Compania Truffle Security a publicat scenarii de atac pentru câteva tehnici standard de utilizare a repository-urilor GitHub, care permit extragerea de date din repository-uri la distanță, care au fork-uri publice sau care au fost create ca fork-uri.
Posibilitatea de acces la commit-uri prin hash în toate fork-urile asociate ale repository-ului este cauzată de faptul că GitHub, în scopul optimizării și eliminării duplicatelor, stochează împreună toate obiectele din repository-ul principal și fork-uri, separând logic apartenența commit-urilor. Această stocare permite vizualizarea în repository-ul principal a oricărui commit din orice fork, specificând explicit hash-ul său în URL. De exemplu, un utilizator poate crea un fork al repository-ului '/torvalds/linux' și poate adăuga orice cod, după care acest cod devine disponibil printr-un link direct al hash-ului în repository-ul '/torvalds/linux'. În cazul ștergerii repository-ului, dacă există măcar un fork public, datele din repository-ul șters rămân accesibile prin hash-ul commit-ului.
Se propun trei scenarii care reprezintă o amenințare la adresa securității:
- Primul scenariu abordează situațiile în care dezvoltatorii creează fork-uri ale repository-urilor publice, adaugă modificări în acestea, experimentează și apoi șterg. Pe lângă scurgerea de cod care nu este destinat publicării, pericolul îl reprezintă situația în care, în experimentele cu codul, fișierele exemplare includ chei de acces API funcționale. În acest caz, un atacator poate accesa modificarea prin hash-ul commit-ului, adresat după ștergerea fork-ului prin repository-ul principal. De exemplu, prin metoda propusă, cercetătorii au reușit să identifice 30 de chei de acces API funcționale, studiind trei repository-uri legate de învățarea automată cu un număr mare de fork-uri.
- Al doilea scenariu se referă la posibilitatea de a accesa datele după ștergerea unui depozit primar, dacă pentru acel depozit au fost create fork-uri. Ca exemplu, se aduce în discuție cazul în care cheile secrete ale unuia dintre angajați au fost publicate accidental în depozitul public al unei companii, permițând accesul total la toate depozitele companiei pe GitHub. Compania a șters depozitul de la care s-a realizat scurgerea, dar cheile au rămas în continuare disponibile pentru extragere prin apeluri pe baza hash-ului commit-ului în depozitele cu fork-uri.
- Al treilea scenariu este legat de modelul de dezvoltare a proiectelor care dezvoltă o versiune de bază deschisă într-un depozit public și o versiune extinsă proprietară într-un depozit privat. Dacă compania a dezvoltat inițial proiectul într-un depozit privat, apoi, după deschiderea codului proiectului, l-a transferat în categoria publicelor, dar a continuat dezvoltarea unei versiuni interne închise sau extinse într-un fork privat, există o posibilitate de accesare a modificărilor adăugate în fork-ul privat prin hash-urile commit-urilor din depozitul public. Accesul este posibil doar la modificările adăugate în fork-ul privat înainte de transferul depozitului principal în categoria publicelor (depozitele private și publice sunt separate, dar, când două depozite erau private, commit-urile erau stocate împreună, astfel că au rămas în depozitul după ce a fost transformat în public).
Trucul care permite accesul la commit-uri în fork-urile unui depozit printr-un link către depozitul principal este cunoscut de mulți ani și este utilizat periodic pentru diverse glume și pentru a induce în eroare dezvoltatorii (de exemplu, glumeți creează ocazional o aparență de inserție a backdoor-urilor în depozitul kernel-ului Linux pe GitHub). Ca măsură împotriva acestor glume, GitHub a adăugat un avertisment privind faptul că commit-ul solicitat nu aparține ramurilor din depozitul curent și că este posibil să aparțină unui fork. Totodată, posibilitatea accesării commit-urilor prin hash în orice depozite legate de fork-uri a fost considerată inofensivă, deoarece pentru a accesa datele în fork-uri remote și private este necesară cunoașterea hash-ului commit-ului.
Găsirea unui hash de commit generat pe baza algoritmului SHA-1 și care include 32 de caractere nu este posibilă, dar s-a dovedit că nici nu este necesară. GitHub susține o formă scurtată de referință la commit-uri, care permite adresarea modificărilor în funcție de primele caractere ale hash-ului, dacă nu există suprapuneri cu alte commit-uri. Numărul minim de caractere pentru referința scurtată a hash-ului este 4, ceea ce corespunde unei combinate de 65 de mii de combinații (16^4). Totuși, o astfel de încercare poate să nu fie necesară, deoarece API-ul GitHub permite conectarea de handlers pentru interceptarea evenimentelor, care sunt utilizate de proiecte terțe ce păstrează un registru complet al tuturor operațiunilor, în care informația despre hash-urile commit-urilor rămâne și după ștergerea repositoarelor.
Sursa: opennet.ro
