Ein Sicherheitsforscher hat per selbstgeschriebenem Skript 10.000 GitHub-Repositories aufgespürt, die Trojaner verteilen. Die Repositories stammen scheinbar von verschiedenen Personen, tragen unterschiedliche Namen und sind keine Forks, folgen aber alle demselben Muster. Für Entwicklerteams im Mittelstand verschiebt der Fund die Frage von „Ist GitHub sicher?“ hin zu „Woher stammt dieses Repository wirklich?“.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
GitHub-Malware tarnt sich hier als legitimer Quellcode. Die Angreifer kopieren neue, unbekannte Projekte samt Commit-Historie und Mitwirkenden, hängen aber in der Readme einen Link zu einem ZIP-Archiv an, das einen Trojaner enthält.
Das Wichtigste in Kürze
- Ein Forscher fand per Skript 10.000 GitHub-Repositories, die als getarnter Quellcode Trojaner verteilen.
- Die Repositories klonen neue Projekte inklusive Commits und Mitwirkender, um Vertrauen vorzutäuschen.
- VirusTotal erkennt nur das ZIP-Archiv selbst als schädlich, nicht den Link darauf.
- GitHub löscht nach Beobachtung des Forschers nur gemeldete Repositories, sucht aber nicht aktiv danach.
Wie funktioniert die Tarnung?
Der Forscher stieß auf eine exakte Kopie seines eigenen Projekts: gleicher Name, gleiche Beschreibung, alle Commits übernommen, er selbst als Mitwirkender gelistet. Nur die Readme trug einen frischen Zusatz, einen Link zu einem ZIP-Archiv. Genau diese kopierte Historie soll Vertrauen erzeugen, weil Besucher echte Profile und eine gewachsene Commit-Liste sehen.
Das ZIP-Archiv enthält vier Dateien, darunter eine cmd-Datei, eine ausführbare exe-Datei und eine dll. Der Link auf das Archiv bleibt bei VirusTotal unauffällig, erst das Archiv selbst entlarvt den Trojaner. Auffällig ist das Verhalten der Repositories: Alle paar Stunden löschen die Betreiber den letzten Commit und schieben denselben erneut nach, stets mit dem Namen „Update README.md“.
Wie hat der Forscher die Repositories gefunden?
Statt alle 500 Millionen Repositories abzufragen, nutzte der Forscher den Dienst gharchive, der sämtliche GitHub-Ereignisse pro Tag bereitstellt. Aus den Push-Ereignissen der letzten Tage filterte das Skript Projekte heraus, die mehrmals täglich nur die Readme ändern und ihre Commits aus einem anderen Repository übernommen haben.
Ein zu enger Zeitfilter lieferte zunächst nur 14 Treffer. Nach Anpassung auf Repositories, die zwischen ein- und 24-mal pro Tag aktualisiert werden, fand das Skript 40.000 Kandidaten, von denen 10.000 exakt dem Schadmuster entsprachen. Ein Viertel der gefundenen Projekte trug also ein Trojaner-Archiv, viele davon seit Monaten, einige seit über einem Jahr.
GitHub hat die Werkzeuge, um eine halbe Milliarde Repositories zu durchsuchen, und überlässt die Arbeit trotzdem einem einzelnen Forscher mit gedrosseltem API-Zugang. Vertrauen in eine Plattform ersetzt keine eigene Herkunftsprüfung.
— Markus Seyfferth, Chefredakteur Dr. Web
Was sollten DACH-Entwicklerteams jetzt tun?
Die Kampagne zielt auf Menschen, die über Suchmaschinen oder GitHub-Tags nach Werkzeugen suchen und ein passend benanntes Projekt finden. Laden Sie ausführbare Dateien niemals aus einem ZIP-Link in einer Readme, sondern beziehen Sie Releases ausschließlich über die offiziellen Release-Seiten der bekannten Projekte. Ein Repository mit kopierter Historie und einem externen Archiv-Download gehört auf die Sperrliste.
Prüfen Sie zusätzlich Ihre internen Beschaffungswege für Open-Source-Software und schulen Sie das Team auf dieses konkrete Muster. Wer die größeren Zusammenhänge der Lieferketten-Angriffe einordnen will, findet im Cybersecurity-Glossar die zentralen Begriffe. Die vollständige Analyse samt Suchmuster hat der Forscher auf Orchid Files veröffentlicht.
