Wir sind nur knapp einer wirklich großen Bedrohung entgangen

• Der jüngste Supply-Chain-Angriff im NPM-Paket-Ökosystem hätte tatsächlich noch deutlich größeren Schaden anrichten können
• Die Angreifer missbrauchten populäre Bibliotheken, setzten die Malware jedoch nur dazu ein, Adressen von Krypto-Wallets zu ändern
• Der Angriff erfolgte über raffinierte Phishing-E-Mails, mit denen die 2-Faktor-Authentifizierungsdaten von Entwicklern gestohlen wurden
• Wäre dies in einer noch gefährlicheren Form eingesetzt worden, etwa zum Diebstahl von API-Schlüsseln, hätte enormes Schadenspotenzial bestanden
• Betont wird, dass jede Abhängigkeit potenziell riskant ist und wie wichtig es ist, den gesamten Dependency-Tree zu verstehen

---

Überblick über den Angriff und die Bedenken

• Im NPM-Ökosystem, einem der größten Paket-Ökosysteme überhaupt, waren kürzlich populäre Pakete einem Angriff ausgesetzt
  • Beispielhafte Funktionen: Terminal-Farbverarbeitung, Mapping von Farbnamen zu RGB, Debug-Dekoratoren für Funktionen, Utility zur Erkennung array-ähnlicher Werte usw.
• Solche allgemeinen Abhängigkeiten werden sehr breit eingesetzt, und sobald Code eingeschleust wird, ist die Wahrscheinlichkeit hoch, dass er direkt in Produktionsumgebungen ausgerollt wird
• Hätte der Angriff bösartige Proxys, den Diebstahl von API-Schlüsseln oder andere schwerwiegende Angriffe enthalten, wären die Folgen womöglich wesentlich gravierender gewesen
• Tatsächlich manipulierte die Malware lediglich Krypto-Zahlungsadressen in Online-Wallets (z. B. MetaMask)

Die Raffinesse des Phishing-Angriffs

• Ausgangspunkt des Angriffs war eine sehr gut gemachte Phishing-E-Mail
  • Sie nutzte den NPM-Benutzernamen, um einen personalisierten Eindruck zu erzeugen
  • Mit der Aufforderung, „aus Sicherheitsgründen Passwort und 2FA-Zugangsdaten zu ändern“, wurde Vertrauen aufgebaut
  • In Verbindung mit den Eigenheiten der NPM-Betriebsweise war der Inhalt so gestaltet, dass gewöhnliche Nutzer leicht darauf hereinfallen konnten
  • Durch die Nennung einer konkreten Frist wurde Dringlichkeit erzeugt, um in stressigen Situationen unvorsichtige Klicks auf den Phishing-Link auszulösen
  • Verwendet wurde eine .help-Domain, die der offiziellen NPM-Domain stark ähnelte
• Der auffälligste Hinweis war letztlich nur die Verwendung von „npmjs.help“ statt der offiziellen Domain
  • Heute werden viele neue gTLDs (Generic Top Level Domains) breit für Blogs, Dokumentation und Ähnliches genutzt, sodass auch das natürlich wirken kann

Das potenzielle Schadensausmaß

• Die Phishing-E-Mail ermöglichte nach dem Diebstahl der 2FA-Daten das Einschleusen von Angriffscode und die Veröffentlichung neuer Paketversionen
• Betroffen waren sehr weit verbreitete Bibliotheken wie is-arrayish, color-string, color-name
  • Wäre die Malware nicht nur zur Umleitung von Kryptowährungen, sondern auch zum Diebstahl von API-Schlüsseln eingesetzt worden, hätte das verheerende Folgen haben können
  • Beispielsweise wären massenhafte Leaks von OpenAI- oder AWS-API-Schlüsseln denkbar gewesen, mit langfristigen und großflächigen Schäden
• Tatsächlich wurden die meisten infizierten Bibliotheken vor allem in Kommandozeilen-Tools verwendet, wodurch der Zweck des Krypto-Diebstahls entsprechend begrenzt war

