Arch Linux AUR-Angriff: 400+ Pakete kompromittiert – wie Hacker Build-Skripte für Infostealer und Rootkit nutzten

In den letzten Tagen hat sich ein gezielter Angriff auf die Arch Linux-Community ereignet, der die Vertrauenskette zwischen Entwicklern und Nutzern infrage stellt. Mehr als 400 Pakete im Arch User Repository (AUR) wurden von Angreifern übernommen und deren Build-Skripte so manipuliert, dass beim Kompilieren des Pakets ein Schadprogramm installiert wird. Dieses besteht aus einem Rust-basierten Infostealer, der Entwicklerdaten wie Passwörter, SSH-Schlüssel und Konfigurationsdateien ausspioniert, sowie einem eBPF-Rootkit, das den Angriff dauerhaft verbirgt. Der Vorfall zeigt, wie Angreifer die dezentrale Paketverwaltung von Arch Linux ausnutzen, um sich Zugang zu Entwicklerumgebungen zu verschaffen – ohne eine Schwachstelle in der Software selbst auszunutzen.

Der Angriff nutzt gezielt das Vertrauen aus, das Nutzer in die AUR-Pakete haben. Die kompromittierten Pakete behielten ihre ursprünglichen Namen, Versionsnummern und sogar ihre Commit-Historien bei. Allein die Build-Anweisungen in den PKGBUILD- oder .install-Dateien wurden verändert. Dadurch installierte sich das Schadprogramm unbemerkt, sobald ein Nutzer das Paket kompilierte oder aktualisierte. Besonders gefährdet sind dabei Nutzer, die Pakete ab dem 11. Juni installiert oder auf den neuesten Stand gebracht haben. Die Liste der betroffenen Pakete wächst noch, weshalb eine manuelle Überprüfung dringend empfohlen wird.

Die Angreifer gingen systematisch vor: Sie übernahmen hauptsächlich verlassene Pakete, deren ursprüngliche Maintainer die Projekte nicht mehr betreuten. Anschließend änderten sie die Build-Skripte so, dass beim Kompilieren ein npm-Paket namens atomic-lockfile@1.4.2 nachinstalliert wurde. Dieses Paket enthält einen Hook, der während der Installation ein verstecktes Linux-ELF-Binary namens deps ausführt. Dieses Binary ist der eigentliche Infostealer. Zusätzlich wurden legitime npm-Pakete als Tarnung eingebunden, um den Verdacht zu zerstreuen. Einige der bekannt gewordenen betroffenen Pakete sind alvr und premake-git.

Wie der Infostealer funktioniert und was er sammelt

Sobald das deps-Binary ausgeführt wird, startet es einen Rust-basierten Infostealer, der gezielt nach Entwicklerdaten sucht. Laut einer Analyse des unabhängigen Forschers Whanos sammelt die Malware unter anderem SSH-Schlüssel, GPG-Dateien, Passwort-Manager-Daten und Konfigurationsdateien von Entwicklungsumgebungen. Die gestohlenen Daten werden über eine unverschlüsselte HTTP-Verbindung an einen temporären Server unter temp.sh übertragen. Als Command-and-Control-Server (C2) dient eine Tor-Zwiebeldienst-Adresse, die über einen lokalen Loopback-Proxy angesprochen wird. Dadurch können die Angreifer die Kommunikation verschleiern und den Datenabfluss schwer nachverfolgbar machen.

Die Malware ist darauf ausgelegt, auf Entwicklerarbeitsplätzen und Build-Systemen Fuß zu fassen. Sie installiert sich als persistenter Dienst, um auch nach einem Neustart aktiv zu bleiben. Bei Root-Rechten kopiert sie sich in das Verzeichnis /var/lib/ und registriert sich als Systemd-Service mit der Option Restart=always. Ohne Root-Rechte nutzt sie stattdessen das Heimatverzeichnis des Nutzers und installiert einen Benutzer-Service unter ~/.config/systemd/user/. Diese Vorgehensweise ermöglicht es der Malware, sich auch in eingeschränkten Umgebungen zu etablieren und den Zugriff auf das System langfristig zu sichern.

