Was Sicherheitsteams aus dem xz Utils-Angriff lernen können

Am Karfreitag ließ der Microsoft-Entwickler Andres Freund eine Osterbombe platzen. Während er einige harmlos erscheinende Leistungsprobleme auf einem Debian-Linux-System behob, stolperte er über das Problem beschrieben als der „beste ausgeführte“ Supply-Chain-Angriff aller Zeiten.

Dies wird erhebliche Auswirkungen auf IT-Sicherheitsteams und darauf haben, wie sie künftig mit Open-Source-Risiken umgehen.

Was ist passiert?

Der Angriff war unglaublich komplex. Aber es scheint ein staatlich geförderter Versuch gewesen zu sein, eine Hintertür in eine beliebte Open-Source-Komponente namens xz Utils einzubauen. Das Dienstprogramm zur Datenkomprimierung ist in fast allen Linux-Systemen zu finden. Die Hintertür und die damit verbundene Schwachstelle CVE-2024-3094 sollen Schadcode in einen OpenSSH-Server (SSHD) einschleusen, der auf dem Rechner eines Opfers läuft. Es gibt weitere Details ., aber der Tl;dr ist, dass es entfernten Angreifern, die im Besitz eines bestimmten privaten Schlüssels sind, ermöglichen würde, einen Zielcomputer aus der Ferne zu kapern.

Kurz gesagt, es ist so ernst wie es nur geht, weshalb der CVE einen CVSS-Wert von 10.0 erhielt. Glücklicherweise wurde der Angriff entdeckt, bevor das bösartige xz Utils-Update in große Linux-Distributionen integriert wurde. Zu diesem Zeitpunkt hätte es dem dahinter stehenden Bedrohungsakteur Fernzugriff auf eine unbekannte Anzahl globaler Maschinen ermöglichen können.

Die Raffinesse und die geduldige Planung, die in diesen Angriff eingeflossen sind, deuten auf die Unterstützung des Nationalstaats hin. Wir können dies ableiten, weil:

• Die Hintertür selbst verfügt über eine komplexe Ausführungskette, die mehrere Stufen umfasst
• Die Hintertür wurde über mehrere Commits eingeführt
• Diese Commits wurden nur in Quellcode-Tarball-Releases aufgenommen und nicht in das öffentliche Git-Repository verschoben – um sie vor genauer Prüfung zu schützen
• Die Operation dauerte mindestens zwei Jahre. Zu diesem Zeitpunkt schloss sich der böswillige „Entwickler“ namens „Jia Tan“ dem Open-Source-Projekt an
• Es scheint, dass die Gruppe hinter Jia Tan den ursprünglichen Betreuer Lasse Collin absichtlich unter Druck gesetzt hat, Tan mit ins Boot zu holen. Wahrscheinlich gefälschte Rollen, darunter „Jigar Kumar“ und „Dennis Ens“, die alle den Druck erhöhten, indem sie Lasse mit Funktionswünschen und Fehlerbeschwerden bombardierten

Die Open-Source-Sicherheitsherausforderung

Die schlechte Nachricht ist, dass Jia Tan bekanntermaßen an mehreren anderen Open-Source-Projekten gearbeitet hat. Es ist unklar, ob dort bereits heimlich Schadcode eingeschleust wurde und welche Auswirkungen dies haben könnte.

Open Source ist hier sowohl das Problem als auch die Lösung. Der „Viele-Augen“-Ansatz bei der Softwareentwicklung sollte theoretisch dazu führen, dass Probleme rechtzeitig erkannt werden. Aber wie dieser Angriff zeigt, unternehmen Bedrohungsakteure große Anstrengungen, um Schadcode unbemerkt in Projekte einzuschleusen.

Die Herausforderung für Sicherheitsteams und Entwickler, die Open-Source-Komponenten verwenden, sind die intransitiven Abhängigkeiten, die sie oft unabsichtlich in den Code einführen – wie von hervorgehoben Log4j-Saga. Laut Jamie Scott, Gründungsproduktmanager bei Endor Labs, ist es von entscheidender Bedeutung, sich einen Überblick über solche Risiken zu verschaffen.

„Wenn Sie einem Maven-Paket vertrauen, gibt es im Durchschnitt weitere 14 Abhängigkeiten, denen Sie implizit vertrauen“, sagt er gegenüber ISMS.online. „Diese Zahl ist in bestimmten Software-Ökosystemen wie npm sogar noch größer, wo Sie im Durchschnitt 77 andere Softwarekomponenten für jeden importieren, dem Sie vertrauen. Dieses Vertrauensverhältnis wird mit allen Betreuern aller Softwarekomponenten aufgebaut.“

Was ist also die Antwort? Auf einer Ebene müssen Regierungen, große Softwareunternehmen, die Open Source nutzen, und die Open-Source-Community selbst mehr tun.

„Die Industrie und die Open-Source-Community müssen enger zusammenarbeiten, um das breitere Ökosystem der Cybersicherheitssoftware zu sichern“, sagt Chris Hodson, CSO von Cyberhaven, gegenüber ISMS.online. „Die Grenzen zwischen kommerzieller und Open-Source-Software sind undurchsichtig. Es liegt im Interesse aller, es besser zu machen.“

