Mini Shai-Hulud schlägt erneut zu: 314 npm-Pakete kompromittiert

 (safedep.io)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das atool-npm-Konto wurde am 19. Mai 2026 kompromittiert, wodurch innerhalb von rund 22 Minuten 637 schädliche Versionen für 317 Pakete automatisch veröffentlicht wurden
  • Die Payload ist ein 498 KB großes obfuskiertes Bun-Skript und verwendet dieselbe Scanner-Struktur und dieselben regulären Ausdrücke wie Mini Shai-Hulud, das beim SAP-Kompromittierungsfall eingesetzt wurde
  • Die Ziele für den Diebstahl wurden auf AWS-Zugangsdaten, Kubernetes-Tokens, Vault, GitHub-PATs, npm-Tokens, SSH-Schlüssel und sogar lokale Geheimnisse ausgeweitet
  • In CI wird GitHub Actions OIDC gegen npm-Publish-Tokens getauscht, außerdem werden Sigstore-Signaturen und die Injektion bösartiger Workflows missbraucht
  • Zur Reaktion gehören die Prüfung auf installierte kompromittierte Versionen, der Austausch aller potenziell zugänglichen Zugangsdaten sowie Lockfile- und Dependency-Pinning und Prüfungen vor der Installation

Überblick über den Angriff

  • Das atool-npm-Konto (i@hust.cc) wurde am 19. Mai 2026 kompromittiert, wodurch innerhalb von rund 22 Minuten 637 schädliche Versionen für 317 Pakete veröffentlicht wurden
  • Dieses Konto pflegte 547 Pakete, und die Angreifer führten bei mehr als 314 davon in zwei Wellen Versions-Bumps durch
  • Zu den betroffenen Paketen gehören size-sensor (4,2 Millionen Downloads pro Monat), echarts-for-react (3,8 Millionen), @antv/scale (2,2 Millionen), timeago.js (1,15 Millionen) sowie zahlreiche Pakete im @antv-Scope
  • Die Payload ist ein 498 KB großes obfuskiertes Bun-Skript und verwendet dieselbe Scanner-Struktur, dieselben Credential-RegExes und dieselben Obfuskationsmuster wie das Mini Shai-Hulud toolkit, das drei Wochen zuvor beim SAP-Kompromittierungsfall eingesetzt wurde
  • Exfiltrierte Daten wurden entweder als Git-Objekte in öffentliche GitHub-Repositories committet oder per HTTPS-POST, verschlüsselt mit RSA+AES, an t.m-kosche[.]com gesendet

Verbreitungsweg und SemVer-Risiko

  • Die erste Welle veröffentlichte am 19. Mai 2026 zwischen 01:39 und 01:56 UTC rund 317 Versionen, die zweite Welle führte zwischen 02:05 und 02:06 UTC bei denselben Paketen rund 314 weitere Versions-Bumps durch
  • Die meisten der 309 Pakete erhielten pro Welle genau eine schädliche Version, also insgesamt 2
  • Die vier Pakete size-sensor, echarts-for-react, jest-canvas-mock und jest-date-mock erhielten 3 Versionen und scheinen für erste Tests verwendet worden zu sein
  • Die Angreifer verschoben bei den meisten Paketen das Dist-Tag latest nicht, aber die npm-SemVer-Auflösung wählt unabhängig von latest die höchste Version, die zum Bereich passt
  • So kann etwa bei echarts-for-react latest zwar auf 3.0.6 verbleiben, doch ein Projekt mit "echarts-for-react": "^3.0.6" kann beim nächsten Clean Install auf die schädliche Version 3.2.7 aufgelöst werden

