BleepingComputer a raportat recent cum o vulnerabilitate GitHub, sau posibil o decizie de design, este exploatată de actorii de amenințare pentru a distribui malware folosind URL-uri asociate cu depozitele Microsoft, făcând ca fișierele să pară de încredere.
Se pare acum că GitLab este de asemenea afectat de această problemă și ar putea fi exploatat într-un mod similar.
În timp ce marea parte a activității asociate cu malware era bazată pe URL-urile Microsoft GitHub, această „vulnerabilitate” ar putea fi exploatată cu orice depozit public de pe GitHub sau GitLab, permițând actorilor de amenințare să creeze capcane foarte convingătoare.
Pe baza investigației noastre, am aflat că aceste fișiere – care sunt malware, nu se găseau pe depozitul de cod Microsoft.
Mai degrabă, acestea existau pe CDN-ul GitHub și probabil au fost încărcate de un actor de amenințare care a abuzat funcția de „comentarii” a platformei.
Atunci când lași un comentariu pe un commit sau o solicitare de tragere, un utilizator GitHub poate atașa un fișier (arhive, documente etc), care va fi încărcat pe CDN-ul GitHub și asociat cu proiectul corespunzător folosind un URL unic în acest format: ‘https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}.’
Pentru videoclipuri și imagini, fișierele vor fi stocate sub calea /assets/.
În loc să genereze URL-ul după ce un comentariu este postat, GitHub generează automat linkul de descărcare după ce adăugați fișierul la un comentariu nesalvat, după cum este arătat mai jos. Acest lucru permite actorilor de amenințare să atașeze malware-ul lor la orice depozit fără ca aceștia să știe.
Chiar dacă comentariul nu este de fapt postat sau mai târziu șters de utilizator (sau de un atacator), linkul către fișier rămâne activ.
Sergei Frankoff, de la serviciul de analiză automată a malware-ului UNPACME, a transmis live despre această vulnerabilitate chiar luna trecută, spunând că actorii de amenințare o exploatează activ.
În scurt timp după raportarea noastră, cititorii au remarcat că GitLab nu era imun la această problemă.
BleepingComputer poate confirma că utilizatorii pot într-adevăr exploata funcția de „comentarii” de pe GitLab într-un mod similar.
În testele noastre, am reușit să încărcăm fișiere care ar fi fost încărcate pe CDN-ul GitLab, dar ar fi părut că acestea există în repozitoriile GitLab ale proiectelor populare open source precum Inkscape și Wireshark:
Fișierul folosit în testul nostru este o imagine JPG benignă, redenumită în .exe pentru a demonstra cum, prin exploatarea acestei funcții, actorii de amenințare pot induce în eroare utilizatorii pentru a descărca versiuni software contrafăcute încărcate cu malware.
Formatul urmat de astfel de fișiere încărcate pe CDN-ul GitLab este:
https://gitlab.com/{project_group_namr}/{repo_name}/uploads/{file_id}/{file_name}
File_id-ul aici arată ca un hash MD4 sau MD5 în opoziție cu un identificator numeric simplu.
Asemenea cu GitHub, linkurile de fișiere generate de GitLab ar rămâne active chiar dacă comentariul nu a fost niciodată postat de atacator sau șters ulterior.
GitLab îi îndeamnă pe utilizatori să se autentifice înainte de a putea încărca sau descărca aceste fișiere, dar acest lucru nu împiedică deloc actorii de amenințare să încarce aceste fișiere în primul rând.
Deoarece aproape toate companiile de software folosesc GitHub sau GitLab, această vulnerabilitate permite actorilor de amenințare să dezvolte capcane extrem de ingenioase și de încredere.
De exemplu, un actor de amenințare ar putea încărca un executabil malware în depozitul instalatorului de drivere NVIDIA care pretinde că este un nou driver care rezolvă probleme într-un joc popular. Sau un actor de amenințare ar putea încărca un fișier într-un comentariu al codului sursă Google Chromium și să pretindă că este o nouă versiune de test a browser-ului web.
Aceste URL-uri ar părea, de asemenea, să aparțină depozitelor companiei, făcându-le mult mai de încredere.
În mod regretabil, chiar dacă o companie află că repozitoriile lor sunt abuzate pentru a distribui malware, nu am găsit niciun setări care să le permită să gestioneze sau să șteargă fișierele atașate proiectelor lor.
BleepingComputer a contactat atât GitHub, cât și Microsoft pe joi, 18 aprilie, cu privire la această abuz, dar nu a primit un răspuns. De asemenea, ne-am apropiat de GitLab pentru un comentariu înainte de publicare și așteptăm un răspuns.
Leave a Reply