Auf der öffentlichen Github-Seite verwalten Softwareentwickler in so genannten Repositories ihren Quellcode und bieten ihn auch dort zum Download an. Zahlreiche Open Source-Projekte sind dort beheimatet. In den letzten Tagen sind jedoch zahlreiche neue Repositories aufgetaucht, die hochgradig verdächtig sind. Es handelt sich dabei oftmals um Eins-zu-Eins-Kopien legitimer Projekte, die um schädliche Funktionen erweitert worden sind. Dort eingebauter Schadcode schickt an eine zusätzlich eingefügte URL zahlreiche sensible Daten an die Drahtzieher, wie etwa Authentifizierungstoken für AWS oder auch kryptografisches Schlüsselmaterial. Das führt dazu, dass Angreifer vollen Zugriff auf das System erhalten, auf dem der kompromittierte Code läuft und dass dort beliebiger Code ausgeführt werden kann.
Sicherheitsforscher Stephen Lacy hat auf Twitter gepostet, dass ein schädlicher Link in über 35.000 Fällen in solchen Repository-Kopien auftaucht.
Unterschätztes Problem?
Die Frage, an welcher Stelle dies eine Bedrohung darstellt, liegt nahe. Eine Kopie, die sonst keine Verbindung zum Original hat, scheint erst einmal kein Problem darzustellen. Ein Faktor relativiert diese Einschätzung jedoch deutlich: Es gibt oft Abhängigkeiten unter verschiedenen auf Github geposteten Programmen. Das heißt, um Programm X nutzen zu können, muss noch eine Komponente Y zusätzlich installiert werden. Genau hier liegt das Problem: Sucht jemand nach einer solchen abhängigen Komponente und erwischt dabei die malwarebelastete Variante, sind schlimmstenfalls Funktion und persönliche Daten in Gefahr – selbst wenn die eigentliche Funktionalität des Programms oder der Bibliothek gegeben ist. Das passiert vor allem dann, wenn man nicht genau hinschaut, welches Repository ein*e Entwickler*in erwischt hat und ohne weitere Prüfung installiert.
Vergleichbar ist das in etwa mit manipulierten Entwicklungswerkzeugen von anderen Herstellern, von denen manipulierte und/oder illegitim erworbene Kopien im Umlauf sind. So geschehen vor einigen Jahren mit dem Entwickler-Toolkit von Apple. Auch in anderen Bereichen gab und gibt es immer wieder Parallelen, wie etwa in Containerisierungsplattformen wie Docker. Einen Docker-Container aus zweifelhafter Quelle mit erhöhten Berechtigungen laufen zu lassen kann hier ebenfalls dramatische Auswirkungen auf die Sicherheit haben.
Mittlerweile sind die manipulierten Kopien wieder von Github verschwunden, sodass hier vorerst keine Gefahr mehr besteht. Es können allerdings jederzeit neue Kopien auftauchen.
git vs. Github
Das Versionierungs- und Codeverwaltungsprogramm git bietet die Möglichkeit, auch auf eigener Hardware zu laufen. Wer allerdings seinen Quellcode nicht selbst hosten möchte, kann hier auf die offizielle Github-Plattform zurückgreifen. Diese wird dauerhaft und zeitnah gepflegt und mit Sicherheitsupdates versorgt. Entwicklerteams müssen sich hier nicht noch zusätzlich um die Aktualität ihres Versionierungssystems kümmern. Die PHP-Group hat beispielsweise 2021 beschlossen, von einer selbstgehosteten git-Instanz nach Github zu wechseln.
Was zu tun ist
Wer Github nutzt, sollte also immer darauf achtgeben, nur offizielle Repositories zu nutzen und auch einen Blick darauf zu werfen, wie alt es ist und wie viele Bewertungen es hat. Handelt es sich um ein weit verbreitetes und vielfach eingesetztes Projekt, das aber in einem nur wenige Tage alten Repo liegt und keine Bewertungen hat, dann ist etwas faul. Lacys Kommentar dazu: „Deshalb installiert man nicht einfach so irgendwelche Pakete aus dem Internet“
Anders als in anderen Fällen sind jedoch keine Zugänge zu offiziellen Github- Accounts kompromittiert worden. Nichtsdestotrotz sollte jeder Github-Account mit einer Zweifaktor-Authentifizierung gesichert werden. Die entsprechende Option findet sich in den Kontoeinstellungen unter „Passwort und Authentifizierung“.
