Atomic Arch. Wie 1.500 AUR-Pakete ohne Exploit gekapert wurden

Die Arch-Linux-Community bemerkte um den 11. Juni herum eine Unregelmäßigkeit im Arch User Repository (AUR). Sicherheitsforschende deckten einen groß angelegten Supply-Chain-Angriff auf. Angreifer hatten über 1.500 Community-Pakete gekapert. Die Aktion kam völlig ohne Zero-Day-Schachstellen aus. Die Täter nutzten das Vertrauensmodell der Community aus, indem sie verwaiste Projekte übernahmen.

Der Ablauf des Angriffs

Die Kampagne zielte auf verwaiste Pakete im AUR ab. Maintainer verlassen Projekte oft, wenn sie den Arbeitsplatz wechseln oder das Interesse verlieren. Das AUR erlaubt es anderen Accounts, die Eigenverantwortung für solche verlassenen Pakete zu beantragen. Die Angreifer reichten Übernahmeanträge ein, die vom Governance-Prozess genehmigt wurden. Die neuen Besitzer behielten die Projekthistorie und die bestehende Nutzerbasis komplett bei.

Den eigentlichen Quellcode der Software änderten sie nicht. Stattdessen modifizierten sie die PKGBUILD-Anweisungen und Install-Hooks. Sobald Entwickler einen AUR-Helper nutzten, um ihr System zu aktualisieren, wurde das schadhafte Build-Skript mit erweiterten Rechten ausgeführt. Das Skript schleuste einen Befehl ein, der ein Node-Paket namens atomic-lockfile oder ein Bun-Paket namens js-digest installierte. Dies löste einen Preinstall-Hook aus, der eine native Linux-Binärdatei auf das System brachte.

Die Schadsoftware

Bei der Payload handelt es sich um einen in Rust geschriebenen Credential-Stealer. Die Malware sucht gezielt nach wertvollen Zielen auf Entwickler-Workstations und CI/CD-Runnern. Sie greift SSH-Artefakte, Browser-Cookies, GitHub-Tokens und Zugangsdaten für HashiCorp Vault abgegriffen. Ziel ist es, die Schlüssel zu erlangen, die den Zugang zu Unternehmens-Infrastrukturen öffnen.

Auf Systemen, auf denen die Malware Root-Rechte erlangte, installierte sie ein eBPF-Rootkit. Die eBPF-Technologie (Extended Berkeley Packet Filter) ermöglicht es, Code direkt im Linux-Kernel auszuführen. Das Rootkit verbarg die Schadprozesse, Dateiaktivitäten und Netzwerk-Sockets vor gängigen Monitoring-Tools. Das infizierte AUR-Paket nachträglich zu deinstallieren, bereinigt das System nicht. Das Rootkit sichert den dauerhaften Zugriff.

Die Auswirkungen

Arch Linux stoppte Neuregistrierungen im AUR, um die Ausbreitung einzudämmen. Die Community reagierte schnell und entwickelte Diagnose-Skripte, mit denen Nutzer ihr Risiko einschätzen können. Entwickler können ihre Systeme mit dem Tool aur-malware-check überprüfen, das unter https://github.com/lenucksi/aur-malware-check bereitsteht. Liefert das Tool keine Hinweise auf eine Infektion, ist das System sauber.

Selbst ein negatives Ergebnis verlangt genaues Hinsehen. Eine Diskussion auf Reddit (https://www.reddit.com/r/archlinux/comments/1u6soq7/got_a_critical_verdict_from_atomicarchcheck_heres/) verdeutlichte, dass der Scanner nach zwischengespeicherten Build-Dateien in Verzeichnissen wie ~/.cache/yay/ sucht. Ein als kritisch eingestufter alter Install-Hook kann schlicht das Überbleibsel eines Pakets sein, das lange vor dem eigentlichen Angriffsfenster vom 10. bis 12. Juni installiert und wieder entfernt wurde. Ein Blick in die Pacman-Logs bringt Klarheit, ob ein markiertes Paket während des Vorfalls aktiv war.

Für Systeme, bei denen der Scanner eine aktive Infektion bestätigt, bleibt das Neuaufsetzen des Hosts über saubere Medien und das Ändern aller potenziell abgeflossenen Zugangsdaten der nötige Schritt. Für alle anderen bietet das Prüfen der Cache-Historie und die Nutzung des Checkers einen verlässlichen Weg, die Sicherheit des Systems zu bestätigen, ohne sofort alles plattmachen zu müssen.

Die Atomic-Arch-Kampagne führt vor Augen, dass Angreifer Entwickler gar nicht mehr dazu bringen müssen, neue, unzuverlässige Software zu installieren. Sie übernehmen einfach die Projekte, denen die Entwickler bereits vertrauen.