Fokus auf das Web3-Ökosystem und die Strategie der Angreifer

• Der Angriff scheint in erster Linie auf Web3-Nutzer gezielt zu haben, etwa auf Zahlungen im Browser
  • Durch den Angriff auf allgemeine Bibliotheken ohne direkten Web3-Bezug konnten die Angreifer einer schnellen Erkennung und Blockierung im Web3-Ökosystem eher entgehen
  • Beispiel: Selbst wenn Bibliotheken mit MetaMask-Integration besonders sorgfältig geprüft werden, ist ein Angriff über Utilities für Textfarben kaum zu erwarten

Lehren für das Entwickler-Ökosystem

• Dieser Fall unterstreicht, dass jedes Dependency-Paket tatsächlich bösartig sein kann
  • In der Praxis gibt es klare Grenzen dabei, Dependency-Trees vollständig zu kontrollieren oder permanent zu überwachen
  • Zudem deutet der Fall darauf hin, dass Sicherheitsprüfungen unter dem Druck schneller Produktions-Deployments und knapper Zeit leicht in den Hintergrund geraten
• Künftig wird es noch wichtiger, die gesamte Dependency-Struktur eines Projekts zu erfassen und mit Vorsicht zu verwalten

Abschluss und Hinweis

• Dieser Text soll niemanden anprangern oder verantwortlich machen; wichtig ist vielmehr die Erkenntnis, dass jeder Phishing-Angriffen ausgesetzt sein kann
• Seit der Veröffentlichung dieses Beitrags kann sich die Lage verändert haben; bei Unklarheiten oder möglichen Fehlern sollte direkt selbst nachgeprüft werden

Tags:

[GN⁺]

Hacker-News-Kommentare

• Der nx-npm-Supply-Chain-Angriff war eine Kugel, der viele Unternehmen nicht entkommen wären. Schon allein die Installation des VS-Code-nx-Plugins führte dazu, dass automatisch die neueste nx-Version von npm geprüft wurde. Wenn dabei GitHub-Sitzungen vorhanden waren, etwa über die GH CLI mit einem Firmenkonto, oder wichtige Zugangsdaten in .env-Dateien lagen, konnten all diese Daten abgeflossen sein. Das wäre selbst bei sauberem Dependency-Pinning und gut gemanagten Sicherheitsupdates kaum zu verhindern gewesen. In diesem Ökosystem braucht es grundlegend tiefere Veränderungen. Details stehen in der offiziellen Sicherheitsmitteilung.

  • Ich meide alles, was mit NPM zu tun hat. Die einzige Ausnahme ist der TypeScript-Compiler, aber wenn der in Go neu geschrieben wird, fliegt auch der raus. Bei Go ist großartig, dass man eine Mindestversion angeben kann und dass Heruntergeladenes beim Build-Prozess niemals einfach ausgeführt wird. Bei NPM unterscheidet sich der veröffentlichte Quelltext oft von GitHub, und ich halte das für nicht vertrauenswürdig.
  • Editor-Erweiterungen sind ein attraktives Angriffsziel, weil sie in risikoreichen Entwicklungsumgebungen automatisch installiert und aktualisiert werden. Ich wundere mich, warum es dort noch keine groß angelegte feindliche Aufkaufwelle wie bei Browser-Erweiterungen gegeben hat. Ich habe gehört, dass das VSCode-Team viel Aufwand in Malware-Erkennung steckt, aber ich frage mich, ob alle Editoren wie Sublime solche Prüfprozesse haben.
  • Ich halte alle Pakete und Datenbanken lokal und arbeite auf meiner Entwicklungsmaschine im Flugmodus. Nur für git push schalte ich das Internet ein.