Ausführungspfad und Payload

  • Alle manipulierten Versionen ergänzen in der package.json einen Versions-Bump sowie "preinstall": "bun run index.js"
  • 630 der 637 schädlichen Versionen ergänzen in optionalDependencies @antv/setup: github:antvis/G2#<commit-sha>, um eine zweite Kopie der Payload nachzuladen
  • Der Hook preinstall wird vor der Installation von Abhängigkeiten ausgeführt und setzt die Bun-Runtime voraus
  • Selbst wenn preinstall blockiert oder übersprungen wird, bleibt das prepare-Skript des als GitHub-Commit getarnten Eintrags als zweiter Ausführungspfad erhalten
  • index.js ist ein einzeiliges 498-KB-obfuskiertes Bun-Bundle und weist dieselben Bun-Anforderungen, dieselbe Hex-Variablen-Obfuskation, dieselbe Scanner-Struktur mit 100-KB-Flush-Schwelle und denselben Satz an Credential-RegExes auf wie die beim SAP-Kompromittierungsfall eingesetzte Mini Shai-Hulud payload
  • Zur Erkennung von CI-Umgebungen werden Umgebungsvariablen von mehr als 20 Plattformen geprüft, darunter GitHub Actions, Jenkins, GitLab CI, CircleCI, Travis, Buildkite, Drone, TeamCity, AppVeyor, Bitbucket Pipelines, CodeBuild, Azure DevOps, Netlify und Vercel

Ziele bei der Sammlung von Zugangsdaten

  • Die Payload liest mehr als 80 Umgebungsvariablen mit verschleierten Namen und durchsucht Dateiinhalte per regulärem Ausdruck
  • Zu den Hauptzielen zählen GitHub-Token, npm-Token, GitHub-Actions-JWTs, AWS-Schlüssel, Azure-Schlüssel, DB-Connection-Strings, Stripe-Schlüssel, SSH-Schlüssel, Docker-Authentifizierungsdaten, Vault-Tokens, Kubernetes-Tokens und in URLs eingebettete Zugangsdaten
  • Der Dateiscanner liest Standardpfade für Zugangsdaten im Home-Verzeichnis wie .ssh, .aws/credentials, .npmrc, .docker/config.json und .kube/config
  • Er durchläuft die komplette AWS-Credential-Resolution-Order, holt IAM-Role-Credentials aus EC2 IMDSv2 und dem ECS-Container-Credential-Endpoint und versucht außerdem Zugriffe auf AWS STS GetCallerIdentity und Secrets Manager
  • Bei Vault werden Token-Dateien sowie VAULT_ADDR, VAULT_TOKEN, VAULT_ROLE und weitere Werte geprüft; bei gültigen Zugangsdaten versucht die Malware, Secrets aufzulisten sowie AWS- und Kubernetes-Authentifizierung zu nutzen
  • Für Kubernetes werden Service-Account-Token und KUBECONFIG geprüft; ist ein Docker-Socket vorhanden, wird versucht, Container des Hosts aufzulisten und aus dem Container auszubrechen

C2 und Datenabfluss

  • Die GitHub-API wird wie ein C2 verwendet: Mit GET /user werden gestohlene GitHub-Tokens validiert, mit GET /user/orgs Organisationen aufgelistet
  • Tokens mit ausreichenden Rechten wie repo oder public_repo werden genutzt, um Repositories für die Exfiltration der Angreifer anzulegen
  • Die Beschreibung der erzeugten Repositories wird als umgekehrter String niagA oG eW ereH :duluH-iahS gespeichert, was vorwärts gelesen „Shai-Hulud: Here We Go Again“ ergibt
  • Die Repositorienamen kombinieren zwei Dune-bezogene Wörter mit einer Zahl, etwa harkonnen-melange-742, fremen-sandworm-315 oder gesserit-navigator-508
  • Exfiltrierte Daten werden über die Git Data API in der Reihenfolge Blob, Tree, Commit und Ref-Update gespeichert
  • Ein separater HTTPS-Sender ist so aufgebaut, dass hxxps://t.m-kosche[.]com/api/public/otel/v1/traces wie ein OpenTelemetry-OTLP-Trace-Ingestion-Endpoint aussieht
  • Die HTTPS-Payload verschlüsselt gzip-JSON mit AES-256-GCM und verpackt den AES-Schlüssel per RSA-OAEP mit einem hartkodierten öffentlichen Schlüssel

