Auf private Daten und gelöschte Inhalte kann dauerhaft zugegriffen werden, GitHub-Beamter: absichtlich gestaltet

Kürzlich schockierte eine Neuigkeit die Open-Source-Community: Auf gelöschte Inhalte auf GitHub und Daten in privaten Repositories kann dauerhaft zugegriffen werden, und dies wurde vom Beamten absichtlich geplant.

Das Open-Source-Sicherheitssoftwareunternehmen Truffle Security hat das Problem in einem Blogbeitrag detailliert beschrieben.

Truffle Security führt einen neuen Begriff ein: CFOR (Cross Fork Object Reference): Wenn ein Repository-Fork Zugriff auf vertrauliche Daten in einem anderen Fork hat (einschließlich Daten aus privaten und gelöschten Forks), liegt eine CFOR-Schwachstelle vor.

Ähnlich wie bei unsicheren direkten Objektreferenzen können Benutzer in CFOR direkt auf Commit-Daten zugreifen, indem sie den Commit-Hash-Wert angeben, andernfalls sind die Daten unsichtbar.

Das Folgende ist der Originalinhalt des Truffle Security-Blogs.

Zugriff auf Daten aus einem gelöschten Fork-Repository

Stellen Sie sich den folgenden Workflow vor:

• Forken Sie ein öffentliches Repository auf GitHub;

• Übertragen Sie den Code in Ihr Fork-Repository;

• Sie löschen Ihr Fork-Repository .

Der Code, den Sie an den Fork übermittelt haben, sollte also nicht zugänglich sein, weil Sie das Fork-Repository gelöscht haben. Es ist jedoch dauerhaft zugänglich und unterliegt nicht Ihrer Kontrolle.

Wie im Video unten gezeigt, forken Sie ein Repository, übermitteln Sie Daten an dieses und löschen Sie dann das Fork-Repository. Anschließend kann über das ursprüngliche Repository auf die „gelöschten“ übermittelten Daten zugegriffen werden.

Diese Situation kommt häufig vor. Truffle Security untersuchte drei häufig geforkte öffentliche Repositories eines großen KI-Unternehmens und fand problemlos 40 gültige API-Schlüssel aus den gelöschten geforkten Repositories.

Zugriff auf Daten aus einem gelöschten Repository:

Sie haben ein öffentliches Repository auf GitHub sie Fork, und sie synchronisieren ihr geforktes Repository niemals mit Ihren Updates.

• Sie löschen das gesamte Repository.

• Dann ist der von Ihnen übermittelte Code weiterhin zugänglich, nachdem der Benutzer Ihr Repository geforkt hat.

GitHub speichert Repositorys und gespaltene Repositorys in einem Repository-Netzwerk, wobei das ursprüngliche „Upstream“-Repository als Root-Knoten fungiert. Wenn ein gegabeltes öffentliches „Upstream“-Repository „entfernt“ wird, weist GitHub die Root-Rolle einem der nachgelagerten gegabelten Repositorys neu zu. Alle Commits aus dem „Upstream“-Repository sind jedoch weiterhin vorhanden und über jedes geforkte Repository zugänglich.

Diese Situation ist nicht einzigartig, so etwas ist letzte Woche passiert:

Truffle Security hat einem großen Technologieunternehmen eine P1-Sicherheitslücke gemeldet, die zeigt, dass ein Mitarbeiter versehentlich den Schlüssel zu einem Konto bei GitHub eingereicht hat kritischer Zugriff auf die gesamte GitHub-Organisation. Das Unternehmen löschte das Repository sofort, aber da das Repository gespalten wurde, waren Commits mit sensiblen Daten immer noch über das gespaltene Repository zugänglich, auch wenn das gespaltene Repository nie mit dem ursprünglichen „Upstream“-Repository synchronisiert wurde.

Das heißt, jeder Code, der in ein öffentliches Repository übertragen wird, ist dauerhaft zugänglich, solange das Repository über mindestens ein Fork-Repository verfügt.

Zugriff auf private Repository-Daten

Berücksichtigen Sie den folgenden Arbeitsablauf:

Sie erstellen ein privates Repository, das schließlich veröffentlicht wird;

Erstellen Sie einen privaten Build dieses Repositorys (über einen Fork) und übergeben Sie zusätzlichen Code für Funktionen, die nicht öffentlich sein sollen;

