Hunderte AUR-Pakete von Infostealer-Malware-Angriff betroffen

 (lists.archlinux.org)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • In das AUR (Arch User Repository) wurden zahlreiche bösartige Commits eingeschleust, wodurch ein Supply-Chain-Angriff entstand, bei dem der Paketinstallationsprozess so manipuliert wurde, dass npm install atomic-lockfile ausgeführt wird
  • Bei der Durchsicht der schreibgeschützten Mirror-Suchergebnisse wurde derselbe bösartige Befehl in den Dateien PKGBUILD, .install und .hook von rund 408 Paketen bestätigt
  • Die bösartigen Commits nutzen Commit-Fälschung, indem sie Name und E-Mail des jeweils vorherigen Commits missbrauchen, um sich als legitime Maintainer auszugeben; das ist unabhängig von einer möglichen Kontoübernahme
  • Arch arbeitet derzeit an der Rücksetzung bzw. Löschung bösartiger Commits und an der Sperrung von Konten; weitere bösartige Pakete sollen gesammelt in einem einzigen Thread gemeldet werden
  • Community-Mitglieder melden fortlaufend einzelne Paket-Commits und leisten damit eine kooperative Reaktion auf einen Vorfall großen Ausmaßes, der das gesamte AUR-Paketökosystem betrifft

Überblick über den Vorfall und Bitte um Mithilfe

  • Es wurden Hinweise auf massenhaft eingeschleuste bösartige Commits im AUR geteilt; derzeit laufen Maßnahmen zur Rücksetzung/Löschung der bösartigen Commits und zur Sperrung von Konten
  • Falls weitere bösartige Pakete entdeckt werden, wird darum gebeten, sie als Antwort auf diese E-Mail zu melden, damit alles im selben Thread gesammelt werden kann
  • Ein zuständiger Koordinator antwortete, dass alle eingegangenen Meldungen geprüft wurden, und bedankte sich bei den Beteiligten für ihren Zeitaufwand

Muster des Schadcodes — atomic-lockfile

  • Die manipulierten Pakete führen durchgängig npm install atomic-lockfile aus; dahinter folgen zusätzliche npm-Paketnamen wie ora, fast-glob, glob, minimist, axios, commander, execa, chalk, debug und weitere
  • Dateitypen, in denen sich der bösartige Befehl befand
    • Installationsskripte in der Form *-deps.install
    • Paket-Installationsskripte *.install
    • Dateien vom Typ *.hook — zum Beispiel in der Form Exec = /bin/sh -c 'cd /tmp && npm install atomic-lockfile ... 2>/dev/null; exit 0', also Ausführung in /tmp, anschließendes Unterdrücken von Fehlern und Beenden
    • Teilweise auch in zugehörigen Dateien wie install.sh enthalten
  • Als Beispiel für ein neu erstelltes bösartiges Paket wurde exodus-wallet-bin gemeldet; es handelte sich um ein neu angelegtes Paket, das zum Zeitpunkt des ersten Commits vor etwa 4 Stunden erstellt worden war

Erkennungsmethode und Umfang der Auswirkungen

  • Die Erkennung erfolgte durch direkte Prüfung eines schreibgeschützten Mirrors
    • Nach git clone https://github.com/archlinux/aur.git wurden alle Refs durchlaufen und git grep 'atomic-lockfile' ausgeführt
    • Als Ergebnis wurde eine lange Liste von rund 408 Paketen ermittelt, die atomic-lockfile installieren; diese kann für automatisierte Bereinigungsarbeiten genutzt werden
  • Beispiele für als betroffen genannte Pakete
    • runescape-launcher, oracle-bin, tesseract-gui, python-starsessions, bitcoin-core-git, apple-music-desktop, exodus-wallet-bin, anythingllm-appimage, arm-linux-gnueabihf-binutils und weitere
    • Darunter auch breite Paketfamilien wie cutefish-*, python2-* und python-*
  • Da durch zahlreiche Einzelmeldungen sehr viele E-Mails aufliefen, wurde empfohlen, mehrere Fälle in einer einzigen Mail zu bündeln; eine zusammengefasste Paketliste wurde zudem separat auf IRC geteilt

Methode der Vortäuschung/Fälschung

  • Bei Paketen im Zusammenhang mit einem bestimmten Konto (arojas) wurde die Frage aufgeworfen, ob es sich um eine Kontoübernahme oder um Commit-Fälschung handelt
  • Dazu wurde bestätigt, dass die bösartigen Commits Name und E-Mail des unmittelbar vorherigen Commits vortäuschen (impersonate) — also eine Fälschung der Commit-Metadaten
  • Es wurde auch berichtet, dass andere Pakete desselben Nutzers in manchen Fällen bereits bereinigt wurden