Missbrauch von CI/CD und der Vertrauenskette

  • Aus GitHub-Repositories, auf die gestohlene Tokens Zugriff haben, sammelt die Malware Workflow-Ausführungshistorien, Artefakte, Secret-Namen, Branch-Listen und Claude-Code-Konfigurationen
  • Auf Secret-Werte kann über die GitHub-API zwar nicht direkt zugegriffen werden, aber die Secret-Namen verraten, welche Zugangsdaten vorhanden sind
  • Der bösartige Workflow wird in .github/workflows/codeql.yml injiziert, trägt den Namen Run Copilot und wird bei push ausgelöst
  • Der Workflow legt mit VARIABLE_STORE: ${{ toJSON(secrets) }} alle Repository-Secrets als JSON in einer Umgebungsvariablen ab, speichert sie als format-results.txt und lädt sie als Artefakt hoch
  • Anschließend wird die Artefakt-ZIP heruntergeladen, und durch das Löschen des Workflow-Runs sowie das Zurücksetzen des Branch-Refs werden Spuren der Injektion reduziert
  • In CI-Umgebungen mit GitHub Actions OIDC wird versucht, über den Endpoint https://registry.npmjs.org/-/npm/…; einen npm-Publish-Token zu erhalten
  • Die Payload enthält eine Sigstore-Signing-Implementierung einschließlich Fulcio, Rekor und SLSA-Provenance-Formaten, sodass mit einer kompromittierten CI-Identität signierte Artefakte erzeugt werden können

Infektion von Entwicklungsumgebungen und AI-Coding-Agenten

  • Die Payload zielt auf Claude Code, Codex und VS Code ab, indem sie per Remote-Injektion über die GitHub API und per lokaler Infektion durch Schreibzugriffe auf das Dateisystem eingeschleust wird
  • In mit den gestohlenen Tokens zugänglichen Repositories werden .vscode/tasks.json, .claude/index.js, .claude/settings.json, .claude/setup.mjs, .vscode/setup.mjs committet
  • .claude/settings.json registriert einen SessionStart-Hook, der bei jedem Start einer Claude-Code-Sitzung node .claude/setup.mjs ausführt
  • .vscode/tasks.json triggert die Ausführung mit "runOn": "folderOpen", wenn der Projektordner geöffnet wird
  • setup.mjs lädt Bun v1.3.14 aus den offiziellen GitHub-Releases herunter, extrahiert die Binärdatei und führt anschließend die Payload aus
  • Der lokale Infektionspfad kopiert die Payload nach ~/.claude/package/index.js und ~/.codex/package/index.js und scannt bestehende Projekt-Konfigurationsdateien, um Hooks einzuschleusen
  • Auf Apple-Silicon-Macs wird dieser lokale Infektionspfad übersprungen, unter Linux, auf Intel-Macs und unter Windows wird er ausgeführt

Persistenz und GitHub-Dead-Drop-C2

  • Ein als kitty-monitor getarnter persistenter Daemon wird unter Linux als systemd-User-Service und unter macOS als ~/Library/LaunchAgents/com.user.kitty-monitor.plist installiert
  • Das Installationsprogramm verwendet systemctl --user enable --now und loginctl enable-linger, damit der Mechanismus auch nach dem Logout erhalten bleibt
  • Der cat.py-Daemon pollt stündlich die GitHub Search API und sucht nach Commits mit dem Keyword firedalazer
  • Das Commit-Nachrichtenformat lautet firedalazer <base64_url>.<base64_signature>; danach wird die RSA-PSS-Signatur mit einem hartcodierten 4096-Bit-RSA-Public-Key verifiziert und der Python-Code der URL ausgeführt
  • Ein separater gh-token-monitor-Daemon pollt gestohlene GitHub-Tokens in 60-Sekunden-Intervallen; die TTL beträgt 24 Stunden
  • Ein Prozessspeicher-Scanner dumpt unter Linux mit /proc/pid/maps+mem und unter Windows mit ReadProcessMemory lesbare Speicherbereiche des Worker-Prozesses von GitHub Actions Runnern

