Hackvorfall bei den npm-Paketen debug und chalk

• Am 8. September wurde das Einschleusen von Schadcode in populäre npm-Pakete entdeckt
• Insgesamt waren 18 Pakete betroffen, die weltweit auf mehr als 2 Milliarden Downloads pro Woche kommen
• Die Angreifer integrierten Code, der Kryptowährungs- und Web3-Aktivitäten im Browser von Website-Besuchern heimlich abfängt und Freigaben sowie Geldflüsse in Wallets auf Konten der Angreifer umleitet
• Es wurde bestätigt, dass in zentrale Paketdateien (index.js) verschleierter JavaScript-Code eingefügt wurde
• Der Vorfall begann zeitgleich mit Updates der betroffenen Pakete, die Community reagiert derzeit darauf

---

Überblick über den Vorfall

• Am 8. September um 13:16 UTC erkannte der Sicherheits-Monitoring-Feed von Aikido, dass mehrere mit Schadcode versehene Pakete auf npm hochgeladen wurden
• Diese Pakete sind auf npm äußerst beliebt und erreichen mehr als 2 Milliarden Downloads pro Woche

Angriffsweise und Inhalt

• Nach dem bösartigen Update wurde bestätigt, dass JavaScript-Schadcode heimlich im Browser von Besuchern von Websites ausgeführt wird, die diese Pakete verwenden
  • Ziel dieses Codes ist die Überwachung von Kryptowährungs- und Web3-Aktivitäten, die Manipulation von Wallet-Interaktionen und die unbefugte Änderung von Zahlungsadressen
  • Für Nutzer kann es ohne sichtbare Veränderung auf dem Bildschirm dazu kommen, dass Gelder und Freigaberechte an von den Angreifern festgelegte Krypto-Adressen gesendet werden

Detaillierte Analyse des Schadcodes

• Beispielsweise wurde in is-arrayish und anderen Paketen die Datei index.js manipuliert und komplexer, verschleierter JavaScript-Code eingefügt
• Im Code wird die Schnittstelle window.ethereum verwendet, um Informationen zu Wallet-Konten abzufragen und die Bedingungen für die Auslösung des Angriffs zu prüfen
• Intern sind zahlreiche Krypto-Adressen (Bitcoin, Ethereum usw.) sowie Funktionslogik enthalten, mit der Wallet-Adressen und Transaktionsdetails durch Adressen der Angreifer ersetzt werden
• Dadurch besteht das Risiko, dass Kryptowerte realer Nutzer unbemerkt abgegriffen und unbefugt übertragen werden

Aktuelle Lage und Reaktion der Community

• Die betroffenen bösartigen Paketversionen werden zügig aus den wichtigsten npm-Repositories entfernt
• In der IT- und Open-Source-Community laufen aktiv Empfehlungen zum Stopp der Nutzung und zum Upgrade betroffener Pakete sowie Maßnahmen zur Erkennung weiterer Infektionen
• Der Hackvorfall hat das Bewusstsein für die Sicherheit der Paket-Supply-Chain, die Erkennung von Code-Verschleierung und den Schutz von Web3-Browser-Erweiterungen deutlich geschärft

[crawler]

> 8. September 2023,

Die Datumsangabe war aufgrund einer Halluzination falsch. Es geht nicht um 2023, sondern um jetzt.
Es scheint, als gäbe es bei npm ziemlich häufig Meldungen über Hacks. Das wirkt problematisch.

[GN⁺]

Hacker-News-Kommentar