Stand der Gegenmaßnahmen

  • Gemeldete Paket-Commits wurden der Reihe nach bearbeitet; bei einigen Einträgen wurde per Antwort Done bestätigt, dass die Korrektur abgeschlossen ist
  • Mit weiteren Meldungen prüfte der zuständige Koordinator die eingegangenen Fälle gesammelt, parallel zu den laufenden Sperr- und Rücksetzungsmaßnahmen
  • Zahlreiche Beteiligte meldeten einzelne Pakete zusammen mit Commit-Links; die Reaktion erfolgte damit als gemeinschaftlich getragene, kooperative Gegenmaßnahme

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Lobste.rs-Kommentare

  • Durch diese Sache dürfte das restliche Vertrauen in anonyme, nicht verifizierte Beiträge in der Community so gut wie am Ende sein
    Es fühlt sich an, als würde man zusehen, wie Vertrauen in Echtzeit abgetragen wird

    • Ehrlich gesagt ist das gut so, und es ist längst überfällig. Unsere Branche muss endlich aufwachen
      Wir vertrauen Computern viel zu viele persönliche und sensible Daten an, und sie sind zum Zentrum des modernen Lebens geworden. Wenn ein privater Rechner kompromittiert wird, ist das ein wirklich katastrophales Ereignis, und im besten Fall kann man nur hoffen, für Hacker nicht interessant genug zu sein, dass sie einen gezielt schikanieren
      Trotzdem haben wir es aus irgendeinem Grund normalisiert, irgendein zufälliges Programm mit vollen Rechten auszuführen[1], und tun dann überrascht, wenn sich das als schlechte Idee herausstellt
      [1] Gemeint sind die aktuellen Benutzerrechte. In den meisten Setups hat root praktisch kaum Bedeutung
    • KDE hat AUR vor einer Woche aus der eigenen Build-Pipeline entfernt; vermutlich war das eine Reaktion auf eine frühere Version dieses Angriffs
    • Es wäre interessant, bei der Prüfung von AUR-Paketen ein Web-of-Trust-Modell anzuwenden und es bei aktuellen Updates mit einer Abkühlphase zu kombinieren
      Ich stelle mir ein System vor, das beim Installieren oder Aktualisieren von AUR-Paketen solche Optionen bietet: bei kürzlich aktualisierten Paketen eine Woche warten, bis sie "abgekühlt" sind; selbst ein paar Minuten investieren, um das Paket zu prüfen, und eine signierte Review zu hinterlassen, die mit dem eigenen Ruf verknüpft ist; oder sich auf signierte Reviews mehrerer anderer Personen verlassen, bei denen sich genug Vertrauen angesammelt hat
      Die Abkühlphase könnte technisch mit der Arch-Politik kollidieren, alle Pakete gemeinsam aktuell zu halten. Allerdings werden AUR-Pakete ohnehin nicht offiziell unterstützt

  • Selbst nach mehreren Stunden wurde das NPM-Paket noch nicht entfernt: https://www.npmjs.com/package/atomic-lockfile

  • Um zu prüfen, ob installierte Pakete betroffen sind, kann man dieses kleine Skript zusammen mit der Datei aur_pkg_list.txt verwenden

    installed_pkgs="$(yay -Qq)";  
grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' \
| while read -r pkg; do \
    echo "$installed_pkgs" | grep "^$pkg\$"; \
done

    Ich habe die Semikolons eingefügt, damit man es leicht als Einzeiler verwenden kann :-)

    • Es scheint auch Teilstrings zu treffen. Zum Beispiel matcht ktea auch auf kteatime
      Diese Version scheint zu funktionieren

      grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' | while read -r pkg; do  
   echo "$installed_pkgs" | grep "^$pkg\$";  
done

  • Gut möglich, dass das schon seit einiger Zeit lief. In dieser E-Mail von vor 18 Tagen scheint ein ähnlicher bösartiger Payload verwendet worden zu sein, aber der schädliche Commit wurde offenbar vollständig aus dem Repository entfernt

  • Dazu passend: Gibt es irgendwo einen wirklich guten Vergleich der Supply-Chain-Sicherheitslage populärer Linux-Distributionen? Die meisten Texte, die ich bisher gefunden habe, wirkten entweder wie subtil verkapptes Marketing oder wie schlampige AI-Ware. Vielleicht muss ich das einfach selbst recherchieren
    Der deprimierende Teil ist, dass ich die Ideale gemeinschaftlicher Entwicklung eigentlich mag, wegen Supply-Chain-Sorgen aber zunehmend genauer auf geschlossene Alternativen oder sogar proprietäre Software schaue