Shai-Hulud-Malware in der KI-Trainingsbibliothek PyTorch Lightning entdeckt

• Die Versionen 2.6.2 und 2.6.3 des Deep-Learning-Frameworks lightning wurden für einen Supply-Chain-Angriff missbraucht — schon pip install lightning führt dazu, dass ein verschleierter JavaScript-Payload im versteckten Verzeichnis _runtime automatisch ausgeführt wird
• Da das Framework breit für den Bau von Bildklassifikatoren, LLM-Finetuning, Diffusionsmodelle und Zeitreihenprognosen genutzt wird, ist es wahrscheinlich bereits im Dependency-Tree vieler AI/ML-Teams enthalten
• Sobald die Malware ausgeführt wird, scannt sie im lokalen Dateisystem mehr als 80 Pfade und stiehlt GitHub-Tokens (ghp_, gho_), npm-Tokens (npm_), Umgebungsvariablen und Cloud-Secrets, wobei pro Datei bis zu 5 MB verarbeitet werden
• Über alle drei großen Cloud-Anbieter hinweg werden Secrets aufgelistet und abgerufen: AWS (Credential-Dateien, IMDSv2, ECS, Secrets Manager, SSM), Azure (Key Vault) und GCP (Secret Manager)
• In GitHub-Actions-Umgebungen dumpt die eingebaute Python-Umgebung den Prozessspeicher von Runner.Worker und extrahiert alle mit "isSecret":true markierten Secrets sowie Repository- und Workflow-Informationen
• Der Einstiegspunkt ist PyPI (Python), aber die Wurmverbreitung erfolgt über npm (JavaScript) — mit gestohlenen npm-Tokens werden in alle veröffentlichbaren Pakete ein Dropper (setup.mjs) und die Malware (router_runtime.js) injiziert, die Patch-Version erhöht und erneut veröffentlicht, wodurch auch die Rechner nachgelagerter Entwickler infiziert werden, die diese Pakete installieren
• Die Datenexfiltration nutzt gleichzeitig vier parallele Kanäle, damit sie nicht durch das Blockieren eines einzelnen Pfads gestoppt werden kann: ① Versand an den C2-Server per HTTPS POST, ② Dead Drop über die GitHub-Commit-Search-API (doppelt Base64-kodierte Tokens in Commit-Messages), ③ Commit als results-<timestamp>.json in ein öffentliches GitHub-Repository mit Namen aus dem Dune-Universum, ④ direkter Push in das Repository des Opfers
• Nach der Kompromittierung eines Repositorys werden Persistenz-Hooks in Entwicklertools eingebaut, um eine Reinfektion sicherzustellen — in Claude Code wird in .claude/settings.json ein SessionStart-Hook eingetragen, der beim Sitzungsstart automatisch ausgeführt wird, und in VS Code wird in .vscode/tasks.json ein Task mit runOn: folderOpen hinterlegt, der bei jedem Öffnen des Ordners läuft
  • Beide Hooks rufen den in sich geschlossenen Dropper setup.mjs auf; falls die Bun-Runtime fehlt, wird sie unauffällig von GitHub heruntergeladen und der 14,8-MB-Payload router_runtime.js ausgeführt
• Wenn ein GitHub-Token mit Schreibrechten erlangt wird, pusht der Angreifer einen als Formatter getarnten Workflow in das Repository des Opfers — bei jedem Push werden die Repository-Secrets mit ${{ toJSON(secrets) }} gedumpt und als Actions-Artefakt hochgeladen
• Alle Maschinen, auf denen in dem betroffenen Zeitraum diese Versionen installiert wurden, sollten als vollständig kompromittiert gelten; GitHub-Tokens, Cloud-Credentials und API-Keys müssen sofort ersetzt werden, außerdem sollten die Verzeichnisse .claude/ und .vscode/ auf unerwartete Dateien geprüft werden
• Kompromittierungsindikatoren: der Präfix EveryBoiWeBuildIsAWormyBoi in Commit-Messages, "A Mini Shai-Hulud has Appeared" in der Repository-Beschreibung oder das Vorhandensein eines _runtime/-Verzeichnisses im Repository — all das lässt sich direkt über die GitHub-Suche überprüfen

[picopress]

Dann sollte man jetzt wohl besser nicht updaten ...

[GN⁺]

Hacker-News-Kommentare