Das eBPF-Rootkit: Tarnung durch Kernel-Integration

Ein besonders besorgniserregender Aspekt des Angriffs ist die Verwendung eines eBPF-Rootkits. eBPF (Extended Berkeley Packet Filter) ist eine Technologie, die ursprünglich für Netzwerkmonitoring und Leistungsanalyse entwickelt wurde, aber in modernen Linux-Kernen auch für erweiterte Systemaufgaben genutzt wird. Angreifer können eBPF-Programme nutzen, um Kernel-Funktionen zu manipulieren und ihre Aktivitäten vor Sicherheitssoftware und Systemadministratoren zu verbergen.

Das Rootkit integriert sich in den Kernel und filtert bestimmte Systemaufrufe heraus, sodass Prozesse, Dateien und Netzwerkverbindungen der Malware unsichtbar werden. Dadurch kann der Infostealer ungestört weiterlaufen, selbst wenn Sicherheitswerkzeuge wie ps, top oder netstat verwendet werden. Da eBPF-Programme im Kernel ausgeführt werden, sind sie schwer zu erkennen und zu entfernen, ohne das System neu zu starten oder Kernel-Module zu deaktivieren. Dies macht den Angriff besonders hartnäckig und gefährlich für betroffene Systeme.

Warum der AUR besonders anfällig für solche Angriffe ist

Der Arch User Repository (AUR) ist eine Sammlung von Community-Paketen, die von Freiwilligen gewartet werden. Im Gegensatz zu den offiziellen Arch-Repositories, die von den Arch-Entwicklern kontrolliert werden, unterliegen AUR-Pakete keiner zentralen Prüfung. Jeder Nutzer kann Pakete hochladen, ändern oder übernehmen, solange er die Richtlinien einhält. Diese Offenheit ist zwar ein großer Vorteil für die Flexibilität von Arch Linux, macht das Repository aber auch zu einem attraktiven Ziel für Angreifer.

Die Angreifer nutzten gezielt verlassene Pakete, deren ursprüngliche Maintainer das Projekt nicht mehr betreuten. Solche Pakete sind oft veraltet, enthalten Sicherheitslücken oder werden von der Community nicht mehr aktiv überwacht. Durch die Übernahme dieser Pakete konnten die Angreifer das Vertrauen der Nutzer ausnutzen, die auf die Integrität der Pakete vertrauten. Zudem manipulierten sie die Git-Commit-Metadaten, um die Änderungen als legitime Updates erscheinen zu lassen. Ein Arch Linux Trusted User bestätigte später, dass das Konto, das angeblich die Änderungen vorgenommen hatte, nie kompromittiert war – die Änderungen stammten also direkt von den Angreifern.

Wer ist betroffen und was müssen Nutzer jetzt tun?

Der Angriff betrifft alle Nutzer von Arch Linux, die eines der kompromittierten Pakete zwischen dem 11. Juni und dem Zeitpunkt der Entdeckung installiert oder aktualisiert haben. Da die Liste der betroffenen Pakete noch wächst und nicht vollständig veröffentlicht wurde, sollten Nutzer vorsorglich alle kürzlich installierten oder aktualisierten AUR-Pakete überprüfen. Eine einfache Möglichkeit besteht darin, die Paketnamen mit den offiziellen Listen auf den Arch-Wikis oder in den Arch-Mailinglisten zu vergleichen.

Falls ein betroffenes Paket gefunden wird, sollte es sofort deinstalliert und der Quellcode des Pakets überprüft werden. Nutzer sollten auch ihre Systeme auf Anzeichen einer Infektion überprüfen, insbesondere auf unbekannte Systemd-Dienste, Prozesse oder Netzwerkverbindungen. Da die Malware auch SSH- und GPG-Schlüssel stiehlt, sollten Entwickler ihre Zugangsdaten umgehend ändern und die Integrität ihrer Schlüssel überprüfen. Zudem empfiehlt es sich, die betroffenen Systeme von einem sauberen Medium neu zu installieren, um sicherzustellen, dass keine Reste der Malware zurückbleiben.

