Un’estensione VS Code avvelenata ha rubato 3.800 repository interni di GitHub

GitHub sta indagando su un accesso non autorizzato ai suoi repository interni e conferma che un attaccante è riuscito a esfiltrare dati da circa 3.800 di essi. L’intrusione è arrivata attraverso un’estensione avvelenata di Visual Studio Code installata da un dipendente, dando all’attaccante accesso a quella macchina e, da lì, a codice interno che dovrebbe vivere dietro le mura della stessa azienda.

Il confine che GitHub indica, tra repository interni e piattaforma rivolta ai clienti, è l’unica cosa che separa un incidente contenuto da un’emergenza globale di supply chain. GitHub ospita circa 100 milioni di sviluppatori e una porzione significativa del codice open source su cui poggia l’internet moderna. Quando l’azienda parla di “interno”, intende il codice della propria piattaforma, i propri strumenti, la propria configurazione operativa, il materiale con cui GitHub si costruisce e si gestisce da sé. Le organizzazioni dei clienti, le imprese e i repository pubblici e privati che quei clienti tengono su GitHub restano, secondo l’azienda stessa, fuori dal raggio d’impatto di questa intrusione.

Quella distinzione sta facendo un lavoro notevole nella nota pubblicata dall’azienda sul suo account ufficiale di X. “Pur non avendo attualmente alcuna evidenza di impatto sulle informazioni dei clienti conservate al di fuori dei repository interni di GitHub”, recita il testo, “stiamo monitorando attentamente la nostra infrastruttura per eventuali attività successive”. La formulazione è precisa, e la precisione in un avviso di violazione di solito significa che l’indagine è ancora in corso. “Nessuna evidenza di impatto” non equivale a “nessun impatto”. Gli incidenti nelle grandi piattaforme hanno l’abitudine di crescere man mano che l’analisi forense raggiunge l’attività dell’attaccante, e la linea tra sistemi interni e sistemi rivolti ai clienti è raramente un muro fisico pulito. È un insieme di controlli di accesso, credenziali e account di servizio che vanno ragionati uno per uno.

Ti potrebbe interessare ancheUn’IA ha scritto un exploit zero-day funzionante — Google l’ha intercettato per primo

Il meccanismo è la parte di questa storia che dovrebbe preoccupare ogni sviluppatore. Visual Studio Code è l’editor di codice dominante del pianeta, presente in quasi tutte le grandi organizzazioni di ingegneria. Il suo marketplace di estensioni funziona sulla fiducia della comunità: chiunque può pubblicare, e la maggior parte degli ingegneri installa plug-in con la stessa leggerezza con cui aggiunge segnalibri al browser. Un’estensione avvelenata distribuita su quel canale ed eseguita su una macchina di sviluppatore dà all’attaccante accesso a tutto ciò che la sessione di quello sviluppatore può raggiungere: repository, token, registri di pacchetti, servizi interni. Il nome specifico dell’estensione usata in questo caso non è ancora stato reso pubblico, ma lo schema non è nuovo. Nx Console, una popolare estensione di tooling per sviluppatori, ha subito una compromissione simile.

Il gruppo che si fa chiamare TeamPCP ha rivendicato l’intrusione e mette in vendita il dataset su forum clandestini con un prezzo minimo di cinquantamila dollari. L’inquadramento del gruppo, “questo non è un riscatto”, è già di per sé un segnale. Non stanno cercando di estorcere direttamente GitHub. Trattano il codice sorgente interno rubato come gli altri criminali trattano i dump di carte di credito: come merce con compratori. Chi finirà con quell’archivio da 3.800 repository lo pettinerà alla ricerca di credenziali integrate, segreti scolpiti nel codice, dettagli utili ad attaccare l’infrastruttura stessa di GitHub e qualsiasi cosa serva a compromettere bersagli a valle. Allo stesso gruppo viene attribuito anche il worm Mini Shai-Hulud che ha colpito il pacchetto durabletask su PyPI, il che sottolinea il vero sfondo di questa vicenda: gli attacchi alla catena di fornitura dello sviluppo sono passati dallo scenario teorico al mestiere operativo.

La risposta di contenimento di GitHub, nella sua stessa descrizione, è stata rapida. La macchina compromessa è stata isolata. L’estensione malevola è stata rimossa. L’azienda dice di aver ruotato i segreti critici dando priorità alle credenziali a maggior impatto, e che notificherà i clienti coinvolti attraverso i suoi canali di incident response qualora l’indagine si allarghi. La controllata di Microsoft non ha identificato il dipendente di GitHub la cui macchina è stata compromessa, non ha nominato l’estensione e non ha precisato per quanto tempo l’attaccante abbia mantenuto l’accesso prima della rilevazione. Quei dettagli emergono di solito nel rapporto post-incidente più lungo, che arriva settimane dopo la comunicazione iniziale.

Per il resto del settore, la lezione pratica è più semplice di quanto la confezione di threat intelligence faccia sembrare. Ogni organizzazione di ingegneria è a una distanza di una sola installazione superficiale di estensione dallo stesso incidente. Chiunque abbia installato un’estensione VS Code consigliata in un thread di forum ha corso lo stesso rischio piombato addosso a un dipendente di GitHub. Le difese che funzionano sono note e applicate in modo diseguale: limitare l’installazione di estensioni a una allow-list verificata, isolare le macchine degli sviluppatori dalle credenziali di produzione, ruotare i segreti con cadenza rapida. Questa violazione le spingerà in alto nella lista delle priorità nelle aziende che le avevano rimandate.

GitHub non ha dato tempi per un post mortem pubblico completo. Indagini di questa dimensione su piattaforme di questa scala richiedono di solito diverse settimane per far emergere tutta la loro portata, e gli aggiornamenti arriveranno attraverso i canali ufficiali dell’azienda man mano che verranno prodotti. La prossima cosa da osservare è se l’archivio dei 3.800 repository compaia davvero in vendita e a che prezzo si muova il pavimento una volta che il mercato clandestino avrà avuto qualche giorno per esaminare l’indice.

Altri articoli simili

Una scansione di 380.000 app costruite con l’IA ne trova migliaia senza alcuna autenticazione

Un bug di login ha lasciato 70 milioni di siti cPanel aperti a chiunque