Was ein npm-Angriff über die Risiken von Open-Source-Software aussagt

Die Geschichte der Open-Source-Sicherheit ist übersät mit Beispielen katastrophaler Fehler und Beinahe-Unfälle. Eine Anfang September entdeckte Krypto-Malware-Kampagne liegt irgendwo dazwischen. Laut BerichteEin nicht identifizierter Bedrohungsakteur hat ein einzelnes npm-Maintainer-Konto kompromittiert und mit diesem Zugriff Schadcode in Paketen mit über zwei Milliarden Downloads pro Woche bereitgestellt.

Es handelt sich bereits um den größten Supply-Chain-Kompromitt in der Geschichte von npm – dem weltweit größten Software-Register. Wenn dies ein Vorzeichen für die Zukunft ist, wie können sich Unternehmensnutzer von Open Source vor den zunehmenden Cyberrisiken schützen?

Was ist mit npm passiert?

Am 8. September gab der Entwickler und Open-Source-Betreuer Josh Junon (alias „qix“) in den sozialen Medien bekannt, dass sein npm-Konto kompromittiert worden sei. Er erfuhr davon, nachdem das Konto trojanisierte Versionen beliebter Pakete wie Chalk (300 Millionen Downloads pro Woche), Debug (357 Millionen) und Ansi-Styles (371 Millionen) veröffentlichte.

Der Schadcode „fängt stillschweigend Krypto- und Web3-Aktivitäten im Browser ab, manipuliert Wallet-Interaktionen und schreibt Zahlungsziele um, sodass Gelder und Genehmigungen ohne offensichtliche Hinweise für den Benutzer auf vom Angreifer kontrollierte Konten umgeleitet werden“, heißt es in der Erklärung. Aikido.

Junon war Berichten zufolge Ziel eines ausgeklügelten Social-Engineering-Angriffs. Die Angreifer hatten einige Tage zuvor eine Typosquatting-Domain registriert und diese genutzt, um sich in einer E-Mail zum Zurücksetzen der Zwei-Faktor-Authentifizierung als legitime npm-Administratoren auszugeben. Junon behauptete, die E-Mail habe „sehr seriös ausgesehen“.

Eine glückliche Flucht?

Am Ende schloss sich die Open-Source-Community zusammen und – beeindruckenderweise – waren alle schädlichen Paketversionen weniger als vier Stunden später entfernt worden.

„Alle arbeiten zusammen. Informationen können geteilt werden. Die Zahl der Leute, die jetzt daran arbeiten, ist nicht nur größer als Ihr Sicherheitsteam, sie ist größer als Ihr Unternehmen“, sagte Anchores Vizepräsident für Sicherheit. Josh Bressers. Berichten zufolge war es den Angreifern damals trotz der potenziell enormen Reichweite der Kampagne gelungen, weniger als 1000 US-Dollar aus den Krypto-Wallets der Opfer zu stehlen.

Doch das war noch nicht alles. Selbst in der kurzen Zeit, in der die Pakete im Umlauf waren, verbreiteten sie sich weit. Laut dem Sicherheitsanbieter Wiz waren 10 % der Cloud-Umgebungen waren betroffen.

„Während des kurzen Zeitraums von zwei Stunden, in dem die Versionen zum Download verfügbar waren, führten alle Browser, die die betroffene Website luden, eine schädliche Nutzlast aus, die sich in Netzwerk- und Wallet-APIs einklinkte, um Empfänger/Genehmigungen für Kryptowährungen vor der Signierung stillschweigend umzuschreiben, sodass Transaktionen auf vom Angreifer kontrollierte Wallets umgeleitet würden“, behauptete der Anbieter.

Später stellte sich heraus, dass die Angreifer auch andere Betreuer und Pakete ins Visier genommen hatten, darunter duckdb, proto-tinker-wc, prebid-universal-creative sowie prebid und prebid.js. Glücklicherweise handelte es sich bei der Schadsoftware „nur“ um Krypto-Diebstahl-Malware und nicht um etwas Ernsteres, aber dies ist sicherlich eine Warnung für die Zukunft.

Betreuer im Fadenkreuz

