Das hier ist ein vollständig KI generierter Artikel.

Im Arch User Repository (AUR) sind mehr als 400 Pakete entdeckt worden, die ein Linux-Rootkit und einen Infostealer nachladen. Ziel sind vor allem Entwickler-Workstations und Build-Umgebungen, auf denen Zugangsdaten, Tokens und andere Geheimnisse abgegriffen werden können. Der Vorfall zeigt erneut, wie angreifbar Community-getriebene Software-Supply-Chains sind – insbesondere, wenn Paketübernahmen kaum kontrolliert werden.

Was im AUR passiert ist

Ausgangspunkt ist ein Bericht des Independent Federated Intelligence Network (IFIN). Demnach hat sich ein neuer Maintainer im AUR als vertrauenswürdiger Publisher ausgegeben und infizierte Pakete veröffentlicht. Betroffen sind über 400 Pakete, die über modifizierte Installationsskripte ein bösartiges npm-Paket namens atomic-lockfile nachladen und ausführen.

Das AUR ist ein zentrales Element im Arch-Ökosystem: Es liefert PKGBUILDs für Software, die nicht in den offiziellen Repositories liegt – darunter proprietäre Anwendungen, Beta- und Nightly-Builds, Nischen-Tools und ältere Paketversionen. Gleichzeitig ist das AUR nicht kuratiert wie ein offizielles Repo. Paketübernahmen, verwaiste Pakete und Maintainer-Wechsel sind Alltag – und genau hier setzen Angreifer an.

Technische Details zur Malware

Unabhängige Sicherheitsforscher berichten, dass kompromittierte AUR-Pakete mit Pre- oder Post-Install-Skripten versehen wurden, die npm aufrufen und das Paket atomic-lockfile installieren. In mindestens einer Stichprobe enthielt dieses Paket eine Linux-ELF-Binärdatei mit dem Namen deps, die als Credential Stealer mit optionalen eBPF-Rootkit-Funktionen beschrieben wird.

Die Malware zielt auf eine breite Palette von Zielen ab, typischerweise auf Systemen von Entwicklern und Admins:

  • Browser- und Electron-Anwendungsdaten
  • Slack, Microsoft Teams, Discord und Telegram
  • GitHub-Zugangsdaten und npm-Informationen
  • SSH-Schlüssel und -Konfigurationen
  • HashiCorp-Vault-Tokens
  • Docker/Podman-Konfigurationen und VPN-Material
  • Shell-Historien und weitere lokale „Developer Secrets“

Mit eBPF-Unterstützung kann sich der Schadcode in den Kernel einklinken, Prozesse, Dateien und Netzwerkinterfaces verstecken und so klassische Monitoring- und Forensik-Ansätze aushebeln. Analysen zeigen zudem, dass die Binärdatei Daten archivieren, Multi-Part-Dateien handhaben und HTTP-Uploads durchführen kann – also alle Bausteine für eine vollwertige Exfiltrationskette mitbringt.

Missbrauch von verwaisten und übernommenen Paketen

Ein weiterer Bericht eines Supply-Chain-Sicherheitsanbieters beschreibt, wie der Angreifer gezielt verwaiste AUR-Pakete übernommen hat. Nach der Übernahme wurden die PKGBUILD-Dateien angepasst, um während der Installation ein zusätzliches Skript auszuführen, das wiederum atomic-lockfile nachlädt.

Dieses Muster ist aus anderen Ökosystemen bekannt: In npm, PyPI und ähnlichen Repositories werden verwaiste oder kaum gepflegte Pakete übernommen, um sie in der Lieferkette als Einfallstor zu nutzen. Für Nutzer wirkt der Wechsel oft unauffällig – Name und Zweck des Pakets bleiben gleich, nur die Maintainer-Informationen und die Build-Skripte ändern sich.

Reaktion der Arch-Community

AUR-Maintainer arbeiten daran, alle bösartigen Commits zu identifizieren, die betroffenen Pakete zu bereinigen und die verantwortlichen Accounts zu sperren. In einer Nachricht an die Community wurde dazu aufgerufen, verdächtige oder kompromittierte Pakete aktiv zu melden, damit sie schneller aus dem Verkehr gezogen werden können.

Parallel kursieren Skripte, mit denen sich Systeme auf Spuren von atomic-lockfile prüfen lassen. Diese Tools durchsuchen installierte Pakete, Logs und typische Installationspfade nach Indikatoren für eine Kompromittierung.

Was Arch-Nutzer jetzt tun sollten

Für Nutzer von Arch und Arch-basierten Distributionen ergeben sich daraus mehrere konkrete Schritte:

  • Liste betroffener Pakete prüfen: Über die in den Berichten genannten Paketlisten und IOC-Sammlungen lässt sich abgleichen, ob installierte AUR-Pakete betroffen sind.
  • System auf IOCs scannen: Verfügbare Prüfscripte und Security-Tools einsetzen, um nach atomic-lockfile, verdächtigen eBPF-Objekten und der deps-Binärdatei zu suchen.
  • Credentials rotieren: Wenn ein kompromittiertes Paket installiert war, sollten alle Zugangsdaten und Tokens (SSH, GitHub, Vault, VPN, Messenger, Browser-Logins) erneuert werden.
  • Neuinstallation erwägen: Da ein Rootkit sich tief im System verankern und Bereinigung überstehen kann, ist eine saubere Neuinstallation von Arch oft die sicherste Option.

Als generelle Vorsichtsmassnahme empfiehlt es sich, im AUR nur Paketen zu vertrauen, die eine aktive Maintainer-Community, regelmässige Updates und transparente Historien aufweisen. Ein Blick in PKGBUILD und Install-Skripte vor der Installation ist bei sicherheitskritischen Systemen Pflicht.

Lehren für die Open-Source-Supply-Chain

Der Vorfall unterstreicht, dass Offenheit allein keine Sicherheit garantiert. Community-Repositories wie das AUR sind mächtig, aber auch ein attraktives Ziel für Angreifer, die mit vergleichsweise geringem Aufwand eine grosse Zahl von Systemen erreichen können. Besonders kritisch ist, dass Entwickler- und Build-Umgebungen im Fokus stehen – also genau die Systeme, über die sich weitere Software-Lieferketten kompromittieren lassen.

Für Betreiber und Nutzer von Open-Source-Ökosystemen ergeben sich daraus mehrere Handlungsfelder: strengere Prozesse bei Paketübernahmen, automatisierte Scans von PKGBUILDs und Skripten, bessere Telemetrie über Maintainer-Wechsel und ein stärkeres Bewusstsein dafür, dass „verwaist“ gleichbedeutend mit „angreifbar“ sein kann.

Fazit

Die Kompromittierung von über 400 AUR-Paketen mit einem Rootkit-fähigen Infostealer ist ein deutliches Warnsignal für alle, die auf Arch und andere Rolling-Release-Distributionen setzen. Wer die Flexibilität und Aktualität von Community-Repositories nutzt, muss sich der damit verbundenen Risiken bewusst sein und seine eigenen Prüfprozesse entsprechend anpassen. Für betroffene Systeme gilt: kompromittierte Pakete identifizieren, Zugangsdaten konsequent erneuern und im Zweifel das System neu aufsetzen – alles andere ist ein Spiel mit dem Restrisiko eines versteckten Rootkits.

Quelle: https://www.bleepingcomputer.com/news/security/over-400-arch-linux-packages-compromised-to-push-rootkit-infostealer/