• Ja, ich wurde gehackt. Das ist mir wirklich peinlich, und es tut mir gegenüber allen leid. Für Details schaut bitte hier und hier nach. Ich habe eine Liste der betroffenen Pakete gepostet. Dieser Angriff wirkt gezielt. Ich werde bis zum Ablauf des Zeitfensters zum Bearbeiten des Kommentars laufend Updates ergänzen. Das Chalk-Paket habe ich wiederhergestellt, aber die übrigen sind weiterhin kompromittiert (8., 17:50 CEST). Von NPM gibt es noch keine Rückmeldung. Auf mein NPM-Konto kann ich nicht zugreifen, und auch die Passwort-Wiederherstellung funktioniert nicht. Im Moment kann ich nur warten. Die Support-E-Mail kam von npmjs dot help und sah sehr überzeugend aus. Das soll keine Ausrede sein, aber es war ein müder Morgen, und ich wollte nur noch eine Sache erledigen; aus Unachtsamkeit habe ich wie sonst nicht direkt die offizielle Website aufgerufen, sondern auf den Link geklickt (wohl auch, weil ich am Handy war). Betroffen ist diesmal nur NPM, und unter /debug-js werde ich weiter Updates posten. Noch einmal: Es tut mir wirklich leid

  • Wie schnell und transparent du in dieser stressigen Situation reagierst, ist wirklich vorbildlich. Man denkt immer, man würde nicht auf Phishing hereinfallen, aber ich würde noch ein paar Tipps ergänzen: 1) Niemals über Links in E-Mails einloggen. Phishing und legitime E-Mails sind inzwischen so schwer zu unterscheiden, dass die einzige sichere Methode ist, es gar nicht erst zu versuchen. 2) U2F-/WebAuthn-Sicherheitsschlüssel sind als Zwei-Faktor-Authentifizierung nahezu perfekt gegen Phishing. TOTP ist das nicht. Menschen können am Ende immer Fehler machen, wenn sie müde oder beschäftigt sind. Diesmal hat es dich leider getroffen. Und noch einmal: stark reagiert

  • Laut Hinweis von sindresorhus könnt ihr mit dem folgenden Befehl prüfen, ob sich Malware in eurem Dependency-Tree befindet: rg -u --max-columns=80 _0x112fa8 (benötigt ripgrep, Installation mit brew install rg). Siehe auch den Originalkommentar

  • Mir ist früher an der Uni auch einmal betrunken ein Phishing-Angriff passiert (ist lange her). Wirklich jede Person kann Opfer werden. Umso überraschender ist, wie langsam NPM reagiert. Das spielt Angreifern eher noch in die Hände

  • Socket hat den Vorfall sofort erkannt. Im zugehörigen Blog wird das ebenfalls behandelt. Der Vorfall ist bedauerlich, aber positiv ist, wie schnell das Open-Source-Ökosystem reagiert hat. Solche Fälle zeigen wieder, warum Package-Scanning wichtig ist

  • Danke für die schnelle Warnung. Ich habe porkbun eine E-Mail geschickt und um Sperrung der Domain gebeten

• In dieser Malware-Payload gibt es einen raffinierten Aspekt, der bisher nicht genug beachtet wurde. Statt Wallet-Adressen einfach zufällig zu ersetzen, berechnet sie sowohl zur echten Adresse als auch zu den Adressen in der eigenen Liste die Levenshtein-Distanz und wählt dann die Angreifer-Wallet aus, die am ähnlichsten ist. Sie wurde also gezielt dafür gebaut, die übliche Sicherheitsgewohnheit zu umgehen, nur Anfang und Ende einer Adresse grob zu prüfen. Jemand hat sogar die komplette Payload deobfuskiert, einschließlich dieser ungewöhnlichen Funktion, analysiert und hier ausführlich beschrieben. Passt auf euch auf

  • Ein Teil des Artikels verwirrt mich: Ich dachte, package-lock.json pinnt bestimmte Versionen "exakt" fest. In package.json kann man zwar "Version x oder höher" angeben, aber im Lockfile stehen für jede Dependency doch die festgelegte Version und die Tarball-URL direkt drin. Wenn ein Lockfile vorhanden ist, sollte es in einer CI-Umgebung eigentlich keine automatischen Package-Updates geben. Vielleicht verstehe ich die Funktionsweise von npm-/yarn-/pnpm-Lockfiles falsch. Siehe auch dieses Zitat aus der npm-Dokumentation

  • Ich denke, wenn man Hashwerte mit einer pro Zeichen festgelegten Farbgebung (Vordergrund/Hintergrund), basierend auf Hash und Index, darstellen würde, ließen sich visuell nachgeahmte Hashes viel leichter unterscheiden

  • Mich würde interessieren, ob es Hinweise darauf gibt, dass diese Methode mit einer bestimmten Hacking-Gruppe in Verbindung steht

  • Der Angriffscode ist zwar clever, aber im Web kämpfen wir seit Jahrzehnten gegen ähnliche Address-Spoofing-Angriffe; das ist nur eine dynamischere Version davon. Ihn dafür als außergewöhnlich brillant zu feiern, halte ich für übertrieben. Ehrlich gesagt wirkt die ganze Analyse eher so, als wäre sie von einer KI geschrieben worden, und nicht wie eine sorgfältige Untersuchung

