Das Unternehmen Truffle Security hat Angriffszenarien für mehrere gängige Methoden veröffentlicht, um Daten aus entfernten GitHub-Repositories zu extrahieren, die öffentliche Forks haben oder als Forks erstellt wurden.
Die Möglichkeit, auf Commits über Hash in allen mit Fork verwobenen Repositories zuzugreifen, ergibt sich daraus, dass GitHub zur Optimierung und zur Vermeidung von Duplikaten alle Objekte aus dem Hauptrepository und den Forks zusammen speichert und nur logisch die Zugehörigkeit der Commits trennt. Diese Art der Speicherung ermöglicht es, jeden Commit aus einem beliebigen Fork im Hauptrepository zu betrachten, indem man seinen Hash in der URL angibt. Beispielsweise kann ein Benutzer ein Fork des Repositories '/torvalds/linux' erstellen und beliebigen Code hinzufügen, nach dem dieser Code über einen direkten Hash-Link im Repository '/torvalds/linux' zugänglich wird. Im Falle der Löschung des Repositories bleiben die Daten des entfernten Repositories über den Commit-Hash zugänglich, wenn es mindestens einen öffentlichen Fork gibt.
Drei Szenarien, die ein Sicherheitsrisiko darstellen, werden vorgeschlagen:
- Das erste Szenario betrifft Situationen, in denen Entwickler Forks öffentlicher Repositories erstellen, Änderungen hinzufügen, experimentieren und diese dann löschen. Neben der Offenlegung von Code, der nicht zur Veröffentlichung bestimmt ist, besteht die Gefahr, dass bei den Experimenten in den Code-Dateien mit Beispielen funktionale API-Zugangsschlüssel hinzugefügt werden. In diesem Fall könnte ein Angreifer Zugriff auf die Änderung über den Commit-Hash erhalten, der nach der Löschung des Forks über das Hauptrepository angesprochen wird. Beispielsweise konnten Forscher auf diese Weise 30 funktionale API-Zugangsschlüssel identifizieren, indem sie drei mit maschinellem Lernen verbundene Repositories mit einer großen Anzahl an Forks untersuchten.
- Das zweite Szenario betrifft die Möglichkeit, nach der Löschung des primären Repositories auf Daten zuzugreifen, wenn für dieses Repository Forks erstellt wurden. Ein Beispiel wird angeführt, bei dem in einem öffentlichen Repository eines Unternehmens versehentlich die geheimen Schlüssel eines Mitarbeiters veröffentlicht wurden, die vollständigen Zugriff auf alle Repositories dieses Unternehmens auf GitHub ermöglichen. Das Unternehmen hat das Repository gelöscht, über das der Leak stattfand, aber die Schlüssel blieben weiterhin über Abfragen nach dem Commit-Hash in den Fork-Repositories abrufbar.
- Das dritte Szenario bezieht sich auf das Entwicklungsmodell von Projekten, die eine grundlegende Open-Source-Version in einem öffentlichen Repository und eine erweiterte proprietäre Version in einem privaten Repository entwickeln. Wenn ein Unternehmen zunächst ein Projekt in einem privaten Repository entwickelte und dieses nach der Veröffentlichung des Quellcodes in ein öffentliches überführte, aber die Entwicklung einer geschlossenen internen oder erweiterten Version in einem privaten Fork fortsetzte, besteht die Möglichkeit, auf die in den privaten Fork hinzugefügten Änderungen über die Commit-Hashes über das öffentliche Repository zuzugreifen. Dabei ist der Zugriff nur auf Änderungen möglich, die vor der Überführung des Hauptrepositories in den öffentlichen Bereich in den privaten Fork aufgenommen wurden (private und öffentliche Repositories werden getrennt gespeichert, aber als zwei Repositories privat waren, wurden die Commits gemeinsam gespeichert und blieben daher im Repository, nachdem es in den öffentlichen Bereich überführt wurde).
Der Trick, der den Zugriff auf Commits in den Forks eines Repositories über einen Link zum Hauptrepository ermöglicht, ist schon seit vielen Jahren bekannt und wird gelegentlich für verschiedene Scherze und Irreführungen von Entwicklern genutzt (zum Beispiel erstellen Scherzbolde regelmäßig eine scheinbare Einfügung von Backdoors in das Repository des Linux-Kerns auf GitHub). Als Maßnahme gegen solche Scherze hat GitHub eine Warnung hinzugefügt, dass der angeforderte Commit nicht zu den Branches im aktuellen Repository gehört und möglicherweise zu einem Fork gehört. Dabei wurde die Möglichkeit, auf Commits über den Hash in allen damit verbundenen Fork-Repositories zuzugreifen, als harmlos angesehen, da für den Zugriff auf Daten in entfernten und privaten Forks das Wissen um den Commit-Hash benötigt wird.
Es ist unrealistisch, den Commit-Hash, der auf dem SHA-1-Algorithmus basiert und 32 Zeichen umfasst, zu finden. Es stellte sich jedoch heraus, dass dies gar nicht erforderlich ist. GitHub unterstützt eine verkürzte Form der Bezugnahme auf Commits, die es ermöglicht, Änderungen anhand der ersten wenigen Zeichen des Hashes zu adressieren, solange es keine Überschneidungen mit anderen Commits gibt. Die Mindestanzahl an Zeichen für die verkürzte Adressierung des Hashes beträgt 4, was 65.000 Kombinationen (16^4) entspricht. Dabei muss eventuell keine Durchsuchung erfolgen, da die GitHub-API die Verbindung von Handlern erlaubt, um Ereignisse abzufangen, die von Drittprojekten verwendet werden, die ein Archiv mit vollständigem Protokoll aller Vorgänge führen, in dem die Informationen über Commit-Hashes nach dem Löschen von Repositories erhalten bleiben.
Quelle: opennet.ru