• Vielleicht ist es einfach nur Häufigkeitstäuschung, aber in letzter Zeit sieht man bei wichtigen Paketen ziemlich viele bekannte Supply-Chain-Angriffe
  Schon auf den ersten paar HN-Seiten stehen gerade mehrere Beiträge zu unterschiedlichen Fällen
  Wenn ich an left-pad vor 10 Jahren zurückdenke, frage ich mich, ob erfolgreiche Angriffe heute häufiger sind als damals, und wahrscheinlich ist das so
  Der Wert erfolgreicher Angriffe ist sicher auch gestiegen, aber ich frage mich, ob sich unsere Fähigkeit als Community tatsächlich verbessert, solche Dinge vor einem Paket-Release zu erkennen
  Kommerzielle Softwarefirmen müssen das besser machen, aber es scheint immer noch an universellen, einfachen Tools für Fälle zu fehlen, in denen etwas als Hobby-/Amateurcode beginnt und dann zur Abhängigkeit vieler Projekte wird
  Ich habe denselben Kommentar auch im aktuellen SAP-Supply-Chain-Angriff-Thread gepostet: https://news.ycombinator.com/item?id=47964003

  • Das ist ein reales Phänomen. Stand Anfang April gab es in den letzten 12 Monaten 7 Fälle, in den 20 Jahren davor waren es 9: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
  • Wenn Leute Code massenhaft überall hineinschieben, ohne ihn richtig anzuschauen, ist es nur natürlich, dass Supply-Chain-Angriffe entsprechend zunehmen
  • Der Grund sind automatische Updates und CI-Tools, die eine kritische Verbreitung erreicht haben und von allen genutzt werden
    Früher wurde npm install häufiger manuell ausgeführt, wahrscheinlich nur wenn Builds kaputtgingen oder sehr gelegentlich
    Supply-Chain-Angriffe beruhen darauf, dass Menschen, genauer gesagt Pipelines, Pakete gedankenlos automatisch aktualisieren, sobald ein neues Release erscheint
  • Historisch war die Verarbeitung von Artefakten mit zusätzlichen Sicherheitsprüfungen eine kostenpflichtige Enterprise-Option, und die weniger sichere Variante war der deutlich bequemere Standard
    Ob das ein gutes Geschäftsmodell ist, weiß ich nicht, vermutlich eher nicht
  • left-pad war kein Angriff, sondern ein Bug in NPM
    Es hätte nicht möglich sein dürfen, Paketversionen zu löschen, von denen bereits veröffentlichte andere Pakete abhängen, und umgekehrt hätte man bestimmte Paketversionen löschen können sollen, wenn sie neu sind und niemand von ihnen abhängt
    Als der left-pad-Autor versuchte, alle seine Daten zu löschen, weil er den Dienst verlassen wollte, hätte NPM einen Fehlercode zurückgeben müssen
    Laut Wikipedia stellte NPM-Autor Schlueter, nachdem Koçulu von einer Entscheidung von npm, Inc. enttäuscht war und nicht länger Teil der Plattform sein wollte, einen Befehl bereit, um die 273 von ihm registrierten Module zu löschen

