Die CocoaPods-Saga: Hat Open Source Apples Sicherheitsmodell zerstört?

Open-Source-Abhängigkeiten sind für Organisationen jeder Art und Größe zu einer wachsenden Risikoquelle geworden. log4j, xz Utilities und andere hochkarätige Geschichten haben systematische Schwächen im Ökosystem aufgezeigt, die Bedrohungsakteure zunehmend ausnutzen können. Aber nur wenige vermuteten, dass Apple jemals betroffen sein würde. Schließlich ist dies der Anbieter, der alle in seinem App Store zugelassenen Anwendungen streng prüft. Nun, das war bis zum 1. Juli so, als Sicherheitsforscher ließen eine weitere Open-Source-Bombe: kritische neue Schwachstellen in einem beliebten Abhängigkeitsmanager, der in über drei Millionen macOS- und iOS-Anwendungen verwendet wird.

Die Fehler wurden behoben, aber niemand weiß, ob sie bereits für verdeckte Angriffe auf die Lieferkette ausgenutzt wurden. Dies wirft eine immer häufiger gestellte Frage auf: Wie lösen wir ein Problem wie Open Source?

Was ist passiert?

Die Schwachstellen wurden in CocoaPods gefunden, einem Repository für Open-Source-Projekte in Swift und Objective-C, auf das Millionen von Apple-Apps angewiesen sind. Es enthält über 100,000 externe Bibliotheken (oder „Pods“), die einige der beliebtesten Apps der Welt verwenden – darunter Airbnb, Instagram und Uber. Laut EVA Information Security handelt es sich um die folgenden Schwachstellen:

CVE-2024-38368: Ein Konstruktionsfehler im CocoaPods-Server ermöglicht es jedem Benutzer, einen Pod zu beanspruchen, für den kein Besitzer identifiziert wurde, ohne dass eine Überprüfung erforderlich ist. Es gibt heute Tausende dieser herrenlosen Pods. Laut Endor Labs bedeutet dies, dass ein Bedrohungsakteur ein CocoaPods-Konto hätte registrieren, einen Pod beanspruchen und mit der Verbreitung von Malware beginnen können, als wäre er ein vertrauenswürdiger Betreuer. Der CVSS-Score liegt bei 9.3.

CVE-2024-38367: Der CocoaPods-Server vertraut einem Anforderungsheader, dem er nicht vertrauen sollte, wodurch ein Angreifer den E-Mail-Validierungsworkflow zur Verhinderung von Kontoübernahmen unterlaufen kann. Dies hätte dazu führen können, dass Bedrohungsakteure vorhandene Benutzerkonten kapern und die zugehörigen Pods durch bösartige oder kompromittierte Versionen ersetzen. Der CVSS-Score liegt bei 8.2.

CVE-2024-38366: Stammt aus einer Schwachstelle in einem Ruby-Gem namens „rfc-822“, einer Open-Source-Bibliothek, auf die die CocoaPods-Serversoftware zur Validierung von E-Mail-Adressen angewiesen ist. Bedrohungsakteure hätten es ausnutzen können, um Remotecodeausführung auf dem Trunk-Server zu erreichen. Es hat einen CVSS-Score von 10.0.

Was passiert als Nächstes?

Die gute Nachricht ist, dass die Fehler im vergangenen Oktober behoben wurden. Es bleibt jedoch fraglich, ob sie im letzten Jahrzehnt möglicherweise ausgenutzt wurden, wenn man die Anzahl der offengelegten Pods und die Dauer ihrer Offenlegung (über 10 Jahre) bedenkt. Wäre dies der Fall, hätte die Komplexität der Software-Lieferkette den Bedrohungsakteuren reichlich Deckung geboten.

„Es gibt zwar keine direkten Beweise dafür, dass eine dieser Schwachstellen tatsächlich ausgenutzt wird, aber Beweise für deren Fehlen sind nicht gleichbedeutend mit dem Fehlen von Beweisen“, warnt EVA.

Aus diesem Grund empfiehlt der Anbieter allen betroffenen Entwicklern (die CocoaPods vor Oktober 2023 verwenden), ihren Code durch die folgenden Schritte zu sichern:

