In questo articolo3
Ascolta
Voce del browser e privacy
Parte solo quando premi Ascolta. Alcune voci possono usare un servizio online. La nuova velocità può applicarsi dal passaggio successivo. Il testo non viene tradotto.
Cosa è successo
Due azioni GitHub di terze parti, actions-cool/issues-helper e actions-cool/maintain-one-comment, erano state compromesse il 18 maggio durante la campagna di attacco alla supply chain chiamata Mini Shai-Hulud. Dopo la scoperta, il team di sicurezza di GitHub le aveva rimosse per impedire che i workflow che le usavano scaricassero malware.
Secondo i ricercatori di Socket, azienda specializzata in sicurezza delle applicazioni, dal 16 al 25 settembre le due azioni sono tornate accessibili con gli stessi tag di rilascio, che puntavano ancora al codice malevolo introdotto a maggio. In pratica, ogni workflow che le richiamava per versione ha ripreso a scaricare ed eseguire il payload.
Il 25 settembre GitHub ha nuovamente disabilitato le azioni, facendo fallire i workflow che le referenziavano invece di eseguire il codice infetto.
Perché è un problema
La campagna Mini Shai-Hulud, scoperta a maggio, ha colpito 323 pacchetti e 639 versioni dell'indice npm, il registro di pacchetti per Node.js, con malware progettato per rubare token, credenziali e segreti degli ambienti di integrazione continua (CI/CD).
Il ripristino delle due azioni senza prima ripulire i tag ha riaperto una finestra di esposizione per tutti i progetti che le usavano. Socket stima che circa 15.000 repository dipendano da issues-helper, anche se non tutti sono stati necessariamente compromessi.
Non è chiaro perché le repository siano state riabilitate senza una verifica preventiva. I ricercatori non hanno ancora stabilito quanti progetti referenzino le azioni con tag mobili invece di un commit fisso, ma sottolineano che si tratta di strumenti usati quasi quotidianamente per la gestione delle issue.
Cosa fare se si è coinvolti
Socket consiglia a chi ha usato queste azioni di cercare i riferimenti nei propri workflow e rimuoverli oppure fissare un commit verificato e pulito. È inoltre opportuno controllare le esecuzioni successive al 16 settembre e ruotare i segreti accessibili ai workflow che hanno usato un tag compromesso.
L'esposizione è iniziata il 16 settembre tra le 11:09 e le 18:16 GMT+2. Chi ha eseguito workflow con queste azioni in quel periodo dovrebbe considerare i propri segreti potenzialmente esposti.
