Supply-Chain-Attacken
Cyber-Angriff auf GitHub-Verzeichnisse zeigt die Gefahr von Supply-Chain-Attacken
Von Christine Schönig, Regional Director Security Engineering CER, Office of the CTO, bei Check Point Software Technologies GmbH
Nachdem Anfang August 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 weiterziehen 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-Repositories 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-Repositories 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-Repositories geklont und sie mit dem ursprünglichen Quellcode 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 Quellcode aus den ursprünglichen Repositories 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 Anwendungen 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, dass bei Veröffentlichung des Projekts keine böse Überraschung wartet.
