Företaget Truffle Security har publicerat attackscenarier baserat pÄ flera typiska metoder för att arbeta med repositories pÄ GitHub, vilket gör att man kan extrahera data frÄn fjÀrrrepositories som har offentliga forks eller som skapades som forks.
Möjligheten att fÄ tillgÄng till commits via hash i alla relaterade forks av repositories beror pÄ att GitHub, för att optimera och undvika dubbletter, lagrar alla objekt frÄn huvudrepositoryn och forks tillsammans, men separerar logiskt Àgarskapet av commits. Denna typ av lagring gör det möjligt att se vilken commit som helst frÄn en fork i huvudrepositoryn genom att uttryckligen ange dess hash i URL:en. Till exempel kan en anvÀndare skapa en fork av repositoryn "/torvalds/linux" och lÀgga till vilken kod som helst, efter vilket denna kod blir tillgÀnglig via en direkt hash-lÀnk i repositoryn "/torvalds/linux". Om repositoryn tas bort kvarstÄr data frÄn den borttagna repositoryn tillgÀngliga via commit-hashen sÄ lÀnge det finns Ätminstone en offentlig fork.
Tre scenarier föreslÄs som utgör en sÀkerhetshot:
- Det första scenariot berör situationer dÀr utvecklare skapar forks av offentliga repositories, lÀgger till Àndringar i dem, experimenterar och sedan tar bort dem. Utöver lÀckage av kod som inte Àr avsedd för publicering utgör situationen dÀr arbetsnycklar till API:n lÀggs till i exempel pÄ kod under experiment ett allvarligt hot. I sÄdana fall kan en angripare fÄ tillgÄng till Àndringar via commit-hashen, riktad efter att forken tagits bort genom huvudrepositoryn. PÄ det föreslagna sÀttet lyckades forskare identifiera 30 fungerande API-nycklar genom att studera tre relaterade repositories om maskininlÀrning med ett stort antal forks.
- Det andra scenariot handlar om möjligheten att fÄ Ätkomst till data efter att det primÀra förrÄdet har raderats, om det har skapats forkar för detta förrÄd. Ett exempel pÄ detta Àr nÀr en offentlig förrÄd hos ett företag av misstag publicerade de privata nycklarna för en av sina anstÀllda, vilket gav fullstÀndig tillgÄng till alla förrÄd av företaget pÄ GitHub. Företaget raderade förrÄdet dÀr lÀckan skedde, men nycklarna var fortfarande tillgÀngliga för extraktion via förfrÄgningar med kommittens hash i förrÄden med forkar.
- Det tredje scenariot Ă€r kopplat till utvecklingsmodellen för projekt som utvecklar en grundlĂ€ggande öppen version i ett offentligt förrĂ„d och en utökad proprietĂ€r version i ett privat. Om ett företag ursprungligen utvecklade ett projekt i ett privat förrĂ„d och sedan efter att koden öppnades, flyttade det till en offentlig version, men fortsatte att utveckla en stĂ€ngd intern eller utökad version i en privat fork, finns det möjlighet att fĂ„ Ă„tkomst till Ă€ndringar som lagts till i den privata forken genom kommittens hash via det offentliga förrĂ„det. Ă
tkomst Àr endast möjlig till de Àndringar som lagts till i den privata forken innan huvudförrÄdet flyttades till den offentliga kategorin (lagring av privata och offentliga förrÄd Àr uppdelad, men nÀr tvÄ förrÄd var privata lagrades kommittéer tillsammans, och dÀrför finns de kvar i förrÄdet efter att det flyttades till en offentlig kategori).
Tricket att fÄ Ätkomst till kommittéer i forkar av ett förrÄd genom en lÀnk till huvudförrÄdet har varit kÀnt i mÄnga Är och anvÀnds ibland för olika skÀmt och för att vilseleda utvecklare (till exempel skÀmtare skapar periodvis en illusion av att bakdörrar har införts i förrÄdet med Linux-kÀrnan pÄ GitHub). Som en ÄtgÀrd för att motverka sÄdana skÀmt har GitHub lagt till en varning om att den begÀrda kommittén inte tillhör grenarna i det aktuella förrÄdet och kan tillhöra en fork. Samtidigt har möjligheten att fÄ Ätkomst till kommittéer via hash i alla relaterade forkar av förrÄdet betraktats som harmlös, eftersom Ätkomst till data i fjÀrr- och privata forkar krÀver kÀnnedom om kommittens hash.
Att förbereda en commit hash, som Àr baserad pÄ SHA-1 algoritmen och som innehÄller 32 tecken, Àr inte möjligt, men det visar sig att det inte Àr nödvÀndigt. GitHub stödjer en förkortad form av att hÀnvisa till commits, vilket gör det möjligt att adressera Àndringar med hjÀlp av de första tecknen av hashen, sÄ lÀnge det inte finns nÄgra överlappningar med andra commits. Det minimiantal tecken som krÀvs för att förkorta hashen Àr 4, vilket motsvarar en genomsökning av 65 000 kombinationer (16^4). Vid denna tidpunkt kan det hÀnda att genomsökningen inte ens behövs, eftersom GitHub API tillÄter att ansluta hÀndelsehanterare som anvÀnds av tredjepartsprojekt som leder en arkiv med en komplett logg av alla operationer, dÀr informationen om commit hashes förblir kvar Àven efter att repositorier har raderats.
KĂ€lla: opennet.ru