Der Open-Source-Geist lässt sich nicht mehr zurück in die Flasche kriegen. Im Jahr 2024 wurden über 6.6 Billionen Open-Source-Komponenten heruntergeladen, wobei npm für 4.5 Billionen Anfragen verantwortlich war, laut Sonatyp. Es ist jedoch besorgniserregend, dass die Betreuer äußerst beliebter Pakete, die oft unterfinanziert und überlastet sind, zunehmend ins Visier geraten. Mitun Zavery, Regional VP von Sonatype, vergleicht diese jüngste Kampagne mit der Ziel war letztes Jahr xz Utils.

„Wir haben ein klares Muster erkannt: Bedrohungsakteure nehmen die Betreuer weit verbreiteter, aber unterfinanzierter Projekte ins Visier. Die jüngste Kompromittierung von npm-Paketen wie Chalk und Debug spiegelt unsere Beobachtungen beim Backdoor-Versuch von xZ Utils wider. In beiden Fällen hat der Angreifer geduldig Vertrauen aufgebaut, um die Kontrolle zu erlangen. Das zeigt, dass Social Engineering mittlerweile eine Schlüsselphase bei der Kompromittierung der Lieferkette darstellt“, erklärt er gegenüber ISMS.online.

„Die Industrie muss erkennen, dass Open-Source-Betreuer Teil unserer kritischen Infrastruktur sind, und sie entsprechend mit Finanzmitteln, Sicherheitstools und Support-Netzwerken ausstatten. Unsere Arbeit an xz Utils hat gezeigt, dass eine kollaborative Frühwarnung und schnelle Reaktion im gesamten Ökosystem diese Angriffe stoppen können, bevor sie sich ausbreiten.“

Gehen Sie von Kompromissen aus

Sachar Menashe, Vizepräsident für Sicherheitsforschung bei JFrog, argumentiert, dass die Herausforderung bei solchen Angriffen ihre Geschwindigkeit sei.

„Sobald ein vertrauenswürdiges Paket kompromittiert ist, kann es sich schnell über CI/CD-Pipelines und Projekte verbreiten. Ein Zero-Trust-Ansatz ist entscheidend: Kein Paket sollte nur deshalb vertrauenswürdig sein, weil es beliebt ist“, erklärt er gegenüber ISMS.online. „Um diese Angriffe abzuwehren, sollten Organisationen eine Zwei-Faktor-Authentifizierung vorschreiben. Dies ist bereits in npm und PyPI erzwungen, nicht jedoch in anderen Repositories wie Maven und NuGet.“

Idealerweise sollten Pakete geprüft werden, bevor sie in eine Organisation gelangen, und zwar mit definierten Regeln und einer Analyse der direkten und transitiven Abhängigkeiten im Kontext, fährt Menashe fort.

„Auch das Verzögern von Upgrades hilft. Unsere Untersuchungen zeigen, dass eine Wartezeit von mindestens 14 Tagen vor der Bereitstellung neuer Paketversionen einen starken Schutz bietet, da entführte Pakete fast immer innerhalb dieses Zeitraums erkannt und entfernt werden“, sagt er.

Zavery von Sonatype argumentiert, dass auch die Transparenz von Open-Source-Komponenten und -Paketen von entscheidender Bedeutung sei.

„Unternehmen müssen mit möglichen Kompromittierungen rechnen und darauf reagieren können, indem sie genaue Software-Stücklisten (SBOMs) führen, auf verdächtige Abhängigkeitsänderungen achten und Builds in einer Sandbox ausführen“, erklärt er. „Bei der Untersuchung des xz Utils-Vorfalls haben wir festgestellt, dass diese Transparenz es ermöglicht, fehlerhafte Komponenten schnell zu identifizieren und zu entfernen.“

Sicherheitsstandards könnten Organisationen ebenfalls helfen, argumentiert Zavery.

„Frameworks wie ISO 27001 können helfen, indem sie diszipliniertes Risikomanagement, Zugriffskontrolle und Incident-Response-Prozesse durchsetzen, müssen aber mit Blick auf die Lieferkette angewendet werden“, so sein Fazit. „Die Einbettung von Open-Source-Sicherheitskontrollen in diese Standards kann Unternehmen widerstandsfähiger gegen die Art von Kontoübernahme machen, die wir gerade erlebt haben.“

Eines ist sicher: Diese Angriffe werden jedes Mal stärker werden. Nur wenige Tage nach der Kampagne erste wurmfähige Malware das npm-Ökosystem treffen. Was auch immer passiert, CISOs können es sich nicht leisten, in ihrer Organisation einen blinden Fleck in Sachen Open-Source-Sicherheit zu haben.