{"id":118226,"date":"2024-07-25T15:43:00","date_gmt":"2024-07-25T13:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki"},"modified":"2024-07-25T15:43:00","modified_gmt":"2024-07-25T13:43:02","slug":"dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/dostup-k-dannym-iz-udalyonnyh-i-privatnyh-repozitoriev-na-github-imeyushhih-forki","title":{"rendered":"Zugriff auf Daten aus entfernten und privaten Repositories auf GitHub mit Forks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Unternehmen Truffle Security hat Angriffsszenarien ver\u00f6ffentlicht, die mehrere g\u00e4ngige Methoden im Umgang mit Repositories auf GitHub beschreiben. Diese Methoden erm\u00f6glichen den Zugriff auf Daten aus entfernten Repositories, die \u00f6ffentliche Forks haben oder als Forks erstellt wurden. <\/p>\n
Der Zugriff auf Commits \u00fcber den Hash in allen verwobenen Forks eines Repositories wird durch die Optimierung und die Vermeidung von Duplikaten erm\u00f6glicht, da GitHub alle Objekte aus dem Hauptrepository und den Forks zusammen speichert, w\u00e4hrend die Zugeh\u00f6rigkeit der Commits logisch getrennt wird. Diese Art der Speicherung erlaubt es, jeden Commit aus einem beliebigen Fork im Hauptrepository anzuzeigen, indem man seinen Hash in der URL angibt. Zum Beispiel kann ein Benutzer einen Fork des Repositories '\/torvalds\/linux' erstellen und jeden beliebigen Code hinzuf\u00fcgen, nachdem dieser Code \u00fcber einen direkten Hash-Link im Repository '\/torvalds\/linux' verf\u00fcgbar wird. Bei der L\u00f6schung des Repositories bleiben die Daten aus dem gel\u00f6schten Repository verf\u00fcgbar, wenn es mindestens einen \u00f6ffentlichen Fork gibt, der auf den Commit-Hash verweist. <\/p>\n
Drei Szenarien, die eine Sicherheitsbedrohung darstellen, werden angeboten: <\/p>\n
\n
Das erste Szenario behandelt Situationen, in denen Entwickler Forks \u00f6ffentlicher Repositories erstellen, \u00c4nderungen hinzuf\u00fcgen, experimentieren und diese dann l\u00f6schen. Neben dem Risiko der Offenlegung von Code, der nicht zur Ver\u00f6ffentlichung gedacht ist, besteht die Gefahr, dass w\u00e4hrend der Experimente in den Beispieldateien API- Zugriffsschl\u00fcssel eingebettet werden. In diesem Fall k\u00f6nnte ein Angreifer Zugriff auf \u00c4nderungen \u00fcber den Commit-Hash erhalten, der nach dem L\u00f6schen des Forks \u00fcber das Hauptrepository angesprochen wird. So konnten Forscher beispielsweise auf diese Weise 30 aktive API-Schl\u00fcssel identifizieren, indem sie drei mit maschinellem Lernen verbundene Repositories mit einer gro\u00dfen Anzahl von Forks analysierten.\n
Das zweite Szenario betrifft die M\u00f6glichkeit, auf Daten zuzugreifen, nachdem das urspr\u00fcngliche Repository gel\u00f6scht wurde, sofern f\u00fcr dieses Repository Forks erstellt wurden. Ein Beispiel hierf\u00fcr ist der Fall, in dem in einem \u00f6ffentlichen Repository eines Unternehmens versehentlich die privaten Schl\u00fcssel eines Mitarbeiters ver\u00f6ffentlicht wurden, die vollen Zugriff auf alle Repositories dieses Unternehmens auf GitHub erm\u00f6glichen. Das Unternehmen hat das Repository, \u00fcber das die Daten geleakt wurden, gel\u00f6scht, aber die Schl\u00fcssel sind weiterhin \u00fcber Abfragen nach dem Commit-Hash in den Forks zug\u00e4nglich.
<\/center>\n
Das dritte Szenario bezieht sich auf das Entwicklungsmodell von Projekten, die eine grundlegende Open-Source-Version in einem \u00f6ffentlichen Repository und eine erweiterte propriet\u00e4re Version in einem privaten Repository entwickeln. Sollte ein Unternehmen zun\u00e4chst ein Projekt in einem privaten Repository entwickelt haben und dieses anschlie\u00dfend, nach dem \u00d6ffnen des Codes, zu einem \u00f6ffentlichen Projekt umgewandelt haben, w\u00e4hrend es die geschlossene interne oder erweiterte Version weiterhin in einem privaten Fork entwickelt, besteht die M\u00f6glichkeit, \u00fcber die Hashes der Commits im \u00f6ffentlichen Repository auf die \u00c4nderungen im privaten Fork zuzugreifen. Dabei ist der Zugriff jedoch nur auf die \u00c4nderungen m\u00f6glich, die vor der Umwandlung des Hauptrepositories in ein \u00f6ffentliches Projekt in den privaten Fork hinzugef\u00fcgt wurden (die Speicherorte von privaten und \u00f6ffentlichen Repositories sind getrennt, aber als beide Repositories privat waren, wurden die Commits gemeinsam gespeichert und sind daher nach der Umwandlung in ein \u00f6ffentliches Repository im Repository erhalten geblieben).
<\/center> <\/ul>\n
Der Trick, um auf Commits in Forks eines Repositories \u00fcber einen Link zum urspr\u00fcnglichen Repository zuzugreifen, ist seit vielen Jahren bekannt und wird gelegentlich f\u00fcr verschiedene Scherze und um Entwickler in die Irre zu f\u00fchren verwendet (zum Beispiel schaffen es Spa\u00dfv\u00f6gel, 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\u00fcgt, die besagt, dass der angeforderte Commit nicht zu den Branches im aktuellen Repository geh\u00f6rt und m\u00f6glicherweise einem Fork zugeordnet ist. Gleichzeitig wurde die M\u00f6glichkeit, auf Commits \u00fcber den Hash in allen damit verbundenen Forks des Repositories zuzugreifen, als unbedenklich betrachtet, da f\u00fcr den Zugriff auf Daten in entfernten und privaten Forks das Wissen \u00fcber den Commit-Hash erforderlich ist. <\/p>\n
Es ist zwar unrealistisch, einen Commit-Hash zu bestimmen, der auf dem SHA-1-Algorithmus basiert und 32 Zeichen umfasst, doch das ist auch nicht notwendig. GitHub unterst\u00fctzt eine verk\u00fcrzte Form der Ansprache von Commits, die es erlaubt, \u00c4nderungen anhand der ersten paar Zeichen des Hashes zu adressieren, solange keine \u00dcberschneidungen mit anderen Commits bestehen. Die minimale Anzahl von Zeichen f\u00fcr die verk\u00fcrzte Adressierung eines Hashes betr\u00e4gt 4, was einer Gesamtheit von 65.000 Kombinationen (16^4) entspricht. In vielen F\u00e4llen kann es auch nicht n\u00f6tig sein, diese M\u00f6glichkeiten zu nutzen, da die GitHub-API das Hinzuf\u00fcgen von Handlern erm\u00f6glicht, um Ereignisse abzufangen, die von Drittanbietern verwendet werden, die ein Archiv mit einem vollst\u00e4ndigen Log aller Operationen f\u00fchren, in dem die Informationen \u00fcber die Commit-Hashes auch nach der L\u00f6schung von Repositories erhalten bleiben. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Zugriff](\"\/wp-content\/uploads\/2024\/07\/45381deb03eaa5be40baf8b4dbf7b481.png\")
<\/center>\n![\"Zugriff](\"\/wp-content\/uploads\/2024\/07\/23342cf907bd300699e913297d29b310.png\")
<\/center> <\/ul>\n