Juurdepääs andmetele kaug- ja erasektori GitHub'i hoidlatest, mis omavad forke

Ettevõte Truffle Security avaldas rünnakuskeemid, mis põhinevad mitmetel tüüpilistel GitHubi hoidlate kasutamise meetoditel, võimaldades andmeid välja tõmmata eemalsetest hoidlatest, millel on avalikud fork'id või mis on loodud fork'idena.

Juhtme koodide juurdepääs seotud hoidlate fork'ide kaudu tuleneb sellest, et GitHub optimeerimise ja duplikaatide vältimise tõttu salvestab kõik objektid peamise hoidla ja fork'ide vahel koos ning eraldab ainult loogiliselt commit'ide kuuluvuse. Selline salvestamine võimaldab peamise hoidla kaudu vaadata igat commit'it igast fork'ist, kui selle häsht on URL-is selgelt näidatud. Näiteks saab kasutaja luua fork'i hoidlast "/torvalds/linux" ja lisada sinna mis tahes koodi, pärast mida on see kood saadaval otse häsht-linkina hoidlas "/torvalds/linux". Kui hoidla kustutatakse ja vähemalt üks avalik fork on olemas, jäävad kustutatud hoidlast andmed juurdepääsetavaks commit'i häsht'i kaudu.

Pakutakse kolme stsenaariumi, mis esindavad turvaohu:

• Esimene stsenaarium käsitleb olukordi, kus arendajad loovad avalike hoidlate fork'e, lisavad neisse muudatusi, katsetavad ja seejärel kustutavad. Peale koodi väljapaneku, mis ei olnud mõeldud avaldamiseks, kujutab ohtu olukord, kus katsetamise käigus lisatakse näidiskoodifailide koodidesse töötavad API juurdepääsuvõtmed. Sellisel juhul võib ründaja saada juurdepääsu muudatusele commit'i häsht'i kaudu, mis on suunatud pärast fork'i kustutamist peamise hoidla kaudu. Näiteks suudavad teadlased pakutud viisi abil tuvastada 30 töötavat API juurdepääsuvõtit, uurides kolme masinõppega seotud hoidlat, millel on suur hulk fork'e.
• Teine stsenaarium käsitleb juurdepääsu saamist andmetele pärast põhivaru kustutamist, kui sellel varul on loodud forke. Näiteks tuuakse välja juhtum, kus ühe ettevõtte avalikus varus avaldati kogemata töötaja eravedrut, mis võimaldas täieliku juurdepääsu sellele ettevõttele kuuluvatele kõikidele varudele GitHubis. Ettevõte kustutas lekkevaru, kuid võtmed jäävad endiselt kättesaadavaks commit-hash'i kaudu forkite varudes.
• Kolmas stsenaarium on seotud projektide arendamise mudeliga, mis arendab põhiversiooni avalikus varus ja laiendatud eraversiooni privaatsetes. Kui ettevõte algselt arendas projekti privaatsetes varudes ja seejärel pärast koodi avamist muutis selle avalikuks, jätkates samal ajal sise- või laiendatud versiooni arendamist privaatsetes forkides, on võimalik juurdepääs privaatsete forkide muudatustele commit-hashide kaudu avaliku vara kaudu. Siiski on juurdepääs võimalik ainult nende muudatuste jaoks, mis on tehtud privaatsetes forkides enne, kui põhivaru muudeti avalikuks (era- ja avalike varude hoidmine on eraldatud, kuid kuna kaks varu olid privaatset, hoiti commit-e koos, mistõttu jäävad need varusse pärast selle muutmist avalikuks).

Trikk, mis võimaldab juurdepääsu forkide commit'idele põhivaru lingi kaudu, on juba aastaid tuntud ning seda kasutatakse perioodiliselt erinevate naljade ja arendajate eksitamiseks (näiteks loovad naljakad inimesed sellisel viisil aeg-ajalt vale mulje Linuxi tuumareposiitoriumisse tagasivaatamiseks). Vastusena sellistele naljadele on GitHub lisanud hoiatuse, et küsitud commit ei kuulu praegustele harudele ja võib olla seotud forki. Samuti on juurdepääs commit'idele hash'i kaudu igasugustes seotud forkides peetud ohutuks, kuna juurdepääsudel andmetele kaug- ja privaatsetes forkides on vajalik commit-hashi teadmine.

Kohanda SHA-1 algoritmi põhjal genereeritud commit hash'i, millel on 32 sümbolit, ei ole reaalne, kuid selgus, et see ei olegi vajalik. GitHub toetab lühikest viitamist committidele, mis võimaldab adresseerida muudatusi mitme esimese hash'i sümboliga, eeldusel, et teisi commits ei esine. Lühendatud hash'ide aadressimise minimaalne sümbolite arv on 4, mis vastab 65 tuhande kombinatsiooni proovimisele (16^4). Samas ei pruugi proovima hakata, kuna GitHubi API võimaldab ühendada käsitlejatega ürituste püüdmise jaoks, mida kasutavad kolmandate osapoolte projektid, mis peavad arhiivi kõigi toimingute täieliku logiga, kus commit hash'ide teave jääb alles isegi pärast reposte eemaldamist.

Allikas: opennet.ru