• Halten Sie „podfile.lock“-Dateien mit allen CocoaPods-Entwicklern synchron, damit alle auf derselben Version der Pakete sind. Das bedeutet, dass Entwickler nicht automatisch auf ein neues schädliches Update aktualisieren, wenn es eingespielt wird.
• Bei Pods, die intern entwickelt und nur zur Verteilung in CocoaPods gehostet werden, sollten Entwickler eine CRC-Validierung (Prüfsumme) mit der vom CocoaPods-Trunk-Server heruntergeladenen Version durchführen, um sicherzustellen, dass sie mit der intern entwickelten Version identisch ist.
• Führen Sie eine gründliche Sicherheitsüberprüfung des in Anwendungen verwendeten Drittanbietercodes durch.
• Überprüfen Sie die CocoaPods-Abhängigkeiten und stellen Sie sicher, dass Sie keinen verwaisten Pod verwenden.
• Verwenden Sie nur Abhängigkeiten von Drittanbietern, die aktiv gepflegt werden und deren Eigentumsverhältnisse klar sind.
• Führen Sie regelmäßige Sicherheitscode-Scans durch, um Geheimnisse und Schadcode in allen externen Bibliotheken, insbesondere CocoaPods, zu erkennen.

The Bigger Picture

Entwickler verlassen sich weiterhin auf Open-Source-Komponenten, da sie eine schnelle, kostengünstige und einfache Möglichkeit darstellen, Entwicklungszeiten zu verkürzen. Doch die Risiken werden zu groß, um sie zu ignorieren. Laut ISMS.onlines Bericht zum Stand der Informationssicherheit 2024Drei Viertel (75 %) der Organisationen waren von einem Sicherheitsvorfall betroffen, der von einem Drittanbieter oder Lieferanten verursacht wurde. Und fast die Hälfte (45 %) war im vergangenen Jahr von mehreren Vorfällen betroffen.

„Open-Source-Software ist öffentlich zugänglich und kann daher unentdeckte oder ungepatchte Schwachstellen enthalten, die von böswilligen Akteuren ausgenutzt werden könnten. Erschwerend kommt hinzu, dass es bei vielen Open-Source-Projekten keinen dedizierten Support gibt, sodass es schwierig ist, bei auftretenden Problemen rechtzeitig Hilfe oder Updates zu erhalten“, argumentiert Rich Hildyard, Software Product and Delivery Lead beim Mobile Security-Spezialisten MOBSTR.

„Ein weiteres erhebliches Risiko betrifft die Lizenzierung. Die Nichteinhaltung von Open-Source-Lizenzen kann zu rechtlichen Komplikationen führen, insbesondere wenn Lizenzen bestimmte Anforderungen haben, die eingehalten werden müssen.“

Hildyard warnt außerdem vor Projekten, die von ihren Betreuern aufgegeben werden könnten.

„Wenn das passiert, bleiben die Benutzer ohne wichtige Updates oder Fixes, was die Stabilität und Sicherheit ihrer Systeme gefährden kann“, sagt er gegenüber ISMS.online. „Kompatibilitätsprobleme stellen ebenfalls eine Bedrohung dar, da Updates in Open-Source-Abhängigkeiten manchmal Änderungen oder Konflikte mit anderen Softwarekomponenten mit sich bringen können, was die Gesamtfunktionalität beeinträchtigt.“

Boris Cipot, leitender Sicherheitsingenieur bei der Synopsys Software Integrity Group, argumentiert, dass die Komplexität und das schiere Volumen direkter und transitiver Abhängigkeiten es für CISOs schwierig machen, Schwachstellen zu verwalten und zu verfolgen, die mehrere Projekte betreffen. Selbst wenn sie dazu in der Lage sind, kann es aufgrund von Kompatibilitätsbedenken und/oder Testanforderungen zu Verzögerungen bei der Patcherstellung kommen, sagt er gegenüber ISMS.online.

Minimieren von Open-Source-Risiken mit ISO 27001