• Ich habe schon vor 12 Tagen, als Nx auf die gleiche Weise kompromittiert wurde, einen ähnlichen Kommentar geschrieben. Das ist nicht das Versagen einer einzelnen Person, sondern das Versagen einer ganzen Branche. Supply-Chain-Angriffe haben enorme Auswirkungen, und eigentlich sind das längst gelöste Probleme. Wir sind Softwareentwickler, also könnten wir sie mit flächendeckender Einführung standardmäßiger Sicherheitsmaßnahmen wie Code-Signing, Artifact-Signing, Erkennung auffälliger Kontoaktivitäten, 2FA usw. verhindern. Dass Verpackungsplattformen das noch immer nicht durchgängig umsetzen, liegt nicht an technischen Grenzen, sondern daran, dass niemand sie dazu zwingt. Durch den Fortschritt bei KI und den wiederholten Erfolg echter Angriffe wird es in Zukunft noch schlimmer werden. Wir sollten starke Sicherheitsstandards endlich verpflichtend machen

  • Solche Sicherheitsmaßnahmen bringen Trade-offs mit sich. Wenn man etwa heuristische oder nachweisbasierte Mechanismen einführt, schließt man unter Umständen viele automatisierte Systeme oder normale Nutzer aus. SMS-basierte 2FA ist schwach, und E-Mail ist phishbar. TOTP ist nur als offener Standard sinnvoll, verhindert Phishing aber ebenfalls nicht vollständig. Wirklich wirksam ist nur hardwarebasierte Authentifizierung, doch die ist auf großen Plattformen nur schwer realistisch durchzusetzen

  • So einfach wie "Wenn wir nur Sicherheitsstandards einhalten, lässt sich alles verhindern" ist es nicht. Selbst mit perfekten Sicherheitsmaßnahmen bleibt das gesamte System verwundbar, sobald Menschen Fehler machen. Ein vollkommen sicheres System gibt es nicht. KI macht Phishing-Mails zwar schwerer von echten zu unterscheiden, aber umgekehrt kann man mit KI auch solche Angriffe besser erkennen. Am Ende werden wir uns wohl mit KI verteidigen müssen

  • Früher zielten viele Angriffe auf Windows, heute gibt es viel mehr JavaScript- und Python-Entwickler. Solche Angriffe werden in Zukunft nur noch schlimmer werden

• Ich finde, NPM trägt ebenfalls einen Teil der Verantwortung. Verschiedene externe Security-Anbieter und Startups erkennen solche bösartigen Aktivitäten schnell, also ist schwer nachzuvollziehen, warum NPM, das alle Pakete und Security-Events in Echtzeit sehen kann, immer wieder so hilflos ist. Es wirkt fast, als würde man bewusst wegsehen

  • NPM gehört inzwischen GitHub, also Microsoft. Offenbar sind sie zu sehr damit beschäftigt, generative KI wie Copilot in jede erdenkliche App zu stecken

  • Bei Paketen mit mehreren Maintainern sollte es zumindest eine Option geben, dass ein anderer Maintainer die Veröffentlichung genehmigen muss, bevor sie live geht

  • Derselbe Angreifer hat in mehr als 22 Pakete, die lange inaktiv waren, gleichzeitig eine obfuskierte (und sehr verdächtig aussehende) Payload eingebracht und gleichzeitig veröffentlicht. Ich glaube kaum, dass NPM das zuverlässig hätte erkennen können. Ich veröffentliche selbst Apps/Erweiterungen auf anderen Softwareplattformen, und dort wartet man oft Tage oder Wochen. Umso erstaunlicher ist, wie wenig NPM in den Dienst investiert wirkt, obwohl MS und GitHub alle möglichen Sicherheitslösungen verkaufen

  • Ich glaube nicht einmal, dass NPM einen starken Anreiz hat, irgendetwas zu ändern. Seit über zehn Jahren ist es eine Quelle für Malware-Verteilung, aber niemand hört auf, es zu benutzen, also schadet es dem Geschäft auch nicht

  • Eine Ursache ist die übermäßige Verbreitung von Package-Managern. Ich mochte es von Anfang an nicht, für so triviale Dinge Dependencies einzubinden. Genauso hasse ich es, wenn wahllos die neuesten Versionen gezogen werden und mir die Umgebung kaputtmachen. Ich hasse nicht nur npm, sondern Package-Manager im Allgemeinen