Wie Arch Linux und die Community auf den Angriff reagiert haben

Nach Bekanntwerden des Angriffs haben die Arch Linux-Entwickler und die Community schnell reagiert. Die kompromittierten Pakete wurden aus dem AUR entfernt und die betroffenen Maintainer informiert. Zudem wurden Warnungen an die Nutzer ausgegeben, die kürzlich Pakete installiert oder aktualisiert haben. Die Arch-Entwickler betonten, dass die offiziellen Arch-Repositories nicht betroffen seien und weiterhin sicher genutzt werden können.

Die Community diskutiert nun über mögliche Verbesserungen der Sicherheitsmaßnahmen für den AUR. Vorschläge reichen von strengeren Prüfungen neuer Pakete über automatische Signaturprüfungen bis hin zur Einführung eines dezentralen Vertrauensmodells, bei dem Nutzer Pakete nur nach manueller Überprüfung installieren. Einige Entwickler schlagen vor, die Build-Skripte stärker zu überwachen oder sogar eine zentrale Prüfstelle für kritische Pakete einzuführen. Diese Diskussionen zeigen, wie wichtig es ist, die Balance zwischen Offenheit und Sicherheit im AUR zu finden.

Was Entwickler und Unternehmen aus dem Angriff lernen können

Der Angriff auf den AUR verdeutlicht, wie Angreifer gezielt Vertrauensketten in Open-Source-Projekten ausnutzen können. Für Entwickler und Unternehmen bedeutet dies, dass sie ihre Build-Prozesse und Abhängigkeiten genau überwachen müssen. Besonders gefährdet sind Projekte, die auf Community-Pakete oder npm-Abhängigkeiten setzen, die nicht zentral kontrolliert werden. Eine Möglichkeit, sich zu schützen, besteht darin, Build-Skripte und Abhängigkeiten regelmäßig zu überprüfen und nur Pakete aus vertrauenswürdigen Quellen zu verwenden.

Unternehmen sollten zudem ihre Entwicklerumgebungen stärker absichern. Dazu gehört die Verwendung von isolierten Build-Umgebungen, regelmäßige Sicherheitsaudits und die Implementierung von Tools zur Erkennung von Anomalien in Build-Prozessen. Zudem ist es ratsam, sensible Daten wie SSH-Schlüssel und Passwörter nicht auf Build-Systemen zu speichern, sondern in separaten, gut geschützten Umgebungen. Der Einsatz von eBPF-basierten Monitoring-Tools könnte helfen, Rootkits und andere versteckte Malware zu erkennen, bevor sie Schaden anrichten.

Fazit: Vertrauen ist gut, Kontrolle ist besser

Der Angriff auf über 400 AUR-Pakete zeigt, wie schnell Vertrauen in Open-Source-Projekten missbraucht werden kann. Die Angreifer nutzten gezielt die Offenheit und Flexibilität des AUR, um sich Zugang zu Entwicklerumgebungen zu verschaffen. Der Vorfall unterstreicht die Notwendigkeit, Build-Prozesse, Abhängigkeiten und Paketquellen regelmäßig zu überprüfen – besonders in Umgebungen, in denen Sicherheit oberste Priorität hat.

Für Nutzer von Arch Linux bedeutet dies, dass sie ihre kürzlich installierten oder aktualisierten AUR-Pakete überprüfen und im Zweifel deinstallieren sollten. Entwickler und Unternehmen sollten ihre Build-Prozesse und Abhängigkeiten kritisch hinterfragen und gegebenenfalls zusätzliche Sicherheitsmaßnahmen ergreifen. Der Angriff mag vorbei sein, aber die Lehren daraus werden die Sicherheitsstrategien in der Open-Source-Community nachhaltig prägen.