Luke Marshall identifică 17.430 secrete expuse pe GitLab și riscul scurgerii credențialelor

Luke Marshall, un specialist în securitate, a examinat 5, 6 milioane de depozite publice găzduite pe GitLab Cloud și a identificat 17.430 de secrete expuse asociate cu 2.804 domenii distincte. Impresionant, dar nu fără precedent: astfel de scurgeri de credențiale au mai apărut pe alte platforme și în seturi folosite pentru antrenarea modelelor AI, ceea ce indică că problema se repetă în ecosistemul dezvoltării software.

Abordarea a fost simplă și eficientă: Marshall a folosit endpointul public al API-ului GitLab pentru a lista toate proiectele, un script Python personalizat pentru a parcurge paginarea și a ordona rezultatele după ID-ul proiectului, iar numele depozitelor au fost trimise către o coadă AWS Simple Queue Service. O funcție AWS Lambda prelua numele, rula instrumentul open-source TruffleHog pentru a căuta chei, tokenuri și parole și înregistra rezultatele. Fiecare invocare Lambda executa un scan TruffleHog cu concurența setată la 1.000, ceea ce i-a permis să analizeze cele 5.600.000 de depozite în puțin peste 24 de ore, cu un cost total de aproximativ 770 de dolari. Da, sumele sunt corecte: munca la scară mare poate fi surprinzător de ieftină dacă știi ce butoane să apeși.

În comparație cu alte investigații, rezultatele sunt notabile: pe Bitbucket același cercetător găsise anterior 6.212 secrete în 2, 6 milioane de depozite, iar în datasetul Common Crawl folosit la antrenarea unor modele AI au fost identificate circa 12.000 de secrete valide. Pe GitLab densitatea secretelor pe depozit a fost cu aproximativ 35% mai mare decât pe Bitbucket, iar numărul total de secrete verificate live a fost aproape triplu. Majoritatea cheilor expuse sunt relativ recente, post-2018, însă au apărut și chei mai vechi, unele din 2009, care sunt încă valabile, semn că riscul nu dispare pur și simplu în timp.

Din perspectiva tipologiei, peste 5.200 dintre secrete au fost credențiale Google Cloud Platform, urmate de chei MongoDB, tokenuri de bot Telegram și chei OpenAI. De asemenea, au fost detectate puțin peste 400 de chei GitLab. Pentru notificarea automată a părților afectate, Marshall a folosit un flux care combina Claude Sonnet 3.7 cu capabilități de căutare web și un script Python pentru a genera e-mailuri, ceea ce a dus și la obținerea unor bug bounty-uri în valoare totală de 9.000 de dolari. Mulți destinatari au revocat credențialele după primirea notificării, dar un număr nedezvăluit de secrete rămâne în continuare expus pe platformă.

Cazul scoate în evidență probleme structurale: cod sursă publicat accidental sau fără curățare, depozite neauditate și instrumente automate capabile să detecteze rapid și la scară largă date sensibile. O scanare completă, relativ ieftină și bine orchestrată poate transforma o colecție uriașă de proiecte publice într-o hartă a expunerilor critice. În același timp, faptul că multe organizații au revocat secrete după notificare demonstrează utilitatea proceselor de divulgare responsabilă, dar și că prevenția în momentul scrierii codului rămâne cel mai eficient filtru.

Luke Marshall a descoperit 17.430 de secrete valide. Această cifră, împreună cu costul total de 770 de dolari și timpul de scanare de puțin peste 24 de ore, ilustrează cât de ușor poate fi evaluată expunerea la scară industrială cu unelte accesibile precum TruffleHog, API-urile publice GitLab și AWS Lambda. Exemple concrete, GCP, MongoDB, Telegram și OpenAI, arată unde ar trebui prioritizate controalele și unde revocările imediate produc efect real. Crezi că organizațiile se pregătesc suficient pentru a preveni astfel de scurgeri sau reacționează doar după ce primesc o notificare?

Fii primul care comentează

Lasă un răspuns

Adresa ta de email nu va fi publicată.


*