Das Unternehmen Truffle Security hat Angriffsszenarien veröffentlicht, die mehrere gängige Methoden im Umgang mit Repositories auf GitHub beschreiben. Diese Methoden ermöglichen den Zugriff auf Daten aus entfernten Repositories, die öffentliche Forks haben oder als Forks erstellt wurden.
Der Zugriff auf Commits über den Hash in allen zugehörigen Forks eines Repositories ist möglich, weil 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. Dieses Speichersystem erlaubt es, in dem Hauptrepository jeden Commit aus irgendeinem Fork zu betrachten, indem man seinen Hash in der URL klar angibt. Zum Beispiel kann ein Benutzer einen Fork des Repositories „/torvalds/linux“ erstellen und jeden Code hinzufügen, woraufhin dieser Code über den direkten Hash-Link im Repository „/torvalds/linux“ verfügbar wird. Falls das Repository gelöscht wird, bleiben die Daten des entfernten Repositories über den Commit-Hash zugänglich, solange mindestens ein öffentlicher Fork vorhanden ist.
Drei Szenarien, die eine Sicherheitsbedrohung darstellen, werden angeboten:
- Das erste Szenario behandelt Situationen, in denen Entwickler Forks öffentlicher Repositories erstellen, Änderungen hinzufügen, experimentieren und diese dann löschen. Neben dem Risiko der Offenlegung von Code, der nicht zur Veröffentlichung gedacht ist, besteht die Gefahr, dass während der Experimente in den Beispieldateien API- Zugriffsschlüssel eingebettet werden. In diesem Fall könnte ein Angreifer Zugriff auf Änderungen über den Commit-Hash erhalten, der nach dem Löschen des Forks über das Hauptrepository angesprochen wird. So konnten Forscher beispielsweise auf diese Weise 30 aktive API-Schlüssel identifizieren, indem sie drei mit maschinellem Lernen verbundene Repositories mit einer großen Anzahl von Forks analysierten.
- Das zweite Szenario betrifft die Möglichkeit, auf Daten zuzugreifen, nachdem das ursprüngliche Repository gelöscht wurde, sofern für dieses Repository Forks erstellt wurden. Ein Beispiel hierfür ist der Fall, in dem in einem öffentlichen Repository eines Unternehmens versehentlich die privaten Schlüssel eines Mitarbeiters veröffentlicht wurden, die vollen Zugriff auf alle Repositories dieses Unternehmens auf GitHub ermöglichen. Das Unternehmen hat das Repository, über das die Daten geleakt wurden, gelöscht, aber die Schlüssel sind weiterhin über Abfragen nach dem Commit-Hash in den Forks zugänglich.
- 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. Sollte ein Unternehmen zunächst ein Projekt in einem privaten Repository entwickelt haben und dieses anschließend, nach dem Öffnen des Codes, zu einem öffentlichen Projekt umgewandelt haben, während es die geschlossene interne oder erweiterte Version weiterhin in einem privaten Fork entwickelt, besteht die Möglichkeit, über die Hashes der Commits im öffentlichen Repository auf die Änderungen im privaten Fork zuzugreifen. Dabei ist der Zugriff jedoch nur auf die Änderungen möglich, die vor der Umwandlung des Hauptrepositories in ein öffentliches Projekt in den privaten Fork hinzugefügt wurden (die Speicherorte von privaten und öffentlichen Repositories sind getrennt, aber als beide Repositories privat waren, wurden die Commits gemeinsam gespeichert und sind daher nach der Umwandlung in ein öffentliches Repository im Repository erhalten geblieben).
Der Trick, um auf Commits in Forks eines Repositories über einen Link zum ursprünglichen Repository zuzugreifen, ist seit vielen Jahren bekannt und wird gelegentlich für verschiedene Scherze und um Entwickler in die Irre zu führen verwendet (zum Beispiel schaffen es Spaßvögel, auf diese Weise den Anschein zu erwecken, dass sie Backdoors in das Linux-Kernel-Repository auf GitHub einschleusen). Um solchen Scherzen entgegenzuwirken, hat GitHub eine Warnung hinzugefügt, die besagt, dass der angeforderte Commit nicht zu den Branches im aktuellen Repository gehört und möglicherweise einem Fork zugeordnet ist. Gleichzeitig wurde die Möglichkeit, auf Commits über den Hash in allen damit verbundenen Forks des Repositories zuzugreifen, als unbedenklich betrachtet, da für den Zugriff auf Daten in entfernten und privaten Forks das Wissen über den Commit-Hash erforderlich ist.
Es ist zwar unrealistisch, einen Commit-Hash zu finden, der auf dem SHA-1-Algorithmus basiert und 32 Zeichen umfasst, aber es hat sich herausgestellt, dass dies auch nicht erforderlich ist. GitHub unterstützt eine verkürzte Form der Adressierung von Commits, die es ermöglicht, Änderungen anhand der ersten Zeichen des Hashes zu adressieren, solange keine Überschneidungen mit anderen Commits bestehen. Die minimale Anzahl von Zeichen für die verkürzte Adressierung des Hashes beträgt 4, was 65.000 Kombinationen (16^4) entspricht. In vielen Fällen ist ein Durchprobieren möglicherweise nicht notwendig, da die GitHub-API die Einbindung von Handlern ermöglicht, die zur Überwachung von Ereignissen verwendet werden, welche von Drittfirmen, die ein Archiv mit einem vollständigen Protokoll aller Operationen führen, genutzt werden. In diesem Archiv bleibt die Information über die Commit-Hashes auch nach der Löschung der Repositories erhalten.
Quelle: opennet.ru
