Cyber-Angriff auf GitHub-Verzeichnisse, oder: Die Bedrohlichkeit von Supply-Chain-Attacken

Christine Schönig 2020

Von Christine Schönig, Regional Director Security Engineering CER, Office of the CTO bei Check Point Software Technologies GmbH

Nachdem letzte Woche eine Cyber-Attacke auf Tausende GitHub-Verzeichnisse und damit die gesamte Software-Lieferkette dieser Open Source Community bekannt geworden ist, rückte die Bedrohlichkeit von Supply-Chain-Angriffen wieder in das öffentliche Bewusstsein. Im Fall von GitHub konnte die stärkere Ausbreitung des Angriffs verhindert werden, dennoch wirken die Schäden, die ein solcher Angriff nach sich zieht und weiter ziehen kann, einschüchternd.

GitHub wird von über 83 Millionen Entwicklern weltweit genutzt und ermöglicht es ihnen, den Quellcode, den sie dort speichern, zu verfolgen und zu kontrollieren. Die Nutzer von GitHub stellen damit die größte offene Entwickler-Community der Welt dar.

Wie GitHub funktioniert

GitHub ermöglicht es Programmierern, gemeinsam an Code-Repositorys zu arbeiten, sodass andere zu Codes beitragen können, die nicht von ihnen selbst stammen. Dabei hat der Eigentümer des ursprünglichen Codes die volle Kontrolle darüber, ob er die von einem anderen Mitglied der Gemeinschaft vorgenommenen Änderungen akzeptiert oder ablehnt. Dabei ist es üblich, dass Entwickler die Code-Repositorys herunterladen und die Befehlszeilen in ihren eigenen Anwendungen verwenden.

Falls ein Programmierer den Code eines anderen Entwicklers erheblich verändern möchte, dann verwendet er stattdessen die Klon-Funktion von GitHub. Damit kann er eine Kopie erstellen, wobei die ursprüngliche Version unter der Verwaltung des ursprünglichen Autors unangetastet bleibt. Sie behält auch ihre Interaktionsstatistik zu Aufrufen, Beiträgen oder Nutzern, während die geklonte Version unter neuer Leitung steht und keine Interaktionsstatistik hat, da es sich im Grunde um neuen Code handelt.

Über den Angriff

Kürzlich hat also ein Hacker mehr als 35 000 dieser GitHub-Repositorys geklont und sie mit dem ursprünglichen Quell-Code identisch gehalten, aber bösartige Befehlszeilen hinzugefügt. Diese waren in der Lage, ein detailliertes Profil der Umgebung zu sammeln, worin sie ausgeführt wurden. Der Code konnte die Identität des Gerätes, die Identität des Benutzers und möglicherweise andere sensible Daten sammeln. Noch wichtiger ist, dass diese Kodierung die Möglichkeit bot, zusätzlich Malware von einer Web-Seite herunterzuladen. Dieses Schadprogramm konnte jede Anwendung oder Umgebung ausnutzen, die diesen Code aus den Klonen verwendete oder ausführte.

Die Entwickler-Community identifizierte das bösartige Implantat in einer Code-Sammlung, die von GitHub heruntergeladen wurde und befürchtete sofort, dass der Quell-Code aus den ursprünglichen Repositorys ebenfalls mit Malware infiziert worden war. Bei weiteren Untersuchungen stellte sich jedoch heraus, dass wirklich nur die Klone infiziert wurden, weil diese jeden Nutzer täuschen sollten, er lade das Original herunter. Dieser Kniff kann katastrophale Auswirkungen auf die Software-Lieferkette haben, wenn ein Entwickler irrtümlich ein geklontes Code-Repository mit diesem bösartigen Code herunterlädt, es für seine eigenen Zwecke verwendet und dann unwissentlich seinen Benutzern ein mit Malware infiziertes Programm zur Verfügung stellt.

Fazit

Mittlerweile gehen viele Entwickler endlich dazu über, die IT-Sicherheit früh in den Entwicklungsprozess zu integrieren und Sicherheitskräfte mit automatisierten Tools für DevOps auszustatten. So sollen Anwendugen oder Geräte ab Werk einen gewissen Standard an IT-Sicherheit erfüllen. Allerdings geht dieses Umdenken noch zu langsam voran. Der Zwischenfall in GitHub sollte daher als ein Versuch wahrgenommen werden, zahllose Umgebungen und Anwendungen auf so einfache wie hinterlistige Weise anzugreifen. Er ist ein gutes Beispiel, warum die Sicherheit der Software-Lieferkette ebenso wichtig ist, wie die der physischen Lieferkette zwischen Zulieferer und Konzern. IT-Sicherheit ist keine Bremse, wenn sie frühzeitig in die Entwicklung eingebunden wird, sondern eine Versicherung, daß bei Veröffentlichung des Projekts keine böse Überraschung wartet.