Atacul Shai-Hulud de săptămâna trecută a scos la iveală un volum considerabil de secrete digitale după ce a compromis sute de pachete din registrul NPM și a publicat datele furate în aproximativ 30.000 de depozite pe GitHub. Deși nu reprezintă o noutate absolută pentru lanțul de aprovizionare software, amintindu-ne de incidente precum SolarWinds sau de problemele de tip typosquatting în ecosistemul de pachete, această campanie reia aceeași idee: o componentă a unui proiect poate deveni veriga cea mai slabă. Atacul a început ca o campanie auto-propagantă care, încă din septembrie, compromitea pachete NPM pentru a căuta token-uri și alte credențiale cu ajutorul TruffleHog, introducea un script malițios în pachete și publica versiunile modificate în registru.
A doua iterație a atacului a avut un impact mult mai mare: cercetătorii de la Wiz estimează că au fost expuse în jur de 400.000 de secrete brute, iar informațiile au ajuns în 30.000 de depozite GitHub. Doar în jur de 10.000 dintre aceste secrete au fost verificate ca valide de TruffleHog, dar Wiz a observat că peste 60% din token-urile NPM extrase erau încă funcționale la 1 decembrie. Prima undă, apărută la mijlocul lui septembrie, compromisese 187 de pachete, iar în atacul recent au fost afectate peste 800 de pachete dacă se iau în calcul toate versiunile infectate. În plus, varianta 2.0 a malware-ului includea și un mecanism distructiv care putea șterge directorul home al victimei în anumite condiții, o funcționalitate care adaugă un strat suplimentar de risc.
Analiza Wiz dezvăluie și ce tipuri de date au fost expuse. Majoritatea depozitelor conțineau fișiere numite contents.json cu utilizatori GitHub, token-uri și snapshot-uri de fișiere; jumătate dintre ele includeau truffleSecrets.json cu rezultatele scanărilor TruffleHog; aproape 80% conțineau environment.json cu informații despre sistemul de operare, metadate CI/CD, metadata ale pachetelor npm și credențiale GitHub; iar circa 400 de depozite găzduiau actionsSecrets.json cu secrete pentru GitHub Actions. Malware-ul a folosit TruffleHog fără flagul -only-verified, ceea ce înseamnă că multe dintre cele 400.000 de intrări respectă un format cunoscut și pot fi doar zgomot sau, dimpotrivă, pot include credențiale încă valabile. În ciuda nivelului mare de redundanță și a nevoii unei deduplicări serioase, datele conțineau totuși sute de secrete valide, inclusiv token-uri pentru cloud, token-uri NPM și acreditări pentru sisteme de versionare, iar acestea rămân o amenințare reală pentru noi valuri de atacuri.
Datele tehnice oferă context util asupra vectorilor de atac: din 24.000 de fișiere environment.json analizate, cam jumătate erau unice, iar 23% proveneau de pe mașini ale dezvoltatorilor, restul fiind din execuții CI/CD și infrastructuri similare. Majoritatea mașinilor infectate rulau Linux, reprezentând 87%, iar 76% din infecții au fost raportate pe containere. În ceea ce privește platformele CI/CD, GitHub Actions domina informațiile extrase, urmat de Jenkins, GitLab CI și AWS CodeBuild. La nivel de pachete, două exemple au concentrat peste 60% din infecții: @postman/[email protected] și @asyncapi/[email protected]. Modelul de infecție a fost, de asemenea, foarte clar: 99% din cazuri proveneau din evenimentul preinstall, care rula scriptul node setup_bun.js, iar excepțiile par a fi încercări de testare.
Cercetătorii de la Wiz estimează că actorii rău intenționați din spatele Shai-Hulud vor continua să-și perfecționeze tehnicile și anticipează noi valuri de atac, eventual exploatând colecția masivă de credențiale obținute deja. Din acest punct de vedere, impactul ar fi putut fi redus semnificativ dacă câteva pachete cheie, precum cele două dominante, ar fi fost detectate și neutralizate prompt, ceea ce subliniază importanța monitorizării rapide a ecosistemului de pachete și a mecanismelor automate de blocare.
30.000 de depozite GitHub au conținut secrete publicate de atacul Shai-Hulud. Aceasta readuce în discuție subiecte precum gestionarea secretelor în CI/CD, rotația token-urilor și limitarea expunerii prin principiul privilegiului minim, dar și necesitatea unor mecanisme automate care să detecteze rapid pachetele infectate, cum ar fi @postman/[email protected] sau @asyncapi/[email protected]. Exemplul arată că un număr mic de componente poate amplifica semnificativ un atac și că focusul pe curățarea și monitorizarea pachetelor critice, plus implementarea unor politici pentru GitHub Actions și containere, sunt pași practici de urmat.
Ce măsuri crezi că ar trebui să ia echipa ta mai întâi: rotație de token-uri, restricționarea permisiunilor în CI/CD sau scanare continuă a pachetelor din registrul NPM?
Fii primul care comentează