• Wir sind einer Katastrophe wirklich nur knapp entgangen. Kaum zu glauben, dass ein Angreifer mit Zugriff auf solche Pakete am Ende nur ein simples Krypto-Diebstahl-Tool hochgeladen hat. Bei so einer einmaligen Gelegenheit wäre es doch profitabel, noch eine Woche extra zu investieren und raffiniertere Exploits einzubauen: API-Keys, zusätzliche SSH-Public-Keys, Server-IP-Leaks, Browser-Profile oder Session-Tokens auf Entwicklergeräten, sogar die bei mir auf dem Desktop gespeicherten Amazon-Kartendaten. Da gibt es unendlich viel zu stehlen. Selbst wenn man es nicht selbst nutzt, lässt es sich leicht in Darknet-Foren verkaufen. Man fragt sich fast, ob die fähigen Cyberkriminellen längst in stabilen, gut bezahlten Tech-Jobs sitzen und deshalb nur noch solche simplen Angriffe übrig bleiben.

  • Diese Angriffsmethode wäre mit Sicherheit schnell entdeckt worden, also ging es offenbar nicht um Heimlichkeit, sondern um die vollständige Übernahme des Accounts, also um eine schnelle Hit-and-Run-Strategie. Es brauchte eine Methode, mit der sich in wenigen Stunden automatisiert möglichst viel Geld herausholen ließ, und Kryptowährung ist da die offensichtliche Antwort. Wenn der Backdoor nicht so gut versteckt ist, dass selbst die halbe Welt beim Code-Review nichts merkt, gibt es keinen Grund, länger vorzubereiten.
  • Gestohlene Kryptowährung ist realistisch gesehen ein Vermögenswert, den man sicher behält, weil es keine Rückbuchung, Erstattung oder Wiederherstellung gibt. Dagegen sind APIs oder SSH-Keys von Entwicklern fast wertlos, und selbst wenn man Glück hat, muss man sie am Ende doch wieder zu Geld machen, meist ebenfalls über Kryptowährungen.
  • Schnell rein, ein paar Hunderttausend Dollar stehlen, wieder raus und ein paar Monate später dasselbe noch einmal: Wenn man nur der Polizei aus dem Weg geht, kann man so ein Leben lang sorgenfrei leben. Selbst gestohlene AWS-Keys bringen nicht besonders viel. Manche Kriminelle gehen eher auf Passwörter oder Passwortmanager-Datenbanken, aber am Ende landen sie oft doch wieder bei Krypto-Seiten. Es gibt sicher auch jetzt Kriminelle, die geduldig auf den richtigen Zeitpunkt warten, um Unternehmen gründlich zu kompromittieren, und die sich bis zum erfolgreichen Abschluss verborgen halten.
  • Das ist keine Gelegenheit, die es nur einmal im Leben gibt. Kriminelle werden künftig merken, dass sie schon mit der Jagd auf nur ein paar „Entwickler“ sehr leicht an Millionen kommen können, und dann werden immer dreistere Methoden auftauchen. Wenn man Open-Source-Maintainer ist, sollte man inzwischen ernsthaft darüber nachdenken, wie gut die eigene physische Identität online verborgen ist.

• Mein Aufschiebeverhalten ist eine Überlebensstrategie. Ich warte, bis andere Beta testen, deshalb habe ich früher in einer Firma 12 Jahre lang einfach Microsoft Office 2000 benutzt und dadurch zehn friedliche Jahre ohne Upgrade-Probleme oder Umschulungen gehabt. Außerdem habe ich mir angewöhnt, niemals auf Links in E-Mails zu klicken.

  • So halte ich es auch mit meinem Honda und mit Kubernetes. Mein Auto von 2006 habe ich lange genug behalten, um mehrere Generationen großer und kleiner Probleme bei der Auto-Smartphone-Integration zu überspringen, und erst in einem Modell von 2023 lief die iPhone-Anbindung wirklich reibungslos. Bei Kubernetes genauso: Weil ich dem Drängen meines Chefs lange nicht nachgegeben habe, bin ich erst jetzt migriert, wo EKS, GKE usw. ausreichend ausgereift sind, und hatte dadurch deutlich weniger Schmerzen. Hätte ich vor sechs oder sieben Jahren sofort mitgemacht, hätte ich mich wahrscheinlich zu Tode herumgequält.
  • Im npm-Ökosystem ist man schon hoffnungslos zurück, wenn man nicht alle 54 Sekunden aktualisiert.
  • Gegen neue bösartige Pakete ist das wirksam, aber wenn bereits infizierte Software zusätzlich noch von einem Wurm erwischt wird, hilft es nicht unbedingt.
  • Ich antworte morgen.
  • „Neue Versionen grundsätzlich zwei Wochen lang nicht verwenden“ ist eine sehr wirksame Verteidigung gegen Supply-Chain-Angriffe.