Scott von Endor Labs fügt hinzu, dass die Industrie durch die Einführung der Artefaktsignierung helfen könnte.

„Artefaktsignierung bietet eine gewisse Widerstandsfähigkeit gegenüber dieser Art von Angriffen, indem sie sicherstellt, dass nur autorisierte Pipelines gültige, signierte Artefakte erzeugen können“, argumentiert er.

„Dies bietet zwar keinen perfekten Schutz, erhöht aber die Kosten für einen Angreifer erheblich, um bösartige Pakete zu übernehmen, und trägt außerdem zu einer effektiven Reaktion auf Vorfälle bei, indem es den Einsatzkräften ermöglicht, die Verwendung des bösartigen Pakets schnell und präzise zu blockieren, sobald es identifiziert wurde.“

Zu den weiteren dringend benötigten Brancheninitiativen gehört die standardmäßige Einführung von Sicherheitsmetadaten wie Software Bills of Material (SBOMs) und Supply Chain Levels for Software Artifacts (SLSA), die CISOs dabei helfen können, die Risiken in ihren Lieferketten besser zu verstehen. Es gibt auch mehr Mittel für Organisationen wie die OpenSSF, die wiederum wichtige Sicherheitsinitiativen finanziert.

Nächste Schritte für Sicherheitsteams

Laut Hodson liegt der Schlüssel für CISOs und DevSecOps-Teams letztendlich darin, Einblick in ihren Open-Source-Code zu gewinnen, insbesondere intransitive Abhängigkeiten.

„Für CISOs ist es wichtig, die Vertrauenskette und die gegenseitigen Abhängigkeiten einer Softwarebibliothek und einer ausführbaren Datei zu schätzen. „Xz Utils“ fühlt sich für sich genommen wie eine relativ risikoarme Softwarekomponente an, aber Gegner werden versuchen, solche Software auszunutzen, um ihr Ziel zu erreichen“, argumentiert er. „CISOs müssen ein viel besseres Verständnis ihrer Lieferkette erlangen – nicht nur der Anbieter, die sie für kommerzielle Software nutzen, sondern auch der Open-Source-Komponenten in ihren Anwendungen und Diensten. Ganz zu schweigen von denen ihrer Dritten.“

Andrew Rose, CSO von SoSafe, teilt diese To-Do-Liste für das Risikomanagement mit ISMS.online:

• Erstellen Sie eine Bibliothek genehmigter Software und Assets, um klare Leitlinien für Entwickler zu gewährleisten und nicht genehmigten Code und nicht genehmigte Software zu begrenzen. Software sollte validiert und genehmigt werden, möglicherweise von Lieferanten mit Risikobewertung
• Erstellen Sie zu Testzwecken gefälschte Data Lakes und implementieren Sie eine Netzwerksegmentierung. Das bedeutet, dass alle Entwicklerumgebungen oder Orte mit unkontrollierten Builds keinen Zugriff auf echte Daten oder Produktionssysteme und -dienste haben sollten
• Verwenden Sie in der Produktion nur genehmigte, freigegebene Builds und überprüfen Sie diese regelmäßig, um sicherzustellen, dass verdächtige Aktivitäten überwacht werden
• CISOs sollten mit Entwicklergemeinschaften in Kontakt bleiben, um sich über auftretende Schwachstellen, Hintertüren und Probleme zu informieren
• Scannen Sie Umgebungen regelmäßig, auch nachdem CISOs das Haus gereinigt haben. Bei der Verwaltung von Diensten oder Software sollte ein „Vieh statt Haustiere“-Modell angewendet werden, was eine kontinuierliche Bewertung und Neuerstellung bedeutet, um sicherzustellen, dass die richtigen genehmigten Versionen verwendet werden

Scott von Endor Labs fügt die folgenden detaillierten Verteidigungstipps hinzu, um die Wahrscheinlichkeit einer Ausnutzung zu verringern, falls eine Software-Lieferkette kompromittiert wird:

• Implementieren Sie die geringste Berechtigung: Im Fall von xz Utils hätte ein Ansatz der geringsten Berechtigung für die Server- und Containerkonfiguration geholfen. Mit Backdoor-SSH-Schlüsseln können Sie auf SSH zugreifen, wenn auf SSH-Dienste zugegriffen werden kann. Bitte setzen Sie SSH-Ports nicht dem Internet aus
• Erstellen Sie Governance-Richtlinien für die Open-Source-Nutzung: Diese können von „Pinnen Sie alle Versionen der verwendeten Open-Source-Software an, damit Sie nicht immer die neueste Version herunterladen“ bis hin zu „Verwenden Sie keine Versionen von Open-Source-Software, die weniger als 60 Tage alt sind“.
• Entfernen Sie ungenutzte Software, um das Risiko in der Lieferkette zu verringern: Ungenutzte Software kann Ihre Software unnötig aufblähen und im Laufe der Zeit ein Risiko für die Lieferkette mit sich bringen. Es ist nur eine Frage der Zeit, bis der nächste Angriff vom Typ xz Utils entdeckt wird. Indem Unternehmen jetzt mehr Vorsichtsmaßnahmen treffen, können sie proaktiv ihre Widerstandsfähigkeit aufbauen und sicherstellen, dass ihr Weg zur Genesung schneller und weniger traumatisch verläuft.