Als antvis/G2 getarnte Commits

  • 630 der 637 bösartigen Versionen enthalten einen optionalDependencies-Eintrag, der auf einen bestimmten Commit im Repository antvis/G2 verweist 
    {
  "optionalDependencies": {
    "@antv/setup": "github:antvis/G2#1916faa365f2788b6e193514872d51a242876569"
  }
}
  • Wenn npm eine github:-Abhängigkeit auflöst, holt es den entsprechenden Commit, sucht dann nach package.json und führt Lifecycle-Skripte aus
  • Der betreffende Commit enthält package.json, das @antv/setup deklariert und ein prepare-Skript umfasst, sowie eine 499 KB große index.js, die dieselbe Shai-Hulud-Payload erneut verschleiert enthält
  • Das && exit 1 im prepare-Skript lässt die optionale Abhängigkeit fehlschlagen, aber npm behandelt Fehler bei optionalen Abhängigkeiten nicht als fatal, sodass die Installation fortgesetzt wird
  • Die Git-API zeigt drei unterschiedliche Commit-SHAs, die in antvis/G2 gepusht wurden und an keinen Branch gebunden sind
  • Alle drei Commits teilen dieselben Metadaten: author huiyu.zjt <Alexzjt@users.noreply.github.com>, Commit-Message New Package, 0 Parent-Commits und keine GPG-Signatur
  • Der Angreifer kann ohne Schreibrechte auf antvis/G2 in einem Fork einen Payload-Orphan-Commit erzeugen und anschließend den Fork löschen, sodass im Namespace des Upstream-Repositories ein per SHA abrufbarer Commit zurückbleibt
  • Diese Methode gehört zur gleichen Art von gefälschten Commits in GitHub Actions, die Chainguard dokumentiert hat, und wird hier auf die Auflösung von npm-github:-Abhängigkeiten angewendet

Kompromittierungsindikatoren

  • Pakete, die atool (i@hust.cc) zwischen dem 19. Mai 2026 01:44 und 02:06 UTC veröffentlicht hat, sollten überprüft werden
  • Das preinstall-Skript lautet bun run index.js
  • Die SHA256 der Payload lautet a68dd1e6a6e35ec3771e1f94fe796f55dfe65a2b94560516ff4ac189390dfa1c
  • Die als antvis/G2 getarnten Commits sind die folgenden
    • 1916faa365f2788b6e193514872d51a242876569 — 626 Versionen
    • 7cb42f57561c321ecb09b4552802ae0ac55b3a7a — 2 Versionen
    • dc3d62a2181beb9f326952a2d212900c94f2e13d — 1 Version, garbage collected
  • Zu den Netzwerk-IoCs gehören hxxps://t.m-kosche[.]com/api/public/otel/v1/traces, EC2-Metadaten unter 169.254.169.254 und Anfragen an ECS-Container-Metadaten unter 169.254.170.2
  • Zu den Repository-IoCs gehören der Branch chore/add-codeql-static-analysis, der Workflow Run Copilot und .github/workflows/codeql.yml, das toJSON(secrets) nach format-results.txt dumpt
  • Zu den IoCs der Entwicklungsumgebung gehören der SessionStart-Hook in .claude/settings.json, "runOn": "folderOpen" in .vscode/tasks.json, .claude/setup.mjs und .vscode/setup.mjs
  • Zu den Persistenz-IoCs gehören kitty-monitor.service, com.user.kitty-monitor.plist, ~/.local/bin/gh-token-monitor.sh, ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state

Wichtige zu prüfende Pakete

  • Die Tabelle compromised-packages.csv enthält die zwei Spalten Package und Compromised Versions und listet laut Tabelle 317 Pakete auf
  • Im Lockfile sollte geprüft werden, ob diese Pakete und die am 2026-05-19 veröffentlichten bösartigen Versionen vorhanden sind
  • Wichtige @antv-Pakete und bösartige Versionen
    • @antv/g2: 5.5.8, 5.6.8
    • @antv/g6: 5.2.1, 5.3.1
    • @antv/g: 6.4.1, 6.5.1
    • @antv/l7: 2.26.10, 2.27.10
    • @antv/x6: 3.2.7, 3.3.7
    • @antv/s2: 2.8.1, 2.9.1
    • @antv/f2: 5.15.0, 5.16.0
  • Allgemeine npm-Pakete und bösartige Versionen
    • echarts-for-react: 3.0.7, 3.1.7, 3.2.7
    • size-sensor: 1.0.4, 1.1.4, 1.2.4
    • jest-canvas-mock: 2.5.3, 2.6.3, 2.7.3
    • jest-date-mock: 1.0.11, 1.1.11, 1.2.11
    • timeago.js: 4.1.2, 4.2.2
    • timeago-react: 3.1.7, 3.2.7
    • @lint-md/cli: 2.1.0, 2.2.0
    • @lint-md/core: 2.1.0, 2.2.0
    • @lint-md/parser: 0.1.14, 0.2.14