• Für kleine Startups ist das schwierig, aber ein großer Player wie npm sollte meiner Meinung nach alle TLD-Varianten seiner Domain reservieren, also etwa „npm.io“, „npm.sh“, „npm.help“ usw. Dass sich der Angreifer die Domain „npm.help“ sichern konnte, hat diesen Angriff noch wirksamer gemacht.

  • Genau wie AWS seine Kunden vor Phishing warnt und dann die offizielle Rechnungsadresse für E-Mails von [e-mail] auf [e-mail] umstellt. Wenn man so eine Adresse zum ersten Mal sieht, wirkt sie fast wie eine Phishing-Mail, aber sie soll offiziell sein, also ist man verunsichert. Sogar die Vorankündigungs-Mail sieht phishy aus, sodass ich die angehängte PDF-Datei erst öffne, wenn ich sicher bin, dass die Rechnung echt ist. Unternehmen warnen ihre Kunden vor Phishing und sorgen dann selbst unnötig für Verwirrung.
  • Es gibt über 1.500 TLDs, manche davon eingeschränkt oder länderspezifisch. Da fragt man sich schon, was es real pro Jahr kosten würde, all diese Varianten zu registrieren. Vermutlich gibt es dafür sogar SaaS-Anbieter.
  • Wenn man sich die TLD-Liste anschaut, sind es einfach zu viele Domains. Selbst für große Anbieter wäre es zwar sinnvoll, ähnliche TLDs zu blockieren, um Phishing zu erschweren, aber vollständig verhindern lässt sich das nicht.
  • Der erste Schritt ist immer, zu prüfen, ob es wirklich die offizielle Domain ist. Domains von Discount-Registraren oder solche mit kurzer Restlaufzeit sind für mich automatisch verdächtig. Besonders wenn zusammen mit Deadlines Druck aufgebaut wird und sinngemäß behauptet wird, „es bleibt keine Zeit“, schaue ich noch genauer hin. Offizielle Kommunikation sollte meiner Meinung nach nur über eine bekannte Hauptdomain oder deren Subdomains laufen.
  • Bei npm und ähnlichen Domainnamen sind die Varianten endlos, daher ist eine vollständige Absicherung durch Vorabregistrierung praktisch unmöglich. Schon am Domainnamen müsste man Phishing erkennen können, aber in der Realität wird selbst so etwas wie npmjs.help versehentlich angeklickt.

• Was, wenn jemand extreme Gründlichkeit im Stil von Jia Tan mit unserer schlampigen Sicherheit kombiniert, also mit Editor-Plugins, Shell-Userland und ähnlichem? Entwickler-Tools laufen mit Superuser-Rechten, werden aber am wenigsten überprüft. Ich kann auch nicht elisp, neovim, vscode und jedes kleine Userland-Tool einzeln auditieren. Im besten Fall kommt es aus nixpkgs. Irgendwann reicht es, ein besseres VSCode-Plugin auf den Markt zu bringen und ein bis zwei Jahre zu warten. GG.

  • Hoffentlich löst irgendwann jemand wirklich das xkcd-1200-Problem.

