- Auf GitHub kann auf Daten aus gelöschten Forks, gelöschten Repositories und sogar privaten Repositories zugegriffen werden
- GitHub weiß davon, und es ist absichtlich so entworfen
- Da dies für jede Organisation, die GitHub nutzt, einen enormen Angriffsvektor darstellt, wird der neue Begriff „Cross Fork Object Reference (CFOR)“ eingeführt
- Eine CFOR-Schwachstelle liegt vor, wenn ein Repository-Fork auf wichtige Daten eines anderen Forks zugreifen kann, einschließlich Daten aus privaten und gelöschten Forks
Zugriff auf Daten aus gelöschten Forks
- Betrachtet man einen typischen Workflow auf GitHub, kann es vorkommen, dass man ein öffentliches Repository forkt, Code in den Fork committet und den Fork danach löscht
- In den Fork committeter Code ist weiterhin zugänglich und bleibt für immer zugänglich
- Man könnte annehmen, dass dies durch die Notwendigkeit des Commit-Hashs geschützt ist, aber der Hash lässt sich herausfinden
- Daten in gelöschten Forks zu finden, kommt recht häufig vor
Zugriff auf Daten aus gelöschten Repositories
- Betrachtet man ein Szenario, in dem es auf GitHub ein öffentliches Repository gibt, ein Nutzer dieses Repository forkt, nach dem Fork Daten committet und dann das gesamte Repository löscht,
- ist Code, der nach dem Fork committet wurde, weiterhin zugänglich
- GitHub speichert Repositories und Forks in einem Repository-Netzwerk, wobei das ursprüngliche „Upstream“-Repository als Root-Knoten dient
- Wenn das geforkte öffentliche „Upstream“-Repository „gelöscht“ wird, weist GitHub die Rolle des Root-Knotens einem der Downstream-Forks neu zu
- Allerdings existieren weiterhin alle Commits des „Upstream“-Repositorys und sind über alle Forks zugänglich
Zugriff auf Daten aus privaten Repositories
- Betrachtet man einen typischen Workflow, bei dem ein neues Tool auf GitHub Open Source gestellt wird,
- kann es vorkommen, dass man ein privates Repository erstellt, das später veröffentlicht werden soll, davon eine private interne Version erstellt (über einen Fork), zusätzlichen Code für Features committet, die nicht veröffentlicht werden sollen, dann das „Upstream“-Repository öffentlich macht und den Fork privat hält
- Ob private Features und zugehöriger Code (aus Schritt 2) öffentlich sichtbar sind, lässt sich vom öffentlichen Repository aus überprüfen
- Alles, was nach der Veröffentlichung des „Upstream“-Repositorys in den privaten Fork committet wird, ist nicht sichtbar
Wie greift man tatsächlich auf die Daten zu?
- Durch direkten Zugriff auf Commits
- Destruktive Aktionen im Repository-Netzwerk von GitHub (wie die drei oben genannten Szenarien) entfernen Verweise auf Commit-Daten aus der Standard-GitHub-UI und aus gewöhnlichen
git-Operationen
- Diese Daten existieren jedoch weiterhin und sind zugänglich, wenn man den Commit-Hash kennt
- Ein Commit-Hash ist ein SHA-1-Wert. Wenn ein Nutzer den SHA-1-Commit-Hash eines bestimmten Commits kennt, den er sehen möchte, kann er diesen Commit direkt über den Endpunkt
https://github.com/<user/org>/…; aufrufen
- Commit-Hashes können über die GitHub-UI per Brute Force ermittelt werden
- Commit-Hashes lassen sich auch über den Public-Events-API-Endpunkt von GitHub abfragen
GitHubs Richtlinie
- Diese Ergebnisse wurden kürzlich über GitHubs VDP-Programm eingereicht, und GitHub hat klargestellt, dass Repositories absichtlich so funktionieren
- Bei Prüfung der Dokumentation zeigt sich, dass GitHub in den oben dokumentierten Fällen klar beschreibt, was Nutzer erwarten sollten
Auswirkungen
- Solange auch nur ein Fork existiert, bleiben alle Commits in diesem Repository-Netzwerk für immer bestehen, unabhängig davon, ob sie aus dem „Upstream“-Repository oder einem „Downstream“-Fork stammen
- Die Repository-Architektur von GitHub erfordert diesen Designfehler, und die große Mehrheit der GitHub-Nutzer versteht nicht, wie Repository-Netzwerke tatsächlich funktionieren, und ist dadurch schlechter geschützt
- Wenn Secret Scanning weiterentwickelt wird, sodass alle Commits in einem Repository-Netzwerk gescannt werden können, könnte man Warnungen zu Secrets erhalten, die einem gar nicht gehören
- Diese drei Szenarien sind zwar schockierend, decken aber nicht alle Wege ab, auf denen GitHub gelöschte Daten aus Repositories speichern kann
Meinung von GN⁺
- Dieser Artikel wirft für Organisationen, die GitHub nutzen, ein wichtiges Sicherheitsproblem auf. Dass Daten aus gelöschten oder privaten Repositories weiterhin zugänglich sind, ist schockierend. Das wirkt wie ein grundlegender Designfehler, der aus GitHubs Repository-Netzwerk-Architektur resultiert
- Entwickler sollten sich dieses Problems bewusst sein und vorsichtig sein, wenn sie wichtige Daten oder Secrets auf GitHub committen. Sobald etwas in ein öffentliches Repository gepusht wurde, könnte es für immer zugänglich bleiben. Wenn wichtige Secrets offengelegt wurden, lässt sich das letztlich nur vollständig durch Key Rotation beheben
- GitHub legt dieses Problem zwar transparent offen und dokumentiert es, aber die meisten Nutzer werden nicht vollständig verstehen, wie Repository-Netzwerke funktionieren. GitHub sollte mehr tun, um das Bewusstsein für dieses Problem zu schärfen und Nutzer zu schulen
- Ähnliche Probleme könnten auch in anderen Versionsverwaltungssystemen existieren. Entwickler und Organisationen sollten die Architektur und Grenzen der eingesetzten Werkzeuge gut verstehen, wenn sie mit wichtigen Daten arbeiten
- Um die Offenlegung wichtiger Daten zu verhindern, sind mehrschichtige Sicherheitsmaßnahmen erforderlich, darunter strikte Zugriffskontrollen, das Prinzip der geringsten Privilegien sowie regelmäßiges Secret Scanning und Monitoring. Vor allem ist ein hohes Sicherheitsbewusstsein bei Entwicklern entscheidend
1 Kommentare
Hacker-News-Kommentare