„Megalodon“: 5.561 Backdoors auf Github

Mal wieder so ein Massen-Security-Fuckup durch moderne Entwicklungsmethoden.

Diese Woche hatte ich noch von den „Actions“ auf Github geschrieben, und dass ich den Dingern nicht traue, seit einiger Zeit nach einer Alternative suchte. In der Zwischenzeit wurde bekannt, dass da bei Github auch irgendwas angebrannt ist.

Inzwischen ist das auch etwas darüber bekannt, wie hier auf englisch beschrieben, oder hier auf deutsch übersetzt.

Ein Angreifer hat durch „Commits“ (so nennt man in Git einen zusammenhängenden Satz von Änderungen, also jeden Änderungsschritt) Backdoors in 5.561 Git-Repositories der unterschiedlichsten Art eingebaut.

Der springende Punkt: Er hat ihn nicht in die Quelltexte der angegriffenen Repositories eingeschleust, weil das auch schwierig gewesen wäre, weil die ja ganz unterschiedliche Strukturen haben und in verschiedenen Sprachen geschrieben sind, manchmal auch gar kein Programm, sondern vielleicht ein Quelltext eines Buches oder von Webseiten sind. Und da würde es auch auffallen. Der Angreifer hat zu den Github Actions jedes Repositories einen zusätzlichen Workflow eingefügt, was im Normalfall niemandem auffällt, weil die am normalen Inhalt des Repositories nichts ändern und nur eine neue Datei ‎.github/workflows/docker-community-worker-push-latest.yml anlegen, die – Verzeichnis fängt mit Punkt an – in einem beim normalen Arbeiten nicht sichtbaren Unterverzeichnis liegt, für die sich die meisten Leute gar nicht interessieren und die anderen nur selten.

name: Optimize-Build
on:
  workflow_dispatch:

Das Ding wird also erst ausgeführt, wenn der Workflow manuell ausgeführt wird.

Und was macht er?

Normalerweise stehen in diesen Umgebungen, in denen die Workflows ausgeführt werden, je nach verwendeten Programmen, irgendwelche Credentials drin, weil man ja das Ergebnis wie ein compiliertes Programm, ein Package, weiß der Kuckuck, was da gerade produziert wird, irgendwohin hochlädt und dazu Passworte verwendet. Und diese Workflows haben auch vollen Netzzugang. Und dieser Code nun sucht per Regexp in einer Liste typischer Dateien, ob da Credentials (Passworte, ssh-Schlüssel usw.) drinstehen, und lädt sie dann, wenn er per Regexp was findet, per curl auf einen Server hoch.

Das zeigt erhebliche Sicherheitsprobleme mit diesen zu hemdsärmelig entwickelten workflows, in denen zu leichtfertig mit Credentials herumgeworfen wird. Die sind nicht wirklich gut entworfen.

Das Problem daran: So richtig sicher ist man davor auch nicht, wenn man das mit den beschriebenen Github-Alternativen wie Gitea oder Forgejo lokal selbst hostet. Zwar kann der Angreifer da nicht direkt angreifen, aber die Workflows sind „kompatibel“ und machen das, was ich im Artikel schon angesprochen hatte: Sie verwenden Codeschnipsel von irgendwelchen anderen Leuten als Verfahrensteile – und das sogar zwingend, weil oft nicht dokumentiert ist, wie man es selbst macht – und laden diese von Github herunter. Wenn also diese Codeschnipsel, die in den Actions verwendet werden, auf Github kompromittiert sind, können die auch auf lokal gehosteten privaten Repositories wie Gitea oder Forgejo ausgeführt werden. Hochgefährlich. Einfach schlecht.

Eigentlich das alte Standardproblem moderner Entwicklungswerkzeuge, was ich vor Jahren schon an Tools wie Maven oder Cargo kritisiert hatte: Die laden massenhaft Methoden und Libraries und Zeugs von irgendwelchen Quellen von irgendwoher aus dem Internet herunter und führen sie aus. Und keiner weiß so genau, was man da ausführt. Im Prinzip ist das hier dasselbe.

Dabei ist das gar nicht mal so interessant, was die Backdoor genau macht, denn wenn einer drin ist, ist er drin und kann manchen, was er will. Das ist wie beim Wohnungseinbruch: Das ist auch nicht so interessant, was der Einbrecher dann in der Wohnung macht, das kann man sich denken, sondern wie er in die Wohnung reinkommt.

Wie also kann es ein Angreifer schaffen, einen Commit in über 5000 Repositories zu drücken?

Sie sagen wenig dazu:

The attacker used throwaway GitHub accounts with random 8-character usernames (e.g., rkb8el9r, bhlru9nr, lo6wt4t6), set git config to forge the author identity, and pushed via compromised PATs or deploy keys.

Aha. Irgendwie kamen die also an Access Tokens und Deploy Keys. Aber wie sie das gemacht haben, das steht nicht drin. Die müssen vorher also auf andere Weise diese Zugangscredentials zu Github gesammelt haben, und die nun benutzt haben, um einen Schritt weiter zu weiteren Credentials zu kommen, die Zugriff auf weitere Systeme erlauben, auf die Code hochgeladen oder Virtuelle Maschinen konfiguriert werden (z. B. werden auch terraform-Credentials abgegriffen).

Was wiederum heißt, dass das eine Vorbereitungshandlung für weitere Angriffe war und da jetzt Malware in andere Repositories gepumpt worden sein kann.

Das ist auch kein Hobby-Hack, weil das schon recht umfangreich ist, da dürfte eine Organisation dahinterstecken. Ein größerer Angreifer.

Was aber auch heißt, dass dieses ganze System aus Access Tokens und Credentials keine ordentliche Lösung ist, weil man die einfach kopieren kann. Und dass das Konzept der github Actions auch nicht gut ist und dringend verbessert werden müsste.

Wir sind noch ziemlich weit von Sicherheit entfernt.