Arch Linux AUR: Gefälschte Pakete starten Malware als Root

Ein Angreifer hat schädliche Pakete in das Arch User Repository (AUR) hochgeladen, die sich als yay und paru ausgaben, zwei weit verbreitete Hilfsprogramme. Bei der Installation führten die Pakete ein entferntes Shell-Skript mit Root-Rechten aus.

Die Pakete wurden am 13. Oktober entdeckt. Veröffentlicht hatte sie ein Nutzer namens "marchos1as", und zwar unter Tippfehler-Namen, die den echten Programmen zum Verwechseln ähnlich sahen.

Was das AUR ist und warum Helfer wichtig sind

Das AUR ist ein von der Community gepflegter Paketindex für Arch Linux und darauf basierende Distributionen. Es stellt keine fertigen Binärdateien bereit. Stattdessen enthält es Build-Skripte, sogenannte PKGBUILDs, mit denen Nutzer Software selbst bauen und installieren. Diese Skripte decken Programme von Drittanbietern und proprietäre Werkzeuge ab, dazu Beta-Versionen und ältere Versionen, die über die offiziellen Kanäle der Distribution nicht mehr erhältlich sind.

Programme wie yay und paru heißen AUR-Helfer. Sie erleichtern das Suchen und Installieren von Paketen aus der Community, deshalb installieren viele Arch-Nutzer sie früh, oft als eines der ersten Programme auf einem neuen System. Das machte sie zu einer attraktiven Tarnung für Angreifer.

Echter Code mit schädlichem Installationsskript

Aufmerksam wurden die Nutzer durch einen Thread auf der Arch-Linux-Mailingliste mit dem Titel "hundreds of aur packages were mass uploaded with malware". Innerhalb weniger Minuten hatten sich Community-Mitglieder die Pakete angesehen und bestätigt, was darin steckte.

Die Pakete enthielten den echten Upstream-Code, ergänzt um ein schädliches Installationsskript. Dieses Skript lud ein entferntes Shell-Skript herunter und führte es mit Root-Rechten aus.

AUR-Maintainer Andreas Reichel beschrieb eines der Pakete im Detail.

"Das Paket gibt sich als schlichte Neuverpackung des legitimen AUR-Helfers 'yay' aus (gleiche Upstream-URL, gleiches Quell-Tarball), doch der Paketname 'yyay' und das schädliche Installations-Scriptlet verraten, dass es sich um eine trojanisierte Nachahmung handelt, die im echten Paket untergehen soll", warnte Reichel.

Weil Quell-URL und Tarball mit dem echten Projekt übereinstimmten, wäre bei einem kurzen Blick auf das Build-Skript nichts Ungewöhnliches aufgefallen. Der schädliche Teil steckte im Installations-Scriptlet, das während der Paketinstallation läuft.

Ein weiterer Maintainer, Emiliano Gandini Outeda, veröffentlichte eine Liste schädlicher Pakete, die auf seinem eigenen System Alarm ausgelöst hatten. Die Funde stammten von Regeln in TrustSight, einem quelloffenen Werkzeug für Anwendungssicherheit, das er entwickelt.

Das AUR-Team sperrte das Konto marchos1as und entfernte die schädlichen Pakete aus dem Repository.

Schadcode über die Wayback Machine

Laut Reichel wurde der Schadcode nicht direkt von einem Server der Angreifer geladen. Stattdessen holte ihn das Installationsskript über eine URL der Wayback Machine. Diese URL verwies auf ein persönliches Repository namens hellscripter/install-scripts, gehostet auf GitFlic, einem russischen Code-Hosting-Dienst.

Mit einem Archivdienst als Zwischenstation können Angreifer ihren Datenverkehr über eine vertrauenswürdige Domain leiten, was den Download weniger verdächtig erscheinen lassen kann.

Mögliche Verbindung zu einem npm-Wurm

Der Name des Repositorys ist schon einmal aufgetaucht. Das Sicherheitsunternehmen SafeDep hat kürzlich eine npm-Kampagne dokumentiert, die es "DirtyBlanket" nannte. Diese Kampagne lud Code aus einem Repository mit demselben Namen, hellscripter/install-scripts, allerdings auf Codeberg.

Die Forscher von SafeDep stießen dabei auf einen Linux-Wurm. Er installierte den Fernzugriffstrojaner CHAOS, getarnt als Schriftarten-Dienst, und schleuste außerdem einen Loader in AUR-Pakete ein.

Ein OSV-Hinweis zu DirtyBlanket führt zudem dieselbe Wayback-Machine- und GitFlic-Domain auf, die auch bei den jüngsten AUR-Uploads zu sehen war.

Diese Überschneidungen sind bemerkenswert, eine Bestätigung, dass die beiden Operationen zusammenhängen, gibt es derzeit aber nicht.

Teil einer Serie von AUR-Angriffen

Es ist nicht das erste Mal in diesem Jahr, dass das AUR ins Visier gerät. Im Juni verbreiteten 400 Pakete Malware zum Diebstahl von Zugangsdaten mit Rootkit-Fähigkeiten. Eine weitere Kampagne im Juli veranlasste das Arch-Team, die Paketübernahme vorübergehend abzuschalten, also den Vorgang, mit dem Nutzer verwaiste Pakete übernehmen können.

Arch-Nutzer, die eines der verdächtigen Pakete installiert haben, sollten davon ausgehen, dass ihr System kompromittiert ist, und sofort Gegenmaßnahmen ergreifen. Da das schädliche Skript als Root lief, hätte der Angreifer auf dem betroffenen Rechner alles verändern können.

Unsere Einschätzung

Das ist die dritte AUR-Kampagne in rund vier Monaten, was darauf hindeutet, dass Angreifer das Repository inzwischen als verlässliches Einfallstor in Linux-Systeme betrachten. Das Modell, das das AUR so nützlich macht, mit offenen Uploads und von Nutzern gebauten Paketen, überlässt die Prüfung auch weitgehend der Community. In diesem Fall reagierte die Community schnell, doch die Entdeckung hing trotzdem davon ab, dass Freiwillige Mailinglisten-Threads lesen und ihre eigenen Werkzeuge laufen lassen.

Die Wahl der Ziele sagt einiges. AUR-Helfer werden früh installiert und genießen breites Vertrauen, und die Kombination aus echtem Upstream-Code und einem versteckten Installations-Scriptlet ist darauf ausgelegt, eine oberflächliche Prüfung zu überstehen. Dasselbe Muster, schädliche Schritte in Installationsskripten zu verstecken, zeigt sich auch bei Kampagnen wie der MALFEX-npm-Malware und bei schädlichen GitHub-Repositorys, die legitim aussehen sollen.

Für Arch-Nutzer heißt die praktische Lehre: Paketnamen genau prüfen und Installationsskripte lesen, nicht nur die Quell-URLs. Es lohnt sich zu beobachten, ob sich die vermutete Verbindung zu DirtyBlanket bestätigt und ob das Arch-Team nach dieser jüngsten Welle strengere Kontrollen für neue Uploads einführt.