• Inzwischen finde ich, dass Leute, die ohne Passwort-Manager auf Websites direkt Passwörter eingeben, wenn die Domain nicht der offiziellen entspricht, eigentlich nichts Wichtiges im Internet tun sollten

  • Ein Passwort-Manager bzw. Browser-Autofill hätte bei solchen gefälschten Domains gewarnt und auch bei diesem NPM-Phishing die Abweichung zwischen npmjs.help und der offiziellen Domain verhindert

  • Das stimmt zwar, aber ich habe es schon oft erlebt, dass offizielle Apps und Websites komplett unterschiedliche Domains benutzen. Am schlimmsten sind Fälle, in denen mobile App und Web sogar völlig verschiedene Domains haben. Wer so etwas designt, ist mir ein Rätsel

• Jedes Mal, wenn so etwas passiert, frage ich mich, warum Package-Registries nicht kryptografische Signaturen für alle Pakete verpflichtend machen. Natürlich kann auch eine automatisierte Signierung in CI/CD kompromittiert werden, wenn der Angriff bis dorthin reicht, aber die meisten Probleme ließen sich so verhindern. Allerdings müssten Entwickler dann zusätzliche manuelle Schritte wie Artefakt-Download, Signierung und Upload durchführen

  • Eine echte Registry würde das längst tun, wie Debian. npm wirkt amateurhaft und ist deshalb in Unternehmensumgebungen oft verboten

  • Mir gefällt ein Modell mit nachgelagerter Bestätigung: CI/CD lädt automatisiert hoch, aber die eigentliche Veröffentlichung erfolgt erst, wenn ein Mensch im Web noch einmal klickt. So verringert man die Reibung im Release-Prozess und bekommt trotzdem eine zusätzliche menschliche Freigabe

  • Dann bleibt aber noch das schwierige Problem: Welchem Signaturschlüssel vertraut man? Jeder, dessen 2FA kompromittiert wurde, könnte einen neuen Schlüssel hochladen und damit signieren. Man bräuchte also Mechanismen wie eine Verzögerung bei der Registrierung neuer Signaturschlüssel, wenn verdächtige Kontoaktivität erkannt wird

• Ich bin zu dem Schluss gekommen, dass es deutlich besser ist, die npm registry zu meiden. Stattdessen sollte man Pakete lieber direkt aus (git-)Repos beziehen. Die npm registry ist ein Hauptkanal für Supply-Chain-Angriffe, und außerdem sind dort Quellcode und ausgelieferter Code vollständig voneinander getrennt. Mit npm publish kann man beliebigen lokalen Code direkt hochladen, was es böswilligen Akteuren leicht macht, Malware einzuschleusen

  • Es gibt zwar eine Echtheitsprüfung für Veröffentlichungen von GitHub builds nach npm, aber ich glaube, man kann trotzdem noch aus anderen Umgebungen publizieren, daher ist mir das nicht ganz klar

  • Als C-Entwickler fühlt es sich seltsam an, dass Praktiken wie minimale Abhängigkeiten, Single-Header-Libraries und Vendoring früher als veraltet abgetan wurden, heute aber offenbar wieder als notwendig erkannt werden

  • Die neuere Provenance-Funktion von npm löst dieses Problem. Sie ist relativ einfach einzurichten und hilft, solche Angriffe zu verhindern. Ich freue mich, dass große Pakete sie nach und nach übernehmen

  • Mich würde interessieren, ob man das auch in CI-Umgebungen so macht. Ersetzt man dort das übliche npm install auf dem Server einfach durch git clone?

  • „Pakete direkt aus Git-Repositories beziehen“ klingt theoretisch gut, aber in der Praxis hat npm viele Bugs, die sich auch auf die Installation von Git-Dependencies auswirken. Wie ich in diesem Issue geschrieben habe, funktionierte das wegen Problemen im Build-Step bis 2020 nicht richtig, und auch bei globalem npm install gibt es weiterhin Probleme. Sogar wenn das prepack-Script in der npm-Dokumentation beschrieben ist, funktioniert es in der Praxis bei Git-basierten Dependencies nicht. Das TypeScript-Compiler-Team musste wegen dieses Bugs sogar seltsame Workarounds einsetzen; dazu gibt es Code zur Umgehung und einen Bugfix-Versuch. Problematisch ist auch, dass npm bei einem fehlgeschlagenen prepack den Exit-Code nicht weiterreicht und npm install dann einfach in einem kaputten Zustand endet. Wenn man so etwas sieht, braucht npm dringend bessere Pflege und Aufsicht oder sollte gleich durch einen neuen Package-Manager ersetzt werden