Das Risiko eines weiteren Log4Shell oder CocoaPods lässt sich jedoch verringern. Er argumentiert, dass eine kontinuierliche Überwachung von Open-Source-Komponenten, auch mit Software Composition Analysis (SCA)-Tools, um Open-Source-Komponenten und ihre Abhängigkeiten automatisch zu identifizieren und zu verwalten, hilfreich sein wird. Cipot plädiert außerdem dafür, dass Sicherheitsteams ISO 27001 befolgen.

„ISO/IEC 27001 ist ein internationaler Standard für Informationssicherheits-Managementsysteme (ISMS), der einen systematischen Ansatz für die Verwaltung vertraulicher Unternehmensinformationen und die Gewährleistung ihrer Sicherheit bietet“, erklärt er. Dieser Standard kann Unternehmen auch dabei helfen, die mit der Verwendung von Open-Source-Software verbundenen Risiken zu mindern, indem er einen strukturierten Rahmen schafft, der verschiedene Risiken berücksichtigt und so die allgemeine Informationssicherheit verbessert.“

Es bietet besonderen Mehrwert durch:

• Risikobewertung und -behandlung: Dazu gehört die Bewertung der Risiken bei der Verwendung von Open-Source-Software, wie etwa Schwachstellen, mangelnder Support oder Lizenzprobleme, sowie die Umsetzung von Maßnahmen zur Minderung dieser Risiken.
• Asset-Management: Die Pflege eines Inventars von Informationsressourcen, einschließlich Open-Source-Software, hilft bei der Identifizierung und Verwaltung der Sicherheitsaspekte der Software und stellt sicher, dass alle Komponenten aktuell und sicher sind.
• Zugriffskontrolle: Um sicherzustellen, dass nur autorisiertes Personal Open-Source-Software verwenden oder ändern kann, und um unbefugte Änderungen zu verhindern, die zu Sicherheitslücken führen könnten.
• Sicherheitsrichtlinien und -verfahren: Diese können Richtlinien für die Verwendung, Überwachung und Aktualisierung von Open-Source-Software enthalten
• Lieferantenbeziehungen: Sicherstellen, dass Drittanbieter von Open-Source-Software Sicherheitsstandards und -praktiken einhalten, die mit den eigenen Standards der Organisation übereinstimmen.
• Patch-Management: Um sicherzustellen, dass Sicherheitslücken in Open-Source-Software umgehend erkannt und behoben werden
• Incident Management: Ein definierter Prozess zur Verwaltung von Sicherheitsvorfällen, einschließlich der Erkennung und Reaktion auf Schwachstellen oder Sicherheitsverletzungen im Zusammenhang mit Open-Source-Software, der Minimierung von Schäden und der schnellen Wiederherstellung
• Einhaltung gesetzlicher Anforderungen: Der Standard hilft Organisationen dabei, gesetzliche, behördliche und vertragliche Anforderungen zu erfüllen, einschließlich der Einhaltung von Open-Source-Lizenzen und der Gewährleistung, dass die Verwendung von Open-Source-Software nicht gegen Gesetze zum geistigen Eigentum verstößt.
• Kontinuierliche Verbesserung: Förderung einer Kultur der kontinuierlichen Verbesserung, in der die Wirksamkeit der Sicherheitskontrollen, einschließlich derjenigen im Zusammenhang mit Open-Source-Software, regelmäßig überprüft und verbessert wird.
• Schulung und Sensibilisierung: Um sicherzustellen, dass die Mitarbeiter die mit Open-Source-Software verbundenen Risiken und die Maßnahmen zur Minderung dieser Risiken verstehen.

Heute ist Open Source allgegenwärtig, sodass Sicherheitsverbesserungen zu einer gemeinsamen Verantwortung aller Benutzer, Betreuer, Mitwirkenden und Unterstützer werden.

„CISOs sollten Beziehungen innerhalb der Community pflegen und sich an gemeinsamen Bemühungen zur Verbesserung der Sicherheitspraktiken entlang der gesamten Lieferkette beteiligen“, schließt Cipot. In der Zwischenzeit könnte in vielen Endbenutzerorganisationen ein Kulturwandel erforderlich sein. Open-Source-Risiken sind nicht dieselben wie die, die von proprietärem Code ausgehen. Je früher mehr CISOs diese Tatsache akzeptieren und lernen, damit umzugehen, desto besser.