• Merkwürdig ist, dass vier Sicherheitsprobleme gemeldet wurden und alle automatisch vom Bot pl-ghost kommentiert und geschlossen wurden [1][2][3][4]
  Am Ende wurde nur [4] korrekt bearbeitet, und die Bot-Kommentare wurden alle gelöscht
  Im anderen Bericht [5] kann man die Bot-Kommentare sehen, und sie enthalten sogar mehr Informationen als das Original
  [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [5] https://socket.dev/blog/lightning-pypi-package-compromised

  • Hier ist Andy von Lightning. Ja, die PyPI-Zugangsdaten wurden über das kompromittierte pl-ghost-Bot-Konto gestohlen
    Der Angreifer erstellte mit diesem Konto einen neuen Actions-Workflow und extrahierte im ausgeführten Workflow die PyPI-Secrets
    Nach dem Release des Pakets kommentierte er dann noch mit diesem Konto und verspottete uns ein wenig

• Ich wünschte, der Tag ohne Abhängigkeiten würde endlich kommen
  Als extremes Beispiel lasse ich Opus inzwischen, wenn ich interaktive Lern-Apps für meine Tochter baue, nur noch reines JavaScript und HTML verwenden
  Vom Doppelpendel bis zur Flüssigkeitssimulation läuft damit alles auf einmal gut, und früher waren dafür Hunderte von Abhängigkeiten nötig
  Bei MIT-lizenziertem Code kann ich Opus sagen, es soll nur genau die Teile extrahieren, die ich brauche, sie für meinen Zweck anpassen und einbinden
  Für Hobbyprojekte hat das bisher gut funktioniert, und ich hoffe, dass in Zukunft auch Produktionssoftware ohne Abhängigkeiten auskommt

  • Dann musst du allerdings alle Änderungen und zahllosen Sonderfälle selbst verwalten
    Wenn Chrome irgendeine API-Form ändert, musst du das selbst finden und reparieren, und wenn Marokko den Beginn der Sommerzeit verschiebt, musst du auch deinen Datums-/Zeitcode selbst aktualisieren
    Das sind Dinge, die Bibliotheken für uns erledigen und die wir deshalb als selbstverständlich ansehen
    Für einen Doppelpendel-Simulator, an dem deine Tochter nächste Woche das Interesse verliert, ist das kein großes Problem, aber für eine Firma, die etwas baut, das auf unbestimmte Zeit funktionieren muss, schon
  • Jetzt bist du stattdessen der eigentlichen Abhängigkeit ausgesetzt: dem Browser
  • Du wirst natürlich jede Zeile des von Opus erzeugten Codes genauso sorgfältig prüfen, wie du es von einem Open-Source-Maintainer erwarten würdest, oder? Oder?
    Vielleicht sollte ich mal etwas MIT-lizenzieren Remote-Access-Code veröffentlichen, damit er in den Opus-Trainingsdaten landet
  • Ich mag Rust lieber als Go, deshalb hadere ich damit. Auch aus LLM-Sicht ist Rust besser, aber die Abhängigkeitsphilosophie von Rust ist faktisch ein Sicherheits-Schwarzes-Loch, und Go ist da viel besser
  • Hast du irgendein teilbares Repo oder Forge-Projekt hochgeladen? Ich habe ein Spiel zum Buchstabieren von Nutztieren und würde gern meine Bibliothek erweitern und mehr Ideen entwickeln

• Als ich den Fast.AI-Deep-Learning-Kurs gemacht habe, war ich überrascht, wie viele Python-Abhängigkeiten ein Machine-Learning-Projekt mit sich schleppt
  Bei Web-Frontend-Projekten ging ich immer von vielen Third-Party-Abhängigkeiten aus, aber für mich wirkt das ML-Ökosystem noch viel stärker verstrickt
  Außerdem gilt Webentwicklung als sicherheitssensibel, sodass sich dort über lange Zeit viel Sicherheitswissen und viele Praktiken angesammelt haben, während ML-Entwicklung viel improvisierter wirkt und selbst allgemeine Software-Engineering-Praktiken oft kaum angewandt werden
  Eine der Methoden zur Bereitstellung von ML-Modellen damals war zum Beispiel Python pickle, also im Grunde ein ausführbares Objekt ohne eingebaute Beschränkungen
  Modelle in diesem Format konnten auf dem importierenden Rechner alles tun, und ein solches frühes Wildwest-Ökosystem macht Sicherheitsverletzungen und Supply-Chain-Angriffe leichter

  • In diesem Ökosystem gibt es viele Menschen, die ursprünglich keine Softwareingenieure waren
    Manche haben unterwegs ein bisschen Programmieren gelernt, manche sind Mathematiker, und manche sind so etwas wie von AI berauschte Entwickler
    Es gibt auch die Haltung: „Code ist jetzt nicht mehr wichtig, Hauptsache es läuft“
    Für viele ist ordentliches Dependency Management nur lästige Arbeit, mit der sie sich nicht befassen wollen
    In vielen ML-Projekten kommen diese Faktoren zusammen, obwohl gerade ML-Projekte eigentlich zu den Bereichen gehören, die sich am stärksten auf Reproduzierbarkeit konzentrieren müssten

• Bei einer Repository-Suche sehe ich, dass unter den in den letzten 24 Stunden erstellten Repositories 2.200 den Text "A Mini Shai-Hulud has Appeared" enthalten: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

  • Die Repo-Namen scheinen alle aus zwei Begriffen/Wörtern aus Dune zu bestehen, etwa harkonen, mentat oder ornithoptor, jeweils mit einer Zahl dahinter
    Das wirkt wie ein Hinweis darauf, dass Konten, vermutlich GitHub-Auth-/Actions-Tokens, kompromittiert und dann zum Erstellen von Repositories verwendet wurden
  • Dieses Konto https://github.com/tinin46 scheint viele Schlüssel gespeichert zu haben, aber ich verstehe nicht genau, wofür
  • Ich verstehe nicht, warum GitHub nicht sofort reagiert und Repositories blockiert, deren README auf diesen Regex passt
    So etwas ist doch schon einmal passiert, man sollte meinen, sie hätten daraus gelernt
    Diese Malware hat sich nicht einmal viel Mühe gegeben, und Microsoft anscheinend auch nicht
  • Was zum Teufel ist hier eigentlich los?

• Zur Einordnung: Ich habe pytorch nie benutzt und kenne mich mit Praktiken der Softwaresicherheit nicht besonders gut aus
  Aber mir fällt kaum ein Szenario ein, in dem pytorch Netzwerkzugriff brauchen sollte
  Es scheint falsch zu sein, dass man irgendwo im Code beliebige Module importieren und diese API dann nutzen kann
  Es bräuchte wohl zusätzliche Import-Beschränkungen oder statische Analyse
  Die Sprache scheint nicht die richtigen Abstraktionen zu haben, um mit solchen Problemen umzugehen
  Zum Vergleich mag ich an Rust, dass man schon anhand der Funktionssignatur Mutabilität und Lifetimes erkennen kann, ohne den internen Code zu verstehen
  So etwas Ähnliches bräuchte man auch für Abhängigkeiten
  Entwickler sollten alle Abhängigkeiten leicht auditieren können, ohne in untergeordneten Code einzutauchen, und sofort sehen: „Aha, diese Abhängigkeit benutzt eval()“ oder „diese greift aufs Netzwerk zu“
  Mobile Apps erzwingen Berechtigungen, also sollten Entwickler doch auch nur bestimmte Fähigkeiten auf eine Allowlist setzen können, statt komplette Funktionspakete pauschal zu übernehmen

  • Das Python-Ökosystem wird so etwas wohl niemals zulassen, aber ich wünschte, dieses Thema würde dort besser verstanden und ernster genommen
    Ich möchte ungern verallgemeinern, aber besonders die AI-Entwickler-Community scheint Bequemlichkeit über fast alles andere zu stellen
    Es ist zum Beispiel quasi Standard, dass ein Projekt beim ersten Start automatisch große Modelle herunterlädt
    Meist kann man das zwar deaktivieren, aber wegen tief verschachtelter Klassenebenen über mehrere Bibliotheken hinweg ist es wirklich schmerzhaft, die richtigen Parameter dafür zu finden
    Es ist schön, dass man mit komplexen Dingen, oft eher Spielzeug, so leicht loslegen kann, aber diese permissive Kultur fühlt sich ziemlich unangenehm an
    Der erste Problemlösungsschritt scheint immer „pip install …“ zu sein, und manche Umgebungen, etwa MacOS, virtualisieren den GPU-Zugriff auch nicht besonders gut
  • Es gibt Fälle, in denen Modelle über mehrere Compute-Nodes hinweg trainiert werden. Das ist ein wichtiger Anwendungsfall für Netzwerkzugriff

• Ich habe mich diese Woche gefragt, ob es eine gute Idee ist, für das Python-Versionsmanagement uv zu nutzen
  Auf der Website [1] steht: „Da Python keine offiziellen Binärdateien für die Distribution bereitstellt, verwendet uv Distributionen aus dem Projekt Astral python-build-standalone“
  Dabei wird auf dieses GitHub-Repository https://github.com/astral-sh/python-build-standalone verwiesen, und dort wiederum auf https://gregoryszorc.com/docs/python-build-standalone/main/r...
  Wenn ich das richtig verstehe, wird der Source Code für Python-Builds also nicht direkt von python.org bezogen, und ich bin mir unsicher, wie sicher das ist
  Bei asdf [2] habe ich ähnliche Bedenken, aber asdf nutzt pyenv [3], und das wirkt auf mich offizieller
  Kann jemand erklären, welches Tool für Python-Installationen besser und sicherer ist, uv oder asdf?
  [1] https://docs.astral.sh/uv/guides/install-python/
  [2] https://github.com/asdf-community/asdf-python
  [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

  • python-build-standalone lädt den CPython-Sourcecode direkt von python.org herunter[1]
    Woher sonst sollte er ihn auch holen
    [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
  • Um uv und cpython mache ich mir nicht viele Sorgen. Der Prozess ist solide, die Reaktion schnell, und inzwischen ist auch viel Finanzierung da
    Was mir Sorgen macht, sind etwa Formatter wie mdformat, die weit verbreitet sind, aber im Wesentlichen von einer Person in ihrer Freizeit gepflegt werden, oder sehr spezielle Abhängigkeiten, die seit Jahren nicht aktualisiert wurden und drei Ebenen tief im Dependency Tree hängen
    Ich möchte in einer aktiv entwickelten App nicht jedes Update pinnen und manuell freigeben müssen, aber bei ernsthaften Anwendungen scheint das inzwischen fast Pflicht zu werden
    Dann hole ich mir wohl besser wieder API-Keys aus unverschlüsselten .env-Dateien
    Wenn so etwas bei einer großen Consumer-Webapp passiert, ist es peinlich, aber nachvollziehbar; wenn man aber wegen einer indirekten Abhängigkeit in einem Demo-Repo, das zufällig auf demselben Host und System liegt, Hunderte oder Tausende Dollar verliert, ist das schon brutal
    Weiß jemand, ob OAI oder Anthropic bei auf diese Weise gestohlenen Schlüsseln Rückerstattungen geben, oder gilt das als Benutzerfehler?
  • uv ist letztlich selbst eine Binärdatei, die auf deinem Rechner läuft und Python-Binärdateien, Pakete, darin enthaltene Binärdateien und systemweite Tools verwaltet
    Ich weiß nicht, wie groß der Risikounterschied wirklich ist, ob sie die Python-Binärdateien selbst bauen oder jemand anderes

• In letzter Zeit entstehen die meisten meiner pip install-Befehle dadurch, dass Claude Code sie vorschlägt und ich einfach Enter drücke
  Das Modell wurde mit Daten von vor einigen Monaten trainiert und kann unmöglich wissen, was diese Woche kompromittiert wurde
  Damit habe ich mir wohl den denkbar schlechtesten Filter gebaut, um zu beurteilen, ob „dieses Paket gerade sicher ist“

  • Man sollte Faulheit und mangelnde Sorgfalt nicht dem LLM anlasten
  • Welcher Filter soll das überhaupt sein?
    Du hast gesagt, dass du Claude Code Software empfehlen lässt, die du aus dem Internet installieren sollst, und sie dann einfach installierst
    Ich habe noch nie gehört, dass jemand vorschlägt, Claude Code oder irgendein LLM sei ein Filter, um zu beurteilen, ob „dieses Paket gerade sicher ist“, und aus genau dem von dir genannten Grund wäre das eine extrem schlechte Heuristik
  • Veraltete Trainingsdaten sind nur ein Teil des Problems; selbst ein topaktuelles Modell kann nicht wissen, was setup.py auf meinem Rechner ausführen wird
    Es gibt ja nichts, was das Paket vor der Ausführung tatsächlich inspiziert
    Was wir brauchen, ist ein Tool, das vor der Ausführung Metadaten abruft und zeigt, welche Hooks vorhanden sind
  • Das lässt sich leicht vermeiden, indem man einfach nicht Enter drückt
  • Bedeutet „schlechtester Filter“, dass du einfach Enter drückst, wenn Claude es sagt?

• Claude Code wird fast täglich aktualisiert, manchmal sogar mehrmals pro Tag
  Wenn Anthropic irgendwann kompromittiert wird, sind wir alle richtig dran

  • Wer ist mit „wir“ gemeint?
  • Wenn man es in einer nicht privilegierten VM/einem Container mit eingeschränktem Netzwerkzugriff ausführt, dann nicht
    Aber heutzutage ist offenbar alles YOLO
  • Das dürfte schon im Polymarket-Preis eingepreist sein

• Ich habe auf GitHub diese Nachricht vom 20. April gesehen und bin etwas verwirrt
  "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
  Falls sie das Problem damals schon kannten und bis jetzt nicht gewarnt haben, fände ich das wirklich unerquicklich
  Es wäre gut, wenn jemand mit mehr Wissen das klar erklären könnte
  https://github.com/Lightning-AI/pytorch-lightning/issues/216...

  • Hier ist Andy von Lightning. Das bösartige Paket wurde heute um 12:45 PM UTC auf PyPI veröffentlicht
    Davor gab es keine betroffenen Distributionen, und wir wussten auch nichts von einem Leak
    Das ursprüngliche Release auf GitHub war nicht betroffen, wurde aber zur Vermeidung weiterer Verwirrung heruntergenommen
  • Für Leute, die uv verwenden: https://docs.astral.sh/uv/reference/settings/#exclude-newer