• Als Außenstehender des npm-Ökosystems finde ich es erstaunlich, wie viele Pakete für selbst kleinste Dinge eingebunden werden

  • Das liegt daran, dass die Standardbibliothek viel zu dürftig ist und man selbst für grundlegende Funktionen externe Pakete braucht. Wenn man es selbst baut, steckt in scheinbar trivialen Dingen sehr viel Implementierungsaufwand

  • Aus 15 Jahren Entwicklungserfahrung: Viele berufliche JavaScript-Entwickler können faktisch kaum programmieren. Das ist keine Frage der Intelligenz, sondern von Ausbildung und Kultur. Es gibt eine ausgeprägte Angst davor, eigenen Code zu schreiben, und deshalb greift man selbst bei Kleinigkeiten reflexhaft zu externen Abhängigkeiten. Leute mit Hobbyprojekten haben diese Hemmung oft nicht und schreiben häufig robusteren Code. Wenn dich das interessiert, lass Teammitglieder im Unternehmen einmal etwas ohne großes Framework selbst bauen, dann merkst du es sofort

  • Das Aufteilen in kleine triviale Module soll verhindern, dass unnötiger Code beim Client landet. Umfassende Bibliotheken bieten zwar oft eine sauberere DX, bringen aber auch unerwünschten Code mit (Tree-Shaking hilft, ist aber kein Allheilmittel)

  • Seit dem leftpad-Vorfall geht diese Debatte weiter. Vielleicht liegt es einfach daran, dass die JS-Standardbibliothek zu klein ist

  • Für Reviewer wirkt ein PR mit einer einzigen import-Zeile für ein scheinbar „vertrauenswürdiges“ Modul oft viel einfacher als ein großer Code-Change. Tatsächlich ist das nicht sicherer, aber wenn man müde ist, fühlt es sich plausibler an

• Schon beim letzten nx-Vorfall hatte ich die gleiche Meinung: Package-Manager sollten eine Art Grace Period für neue Pakete haben und sie für eine gewisse Zeit (z. B. 24 Stunden) grundsätzlich überspringen. Solche Angriffe werden meist kurz nach Veröffentlichung erkannt und blockiert; wenn Nutzer in diesem Zeitraum nicht automatisch die neueste Version installieren, ließe sich der tatsächliche Schaden verringern

• Ich kann mir vorstellen, wie groß der Schmerz und der Stress des Autors gewesen sein müssen. Es muss furchtbar sein, sich wegen eines einzigen Fehlers immer wieder erklären zu müssen. Es zeigt auch, wie stark das Open-Source-Ökosystem faktisch von Paketen einzelner Personen abhängt. Wir sollten anerkennen, dass jede Person versehentlich gehackt werden kann. Technisch betrachtet, in einer Zeit, in der KI so viel genutzt wird, brauchen wir offenbar Kulturveränderungen: Warnungen bei verdächtigem Code in deno/node/bun, vertrauenssteigernde Veröffentlichungen im Stil von Debians Signaturmodell wie @verified und die Nutzung verifizierter statt einfach nur der neuesten Versionen. Der Autor ist auch nur ein Mensch, und wir alle sollten freundlich bleiben. Wenn sich die Lage beruhigt hat, würde ich auch gern eine technisch detailliertere Analyse oder ein Postmortem sehen