Lunedì 18 maggio GitHub ha rilevato e contenuto una violazione che ha interessato il dispositivo di un dipendente, causata da un’estensione VS Code compromessa pubblicata da una terza parte.

“Ancora una volta il problema non è solo il malware, ma il punto in cui lo abbiamo lasciato entrare: uno strumento di lavoro quotidiano, comodo, familiare, quasi invisibile”, commenta Alessandro Curioni, Presidente e fondatore di DI.GI Academy.

GitHub ha rimosso la versione dannosa dell’estensione, isolando l’endpoint e avviando immediatamente la procedura di risposta all’incidente.

La valutazione attuale delle vittime è che l’attività abbia comportato l’esfiltrazione di soli repository interni a GitHub.

La repository conferma le affermazioni attuali dell’autore dell’attacco, relative a circa 3.800 repository, in linea con quanto emerso finora dalle indagini.

Non ci sono invece prove di un impatto sulle informazioni dei clienti archiviate al di fuori dei repository interni di GitHub, come le aziende, le organizzazioni e i repository dei nostri clienti.

“Episodi come questo ricordano che repository, pipeline CI/CD e integrazioni di terze parti sono a tutti gli effetti superficie d’attacco critica“, secondo Dario Fadda, esperto di cyber sicurezza e collaboratore di Cybersecurity360.

Ecco quali sono i possibili vettori, sapendo che “il caso GitHub conferma che oggi la supply chain software non passa solo da librerie, pacchetti open source o pipeline CI/CD, ma anche dagli strumenti quotidiani degli sviluppatori come estensioni IDE e ambienti locali”, come avverte Sandro Sana, Ethical Hacker e membro Comitato Scientifico Cyber 4.0.

Accessi non autorizzati su GitHub: il rischio è il vettore

Alcuni repository interni di GitHub contengono informazioni dei clienti, per esempio estratti delle interazioni con l’assistenza. Se dovesse emergere un impatto, informeremo i clienti tramite i canali di risposta agli incidenti e di notifica stabiliti.

“Il dato rilevante non è soltanto l’accesso non autorizzato a repository interni, ma il vettore: una componente apparentemente periferica che diventa porta d’ingresso verso asset ad alto valore”, mette in guardia Sandro Sana.

Da un punto di vista tecnico, infatti, “sarà fondamentale capire dalle successive analisi se l’accesso oltre che come noto reperito tramite una estensione di VSCode malevola, sia avvenuto tramite compromissione delle credenziali, abuso di token OAuth o attraverso una catena di fiducia interna“, evidenzia Dario Fadda: “Questi vettori sono ormai tra i più sfruttati negli attacchi moderni, perché consentono movimenti laterali silenziosi e difficili da rilevare, soprattutto in ambienti DevOps altamente automatizzati”.

Ma “è la ‘normalità’ dell’attacco a renderlo pericoloso: solo un’estensione installata dove si scrive codice. Il fattore umano e la complessità della catena digitale restano il terreno preferito degli incidenti, anche quando il bersaglio è tecnicamente sofisticato”, sottolinea Curioni.

Mitigazione del rischio

La piattaforma per developer ha agito tempestivamente per minimizzare i rischi. Lunedì e martedì ha provveduto alla rotazione delle credenziali critiche, dando la priorità a quelle con il maggiore impatto.

“Per le aziende il messaggio è chiaro: la postazione dello sviluppatore va trattata come un asset critico: servono controllo delle estensioni, gestione rigorosa dei secret, minimo privilegio, monitoraggio degli endpoint e governance degli ambienti di sviluppo”, avverte Sandro Sana.

La piattaforma per programmatori continua ad analizzare i registri, a verificare la corretta esecuzione della rotazione delle credenziali e a monitorare la nostra infrastruttura per individuare eventuali attività successive.

“In ottica NIS2 e CRA, la sicurezza del software non è più solo un tema tecnico: è controllo della filiera digitale e gestione del rischio operativo”, suggerisce Sandro Sana.

GitHub adotterà ulteriori misure qualora l’indagine lo richiedesse. Infine pubblicherà un rapporto più completo una volta completata l’indagine.

C’è poi un aspetto culturale: “Molti sviluppatori continuano a sottovalutare la sicurezza degli ambienti di sviluppo rispetto a quella dei sistemi di produzione“, sottolinea Dario Fadda.

In metafora “mi viene da dire che poiché non possiamo impedire alla notte di arrivare sarà utile ricordarsi dove sono gli interruttori che accendono la luce”, conclude Curioni.