Sie machen Ihr „Upstream“-Repository öffentlich und halten Ihr Fork-Repository privat.

• Dann stehen private Funktionen und zugehöriger Code zur öffentlichen Ansicht zur Verfügung. Auf jeden Code, der zwischen dem internen Zweig des Repositorys, in dem Sie das Tool erstellt haben, und der Open Source des Tools übertragen wurde, kann über das öffentliche Repository zugegriffen werden.

  Nachdem Sie Ihr „Upstream“-Repository öffentlich gemacht haben, sind alle an Ihrem privaten Fork-Repository vorgenommenen Commits nicht mehr sichtbar. Dies liegt daran, dass eine Änderung der Sichtbarkeit eines privaten „Upstream“-Repositorys zu zwei Repository-Netzwerken führt: eines für die private Version und eines für die öffentliche Version.

  

  Leider ist dieser Workflow eine der am häufigsten von Benutzern und Institutionen verwendeten Methoden bei der Entwicklung von Open-Source-Software. Infolgedessen können vertrauliche Daten versehentlich in öffentlichen GitHub-Repositorys offengelegt werden.

  Wie greife ich auf Daten zu?

  Destruktive Vorgänge im GitHub-Repository-Netzwerk (wie die drei oben genannten Szenarien) entfernen Referenzen zum Festschreiben von Daten aus der Standard-GitHub-Benutzeroberfläche und normalen Git-Vorgängen. Die Daten sind jedoch weiterhin vorhanden und zugänglich (Commit-Hash). Dies ist die Verbindung zwischen CFOR- und IDOR-Schwachstellen.

  

  Commit-Hashes können über die Benutzeroberfläche von GitHub brutal erzwungen werden, insbesondere da das Git-Protokoll die Verwendung kurzer SHA-1-Werte beim Referenzieren von Commits zulässt. Ein kurzer SHA-1-Wert ist die Mindestanzahl an Zeichen, die erforderlich ist, um eine Kollision mit einem anderen Commit-Hash zu vermeiden, mit einem absoluten Minimum von 4. Der Schlüsselraum für alle 4-stelligen SHA-1-Werte ist 65536 (16^4). Brute-Force-Force aller möglichen Werte lässt sich relativ einfach erreichen.

  

  

  Interessanterweise stellt GitHub einen API-Endpunkt für öffentliche Ereignisse bereit. Sie können Commit-Hashes auch in einem von einem Drittanbieter verwalteten Ereignisarchiv abfragen und alle GitHub-Ereignisse der letzten zehn Jahre außerhalb von GitHub aufbewahren, selbst nachdem das Repository gelöscht wurde.

  GitHub Provisions

  Truffle Security übermittelte seine Ergebnisse über das VDP-Programm von GitHub an GitHub-Beamte. GitHub antwortete: „Das ist beabsichtigt“ und fügte die Dokumentation bei.

  

  

  

  Dokumentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks -when-a-repository-is-deleted-or-changes-visibility

  Truffle Security lobt GitHub für die Transparenz seiner Architektur, aber Truffle Security glaubt: Normale Benutzer betrachten die Trennung von privaten und öffentlichen Repositorys als Sicherheitsgrenze, und Öffentliche Benutzer gelten als nicht in der Lage, auf Daten in privaten Repositories zuzugreifen. Leider ist dies, wie oben erwähnt, nicht immer der Fall.

  Truffle Security kam zu dem Schluss, dass alle Commits an dieses Repository-Netzwerk (d. h. Commits im „Upstream“-Repository oder im „Downstream“-Fork-Repository) für immer bestehen bleiben, solange ein Fork-Repository existiert.

  Truffle Security weist außerdem darauf hin, dass die einzige Möglichkeit, kompromittierte Schlüssel in öffentlichen GitHub-Repositories sicher zu reparieren, die Schlüsselrotation ist.

  Die Repository-Architektur von GitHub weist diese Designfehler auf. Leider wird die überwiegende Mehrheit der GitHub-Benutzer nie verstehen, wie die Repository-Vernetzung tatsächlich funktioniert, und dadurch die Sicherheit gefährden.

  ^{Originallink: https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github}

Das obige ist der detaillierte Inhalt vonAuf private Daten und gelöschte Inhalte kann dauerhaft zugegriffen werden, GitHub-Beamter: absichtlich gestaltet. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!