• Wallets wie MetaMask waren zwar ein Ziel, aber ich habe gehört, dass MetaMask durch das Isolationsmodul LavaMoat gegen solche Angriffe recht gut geschützt ist. Ich würde wirklich gern eine detaillierte Analyse sehen, wie gut dieser Schutz in der Praxis tatsächlich ist. Ich habe persönlich nichts mit MetaMask zu tun, aber mich interessiert, wie wirksam solche Sicherheitsmaßnahmen sind, deren Einführung gegenüber realen Angriffen oft hinterherhinkt. Zur Einordnung noch dieser Beitrag.

• Zu der Aussage „Die Wahrheit ist, dass man auf solche Phishing-Angriffe irgendwann zwangsläufig hereinfällt“ denke ich persönlich: wahrscheinlich nicht ich. Ich habe mir angewöhnt, in E-Mails, die ich nicht selbst ausgelöst habe, niemals Zugangsdaten über Links einzugeben, etwa bei Passwort-Resets. Ich halte das für eine Sicherheitsgrundregel, die 2025 wirklich jeder beherrschen sollte.

  • Die Formulierung „solche“ Phishing-Angriffe lässt es viel raffinierter klingen, als es war. In Wahrheit ist mal wieder einfach ein Entwickler auf eine ganz gewöhnliche Phishing-Mail hereingefallen. Ein sehr grundlegender Fehler, auf den manchmal nicht einmal Verwaltungsmitarbeiter hereinfallen würden. Klar kann jeder mal einen Fehler machen, aber ich denke, dass offensichtliche Nachlässigkeit und amateurhafte Fehler solche Vorfälle immer wieder möglich machen.

• Anders als es in der Erklärung des Artikels klingt, wonach „die gesamte Malware lediglich Krypto-Wallet-Adressen ausgetauscht hat“, blieb MetaMask aus zwei Gründen unbeeinflusst:

1. Zum Zeitpunkt des Angriffs wurde das Paket nicht sofort aktualisiert, und
2. MetaMask war sowohl bei der Installation als auch zur Laufzeit durch LavaMoat geschützt. Die bösartige Payload zielte stattdessen auf Webseiten anderer Wallets ab, die mit MetaMask interagieren. Ich habe übrigens an der Entwicklung von LavaMoat mitgearbeitet. Mehr Infos gibt es im LavaMoat-GitHub.

• Große Open-Package-Repositories brauchen deutlich stärkere Sicherheitslösungen, oder es muss wenigstens einen vertrauenswürdigen, geprüften Kernbestand an Paketen geben. Das gilt genauso für die Python- und Rust-Ökosysteme, die ebenfalls stark auf Vertrauen basieren.

  • Das Grundproblem von npm ist das Fehlen eines erzwungenen Namespace-Systems. Anfänger beschweren sich bei Javas Maven oft, warum es nicht so einfach wie npm ist, aber je mehr Zeit vergeht, desto mehr weiß man Mavens Namensräume und Qualitätsfixierung zu schätzen. POM XML ist zwar unbequem, aber dieses konservative Änderungsmanagement schafft Vertrauen. Dazu passend dieser Artikel: Warum Namespaces in öffentlichen Open-Source-Repositories wichtig sind.
  • Wenn wie in diesem Fall der Account des Paket-Maintainers selbst kompromittiert wird, helfen strukturelle Maßnahmen wie Namespaces allerdings auch nicht mehr. Die einzige Lösung ist dann, neue Releases nicht sofort wirksam werden zu lassen, sondern zu verzögern.
  • Auch Linux-Distributionen arbeiten mit Vertrauen, aber man muss sich das Recht, Pakete hochzuladen, erst verdienen, und es gibt ein ganzes System, um dieses Vertrauen zu überprüfen. NPM wirkt eher wie ein freies System, in das jeder einfach etwas hochladen kann.

• Die Behauptung „Dagegen kann man nichts tun“ kommt immer ausgerechnet aus den Ökosystemen, in denen es am häufigsten zu Kompromittierungen kommt.

  • Genau das ist das Problem. So ein Schluss ist einfach zu bequem.