In GitHub speichern Nutzer:innen ihren Code in sogenannten Repositorys. Darin landen sämtliche wichtigen Daten und auch vorhergehende Versionen. Wollen Nutzer:innen etwas austesten, erstellen sie einen sogenannten Fork, stellen diesen auf Privat und können dort ungestört Änderungen vornehmen, ohne dass das Haupt-Repository davon beeinflusst wird.

Viele Forks werden danach auch wieder gelöscht, da sie nur zu Testzwecken erstellt wurden. Normalerweise würden GitHub-Nutzer:innen annehmen, dass diese privaten und gelöschten Forks und Repositorys nie wieder einsehbar sind. Doch das stimmt offenbar nicht.

Wie die Sicherheitsexpert:innen von Truffle Security festgestellt haben, gibt es wohl einen Weg, um diese Repositorys und Forks einzusehen. Der erste Fall ist dabei, dass ihr einen Fork eines öffentlichen Repositorys erstellt. Ihr nehmt Änderungen am Fork vor, löscht diesen aber wieder. Dennoch können alle, die die Hash-Nummer des Commits (also der Änderung) haben, auch nach dem Löschen noch darauf zugreifen. Das beweist Truffle Security auch in einem Video.

Ein ähnliches Problem gibt es bei privaten Repositorys. Erstellt ihr diese zunächst und erstellt sogar einen privaten Fork, könntet ihr davon ausgehen, dass beide Code-Ordner privat bleiben. Veröffentlicht ihr nun das Repository, werden aber sämtliche Änderungen am privaten Fork ebenfalls öffentlich.

Zuletzt gibt es noch eine weitere Sicherheitslücke mit den Forks. Ihr erstellt ein öffentliches Repository und andere GitHub-Nutzer:innen erstellen einen Fork davon. Ihr aktualisiert das Repository immer wieder, entscheidet euch aber irgendwann, es zu löschen. Obwohl die Forks der anderen User:innen nie mit den Updates aktualisiert wurden und euer Repository gelöscht ist, können sie auch auf die neuen Daten künftig zugreifen.

Alles, was sie dafür brauchen, ist, wie erwähnt, das sogenannte Commit Hash. Dabei handelt es sich um eine zufällige Zeichenreihenfolge, über die Änderungen an Repositorys und Forks eindeutig zugeordnet werden können. Ihr gebt sie in die URL ein, um sie auf GitHub aufzurufen. Zwar handelt es sich dabei um eine lange Zeichenfolge, doch gibt es oftmals noch eine verkürzte Version, die minimal vier Zeichen enthalten kann. Und genau diese können durch Brute Force leicht entdeckt werden.

Stellt euch vor, ein Unternehmen stellt die Daten für seine quelloffene Anwendung über GitHub zur Verfügung. Entwickler:innen der Firma erstellen einen Fork dieses Repositorys und probieren darin verschiedene Änderungen mit teilweise geheimen Informationen aus. Dazu können vor allem API-Token zählen, um auf firmeninterne Strukturen zuzugreifen.

Nachdem die Entwickler:innen diesen Fork löschen, gehen sie davon aus, dass die sensiblen Daten ebenfalls verschwinden. In Wahrheit befinden sie sich aber immer noch versteckt auf GitHub und könnten in der Theorie von Angreifer:innen gefunden werden, um dem Unternehmen zu schaden. Selbiges gilt natürlich auch für Privatpersonen, die sensible Daten in ihren GitHub-Repos eingegeben haben.

Einige GitHub-Nutzer:innen berichten, dass sie diese Erkenntnisse bereits vor einiger Zeit an das Unternehmen übermittelt haben. Sie hielten das schon 2018 für einen Bug im System. Allerdings bekamen sie von GitHub die Rückmeldung, dass diese Sicherheitslücke nur ein geringes Risiko berge und man sich dazu entschlossen habe, sie nicht zu schließen.

Dementsprechend müssen sich GitHub-Nutzer:innen selbst vor der Sicherheitslücke schützen. Truffle Security gibt hier vor allem einen Tipp. Ihr solltet eure API-Keys, die in den Repositorys hinterlegt sind, regelmäßig austauschen. Durch den neuen API-Key könnt ihr den alten Keys den Zugang verweigern. So können Dritte keinen Zugriff ergattern.