Reaktion und Abwehr

  • Wenn eine kompromittierte Version installiert wurde, müssen npm-Tokens, GitHub-PATs, AWS-Schlüssel, SSH-Schlüssel, Cloud-Zugangsdaten, Datenbankpasswörter, Vault-Tokens, Kubernetes-Service-Account-Tokens und Geheimnisse lokaler Passwortmanager ersetzt werden, auf die in der Build-Umgebung zugegriffen werden konnte.
  • t.m-kosche[.]com sollte auf Netzwerk- und DNS-Ebene blockiert werden.
  • Es sollte geprüft werden, ob unter GitHub-Konten mit Tokens, die in der Build-Umgebung zugänglich waren, nicht autorisierte öffentliche Repositories erstellt wurden.
  • In CI-Pipelines sollten Logs zu nicht autorisierten Package-Publishes und zum Austausch von npm-OIDC-Tokens geprüft werden.
  • In den Sigstore-Transparenzlogs sollte geprüft werden, ob signierte Artefakte vorhanden sind, die mit kompromittierten CI-Identitäten erstellt wurden.
  • In lokalen Node.js-Projekten sollten die Hooks in .claude/settings.json, die Auto-Run-Tasks in .vscode/tasks.json sowie .claude/setup.mjs und .vscode/setup.mjs geprüft werden.
  • Der kitty-monitor-systemd-Benutzerdienst und der LaunchAgent com.user.kitty-monitor sollten entfernt werden; außerdem sollte geprüft werden, ob ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state und ~/.local/bin/gh-token-monitor.sh vorhanden sind.
  • Abhängigkeiten sollten gepinnt oder mit einer Lockfile abgesichert werden, damit die Auflösung von semver-Bereichen nicht zu bösartigen Versionen führt.
  • In CI/CD-Pipelines sollten die Freigabe des Docker-Sockets und der Zugriff auf EC2-Metadaten auditiert werden; zudem sollte eine Begrenzung des IMDSv2-Hop-Limits erwogen werden.
  • Package Manager Guard (pmg) ist ein Open-Source-Installations-Proxy, der Packages vor der Ausführung von preinstall mit Threat Intelligence abgleicht.
  • dependency cooldown lehnt Versionen ab, die innerhalb eines konfigurierbaren Zeitfensters veröffentlicht wurden, und kann so starke Auslieferungswellen reduzieren, bei denen semver-Bereiche auf neue bösartige Releases aufgelöst werden.
  • vet kann ungewöhnliche Package-Updates wie unerwartete preinstall-Hooks, sprunghafte Größenanstiege oder Maintainer-Wechsel erkennen, bevor sie CI/CD-Pipelines erreichen.
  • Das Ausmaß der Auswirkungen — 547 Pakete unter einem einzigen Konto und mehr als 314 in einer Session bewaffnete Pakete — legt eine strukturelle Schwäche im Vertrauensmodell von npm offen.

Referenzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • NPM-Lifecycle-Skripte sollten inzwischen standardmäßig deaktiviert sein.
    Im Namen der Bequemlichkeit ist damit faktisch die Ausführung beliebigen Codes eingebaut, und das gilt auch für transitive Abhängigkeiten. Alle weit verbreiteten wurmartigen Angriffe auf NPM wurden über diese Standardeinstellung verbreitet. Es sollte nicht so sein, dass beim einmaligen Aktivieren für einen bestimmten Befehl sofort alle transitiven Abhängigkeiten Lifecycle-Skripte ausführen dürfen; stattdessen sollte man das für jede wirklich benötigte Abhängigkeit explizit kennzeichnen müssen.
    Die überwältigende Mehrheit der NPM-Pakete hängt nicht von solchen Skripten ab, daher ist es sinnvoll, sie global abzuschalten, falls man das noch nicht getan hat.

    • Dazu gibt es ein RFC: https://github.com/npm/rfcs/pull/868
    • Oder man verwendet einfach pnpm.
    • Ja. Oder sie sollten einfach in einer Sandbox laufen. Ein Post-Install-Skript, das im Kontext des installierten Pakets selbst beliebige Befehle ausführt, wäre noch vertretbar, aber die Kombination aus beliebigen Skripten und Benutzerrechten ist eine Katastrophenformel.
      Ein Paket kann allerdings auch beim ersten Import im Programm jeden beliebigen Müll ausführen.

  • Die Aussage „Es gibt keine Möglichkeit, das zu verhindern“ hört man nur bei dem einen Paketmanager, bei dem so etwas regelmäßig passiert.

    • Gibt es abgesehen davon, dass NPM der populärste Paketmanager ist, noch etwas, das ihn für solche Angriffe besonders anfällig macht?

  • Irgendwann könnte es besser sein, Dependabot abzuschalten und NPM-Pakete vollständig bis auf Minor-/Patch-Versionen festzupinnen, statt ständig weiter zu aktualisieren.
    Gerade bei Frontend-Paketen scheinen sinnvolle Sicherheitsfixes inzwischen seltener zu sein als Supply-Chain-Angriffe.
    Traurig, aber wenn man das Frontend in ein statisches BOM verwandelt und darauf vertraut, dass NPM zumindest die Einschränkung „eine alte Version kann nicht erneut veröffentlicht werden“ korrekt durchsetzt — gibt es einen Grund, das nicht zu tun?

    • Dann nervt das Compliance-Team, weil ein CVE mit CVSS 3.1 ungepatcht bleibt, obwohl es einen Patch gibt.
    • Man kann eine Reifezeit erzwingen. Zum Beispiel, indem keine Pull Requests mit Versionen zugelassen werden, die jünger als 30 Tage sind.
      Für Versionen, die bekannte CVEs beheben, könnte man Ausnahmen machen.
    • Ja. Das ist einer der Gründe, warum man solche Supply-Chain-Angriffe in anderen Ökosystemen seltener sieht.
    • Erzeugt NPM nicht ein vollständiges Lockfile inklusive Hashes und festgelegter transitiver Abhängigkeiten?

  • Die Lage wird immer verrückter. Ich persönlich habe bereits node, python und alle Paketmanager von meinem Rechner entfernt und verwende sie stattdessen nur noch in Devcontainern oder VMs.
    Selbst wenn die Entwickler-Community stark gehärtete Sicherheitsmechanismen schafft, mache ich mir Sorgen, dass in vielleicht einem Jahr die Social-Engineering-Fähigkeiten von Modellen so gut sein werden, dass es trotzdem ein verlorenes Spiel bleibt.

    • Ich verstehe nicht, warum du glaubst, dass extrem starke Social-Engineering-Fähigkeiten von Modellen prinzipiell so große Auswirkungen hätten. Es gibt abnehmende Erträge, und der Flaschenhals, dass das Ziel sich mit menschlicher Geschwindigkeit bewegt, scheint enorm zu sein.
      Der Aufwand für den XZ-Hack war zum Beispiel gewaltig, und er ließ sich nicht beschleunigen, weil es darum ging, den bestehenden Maintainer über längere Zeit zu zermürben. Man kann zwar die nötigen bösartigen Nachrichten in Sekunden verfassen und verschicken, aber die Menschen, die sie lesen, werden dadurch nicht schneller; wenn sie alle auf einmal eintreffen, wirkt das eher verdächtig.
      Auch dafür, wie überzeugend Eingaben sein können, gibt es Grenzen. Man könnte irgendeine bösartige Nachricht an den XZ-Maintainer herausgreifen und sie gemeiner, präziser und besser auf persönliche Schwächen und Ängste zuschneiden — aber wäre sie insgesamt viel wirksamer gewesen? Wahrscheinlich nicht, oder höchstens ein bisschen.
    • Wie lösen Container dieses Problem? Wenn sie mit dem Internet verbunden sind — und in der Praxis sind sie das — und solange der Container Anmeldedaten lesen kann, ist das dann nicht dasselbe Problem?
    • Wie steuerst du Cloud-Ressourcen ohne node? Bei Cloudflare braucht man wrangler, und auch bei AWS gibt es viele Node-CLIs.

  • Jetzt, wo Zed 1.0 erreicht hat, würde ich gern komplett wechseln, aber soweit ich weiß, ist das Sicherheitsmodell ganz oder gar nicht. Entweder man erlaubt ihm, beliebige NPM-Pakete nach Belieben herunterzuladen und zu installieren, oder man schaltet sämtliche LSP-Funktionen ab.
    Und dann sieht man ständig solche Meldungen.

  • Könnte npm nicht ein Programm betreiben, das Paket-Uploads automatisch um etwa 10 Minuten verzögert und sie in dieser Zeit an ein Ökosystem externer Code-Audit-Firmen zur automatischen Prüfung verteilt?
    Man könnte ein öffentliches Ranking führen, wer Probleme am schnellsten und zuverlässigsten erkennt, oder sogar Geldprämien vergeben.

  • Diese Liste ist unvollständig. Mindestens ein weiteres Paket, die nx-console-VS-Code-Erweiterung, wurde gestern ebenfalls von diesem Wurm infiziert und hat 2,2 Millionen Downloads.
    Falls das jemand mit Zugang und Kontakten liest: Es wäre sinnvoll, auch diese Abhängigkeitskette zu verfolgen, um zu sehen, ob noch mehr betroffen ist. Hier der Verweis:
    https://github.com/nrwl/nx-console/security/advisories/GHSA-...
    PS: Ich habe es direkt nach der Infektion auf HN gepostet, um die Leute zu warnen, aber leider bekam es kaum Upvotes.

  • Mit Blick auf das gesamte Ökosystem sollte TC39 prüfen, wie man JavaScript selbst um eine bessere Standardbibliothek erweitern kann. Das würde die Zahl der Einzeiler-Pakete reduzieren.
    Stimme zu. Als ich früher mit Deno gearbeitet habe, war einer der besten Aspekte die Standardbibliothek[0] und generell die in sich stimmige Entwicklungsumgebung. Dass die Runtime einen integrierten Test-Runner und eine Assertions-Bibliothek mitbringt, ist eigentlich selbstverständlich.
    0 - https://docs.deno.com/runtime/reference/std/

    • Fairerweise muss man sagen, dass Node schon seit mehreren LTS-Versionen standardmäßig die Module node:test [0] und node:assert/strict [1] bereitstellt. node --test kann Mocha leicht ersetzen, und node:assert/strict ist auch ordentlich, auch wenn chai wegen der Ergonomie von Dingen wie expect manchmal angenehmer ist. Im @std von Deno gibt es eine Assertions-Bibliothek im expect-Stil.
      Das Problem ist, dass es im Node-Ökosystem zu viele Test-Runner gibt und sich viele davon nicht so einfach wie Mocha ersetzen lassen. Deshalb wird der Umstieg auf das eingebaute Test-Harness und die Assertions-Bibliothek natürlich schmerzhaft langsam sein. Aus verschiedenen Gründen mögen die Leute den übermäßig komplexen Charakter von Jest und Vitest. Große Unternehmen hielten sogar Karma für eine gute Idee. Ich verstehe bis heute nicht, warum nicht mehr Entwickler abgestoßen waren von dem Gedanken: „Du magst V8 für Unit-Tests? Dann starten wir dir innerhalb deiner bestehenden V8-Umgebung einfach noch eine weitere V8-Kopie.“
      [0] https://nodejs.org/api/test.html
      [1] https://nodejs.org/api/assert.html#strict-assertion-mode
    • Ich bin mir nicht sicher, welches der hier genannten Pakete in eine „bessere Standardbibliothek“ gehören würde.
      Welche Sprach-Standardbibliothek enthält einen Formatter für Angaben wie „vor 3 Stunden“? Genau das macht timeago.js.
      slice.js liefert im Grunde nur Python-artige negative Indizierung. TC39 hat bereits dafür gesorgt, dass array.at() und array.slice() mit negativen Werten umgehen können.
    • Es ist auch erwähnenswert, dass die Node.js-Standardbibliothek heutzutage weiter wächst und die oben erwähnte Assertions- und Test-Unterstützung einschließt.
      https://nodejs.org/api/

  • Offenbar prüft die Payload den Docker-Socket und versucht, falls vorhanden, mit drei aufeinanderfolgenden Methoden einen Container-Escape.
    Selbst wenn man also in einem Devcontainer oder einer VM arbeitet, versucht so ein Wurm bereits auszubrechen.
    Man sollte sicherstellen, dass man eine rootless VM-Engine verwendet, zum Beispiel podman statt Docker.

    • Manche Leute, sogar aus der Sicherheitsbranche, behaupten etwas anderes, aber Docker ist keine starke Sicherheitsgrenze und sollte nicht so behandelt werden. Es teilt sich das laufende System und den Kernel.
      Das erinnert mich an die Zeit, als Leute Accounts mit niedrigen Linux-Rechten verteilt haben und glaubten, der Kernel werde Privilegieneskalation schon verhindern. Docker ist buchstäblich dasselbe, nur mit mehr Prozedur drumherum. Gerade heute tauchen neue lokale Kernel-LPE-Schwachstellen gefühlt alle fünf Minuten auf.
      Podman ist insofern etwas besser, als man dem Angreifer nicht direkt root gibt, aber warum überhaupt einen Account geben? Nimm einfach eine richtige VM.
    • Man darf den Docker-Socket eben nicht in den Container mounten.
    • Etwas, das eher an Jails oder Zones herankommt, wäre wirklich wünschenswert. Noch besser wäre es, Container innerhalb eines Jails oder einer Zone laufen zu lassen.
      Gibt es unter Linux irgendeine ähnlich umfassende Sandbox wie auf BSD?
    • Warum nicht einfach eine richtige virtuelle Maschine verwenden?
    • Führen die meisten Docker nicht ohnehin rootless aus, zumindest unter Linux? Macht podman darüber hinaus noch mehr?

  • Ich würde jetzt gern aus Mr Bones' Wild Ride aussteigen, aber ich fürchte, so etwas wird weitergehen. Soweit ich das beurteilen kann, richten sich viele kommerzielle Erkennungsstrategien beim Laden oder Verwenden von Paketen auf Repository-, Geräte- oder Entwicklerebene.
    Das wirkt ähnlich wie der Umgang mit E-Mail-Spam oder allgemeiner Malware. Deshalb gibt es fast immer ausreichend lohnende Ziele, damit böswillige Akteure es weiter versuchen. Anders als bei E-Mail sind Paketmanager aber zentralisierte Autoritäten, und es ist naheliegend, dass Probleme außerhalb ihres unmittelbaren Bereichs einfach den Entwicklern zugeschoben werden.
    Aus meiner eher uninformierten Sicht sollte man vielleicht die Kultur schneller Releases und lockerer Versionsverwaltung hinter sich lassen und sich auf stabile, tiefgehend geprüfte Versionen in den Registries konzentrieren. Wegen der Mengen- und Skaleneffekte kann ich mich irren, aber dass stärker dynamische Sprachen offenbar häufiger betroffen sind, bleibt trotzdem aufschlussreich.
    Ich würde wirklich gern einen Text lesen, der die aktuelle Lage umfassend behandelt.

    • Ich habe nachgesehen, ob Mr Bones' Wild Ride vielleicht eine Anspielung auf den Film Nothing But Trouble von 1991 ist, aber ich hatte das falsch in Erinnerung.
      Die Achterbahn in dem Film hieß Mr Bonestripper: https://www.youtube.com/watch?v=NEZEgd8GjJc
      Tatsächlich stammt es aus Roller Coaster Tycoon 2: https://knowyourmeme.com/memes/mr-bones-wild-ride
      Beim Vergleich mit Spam scheint sich unsere Gesellschaft weitgehend damit abgefunden zu haben, in fast allen kommerziellen und sozialen Computer-Netzumgebungen E-Mail-Adressen abzusaugen, Spam den Menschen aufzuzwingen und ihm einen Anschein von Legitimität zu verleihen. In diesem Bereich könnte etwas Ähnliches passieren. Vielleicht in Form einer Kombination aus Oracle-Lizenzüberwachungs-Agenten-artiger Software und automatisiertem Dependency-Management — also indem man Supply-Chain-Malware „löst“, indem man andere Malware auf die Allowlist setzt.