GhostAction revine: workflow-uri „audit” care fură secrete

Ce este confirmat

Potrivit StepSecurity, pe 8 octombrie contul lui Takashi Kitao (autorul motorului de jocuri pyxel) a fost folosit între 13:20 și 13:44 UTC pentru a împinge workflow-ul în 27 de repository-uri. Între 21:10 și 21:26 UTC, contul lui Henry Wu (henrywoo) a fost folosit pentru 318 repository-uri, dintre care 39 sursă și 279 fork-uri. Ultimul a fost uber/athenadriver, unde commit-ul a mers direct pe master, fără pull request sau revizuire, nesemnat, dar cu identitatea lui Henry Wu. În total, cele două valuri au atins 345 de repository-uri.

Workflow-ul pornește la workflow_dispatch și la orice push, face checkout cu istoric complet, scanează arborele de lucru și fiecare commit de pe fiecare ramură pentru 13 tipare de credențiale (cloud, furnizori de AI, platforme Git și altele) și trimite datele printr-o singură cerere HTTP către o adresă IP fixă. Trimite semnal la fiecare rulare, chiar dacă nu găsește nimic. StepSecurity spune că, la athenadriver, serverul a confirmat cererea la patru secunde după pornire, ceea ce indică exfiltrare; GITHUB_TOKEN al rulării avea doar drept de citire pe conținut, deci escaladarea depinde de secretele furate.

• ▸StepSecurity — GhostAction revine
• ▸The Hacker News — workflow-uri GitHub Actions care fură credențiale
• ▸GitGuardian — campania care nu s-a oprit

Cifrele nu coincid

StepSecurity numără 345 de repository-uri atinse pe 8 octombrie și, printr-o căutare de cod pe 9 octombrie, 378 cu un workflow rău activ pe ramura implicită; dintre acestea, 182 conțin markerul de minare a istoricului și 88 markerul pentru secrete numite. Fork-urile nu sunt numărate, iar cifrele se schimbă zilnic. GitGuardian raportează pentru 31 august – 30 septembrie 772 de repository-uri publice ale 373 de utilizatori și organizații, cu 2.577 de secrete țintite. Din 3.669 de rulări colectate, 499 au fost executate în 32 de repository-uri, iar 336 au reușit, exfiltrând 26 de secrete din 13 repository-uri. Majoritatea rulărilor au fost oprite de aprobări.

Titlul The Hacker News vorbește despre „zeci de mii” de repository-uri, citând Socket, iar corpul articolului menționează peste 340. Nu am putut găsi raportul Socket și nu am putut reconcilia cifrele; folosește cifrele StepSecurity și GitGuardian ca pe cele verificabile.

• ▸StepSecurity — dimensiunea și markerii
• ▸GitGuardian — 772 de repository-uri, 2.577 de secrete țintite

Cum au ajuns la conturi: încă nu se știe

StepSecurity spune că un token scurs este explicația „cea mai plauzibilă”, iar The Hacker News îl leagă „probabil” de jurnale infostealer sau de credențiale scurse. Nu este o concluzie confirmată. GitGuardian notează că commit-urile poartă identitatea victimei, aparent prin credențiale furate, și că rotirea secretelor exfiltrate nu este suficientă: credențialul GitHub folosit pentru injectare trebuie găsit și revocat, altfel poate fi refolosit.

Nu se știe nici răspunsul GitHub, nici identitatea atacatorului, nici câte secrete au fost furate în valul din 8 octombrie. Până la momentul scrierii, nu fuseseră publicate versiuni rău intenționate de pachete.

• ▸StepSecurity — ce lipsește din raport
• ▸GitGuardian — recomandări și necunoscute

Ce cauți în organizația ta

• ▸Fișiere de workflow cu numele security-audit.yml, github_actions_security.yml sau security-check.yml, în orice repository și orice ramură, fork-urile interne incluse.
• ▸Commit-uri cu mesaje de tipul „Add security audit workflow” sau „Trigger security scan”, mai ales nesemnate și împinse direct pe ramura implicită.
• ▸Rulări de workflow începând cu 31 august 2026 care nu corespund unui workflow cunoscut.
• ▸În jurnalele de audit: același mentenant care adaugă în câteva minute fișiere identice în multe repository-uri.
• ▸Telemetrie de rețea din runner-ele CI către adrese IP fixe, pe HTTP simplu. StepSecurity publică adresa și markerii în raportul său; verifică-i acolo.

• ▸StepSecurity — ghid de detecție
• ▸The Hacker News — indicatori și mitigări

Dacă găsești workflow-ul

• ▸Presupune că secretele sunt compromise: rotește toate secretele din Actions și orice credențial care a fost vreodată comis pe orice ramură, nu doar cele din fișierele curente.
• ▸Revocă credențialul GitHub care a permis injectarea, nu doar secretele exfiltrate.
• ▸Șterge workflow-ul de pe toate ramurile și verifică fork-urile repository-urilor infectate.
• ▸Oprește lansările până la curățare și consideră utilizabile de către atacator credențialele de publicare.
• ▸Păstrează rularea, commit-ul, data și lista secretelor rotite, ca să poți dovedi ce ai închis.

• ▸StepSecurity — remediere

Ce a oprit atacul în cazurile documentate

StepSecurity notează că repository-ul typecho-fans cerea aprobare pentru rularea workflow-urilor: rulările declanșate din nou au rămas blocate și exfiltrarea nu a avut loc. GitGuardian observă la rândul lui că majoritatea rulărilor au fost reținute pentru aprobare. Cazul athenadriver arată cealaltă față: contul unui autor original al proiectului a putut scrie direct pe master, fără revizuire. Concluziile practice sunt să ceri aprobare pentru rularea workflow-urilor, să nu permiți push direct pe ramura implicită și să revizuiești periodic cine are drept de scriere.

• ▸StepSecurity — typecho-fans și athenadriver
• ▸GitGuardian — rulările reținute pentru aprobare

Închide alerta cu dovezi

Pentru fiecare organizație sau grup de repository-uri, păstrează rezultatul căutării (fișiere și commit-uri), perioada de loguri verificată, lista secretelor rotite cu data și cine a confirmat, credențialul GitHub revocat și excepțiile rămase, cu motiv și termen. O căutare care a găsit zero rezultate este tot dovadă, dacă îi poți arăta interogarea și data.