Furto del codice interno: GitHub svela nuovi dettagli scioccanti

Mostra sommario Nascondi sommario

• Dettagli tecnici: l’estensione infetta che ha aperto la porta
• Cosa è stato esfiltrato: portata dei danni e informazioni coinvolte
• Chi rivendica l’attacco e il loro passato nelle supply chain
• Tempistica operativa e azioni immediate di contenimento
• Indagine forense e rapporto pubblico atteso
  • Cosa comprenderà l’analisi
• Raccomandazioni per sviluppatori e team di sicurezza

GitHub ha reso pubblici nuovi elementi sull’incursione che ha portato alla sottrazione di circa 3.800 repository interni. L’accesso non autorizzato è stato favorito da un’estensione per VS Code compromessa, installata da un dipendente. L’azienda ha avviato verifiche approfondite e promette un report completo al termine delle indagini.

Dettagli tecnici: l’estensione infetta che ha aperto la porta

L’evento è stato innescato da una versione manomessa dell’estensione Nx Console. I criminali hanno pubblicato la release compromessa, numerata 18.95.0, su due marketplace.

• La build infetta è apparsa sul Visual Studio Marketplace e su OpenVSX.
• Visual Studio ha rimosso l’estensione dopo circa 18 minuti dalla segnalazione.
• OpenVSX ha rimosso la stessa release dopo circa 36 minuti.

L’estensione malevola ha permesso il furto di dati di accesso da parte degli attaccanti. Un dipendente di GitHub aveva installato la versione compromessa, creando il vettore per l’accesso ai repository interni.

Cosa è stato esfiltrato: portata dei danni e informazioni coinvolte

I file trafugati comprendono il codice sorgente di progetti interni. GitHub parla di circa 3.800 repository messi in vendita su forum del cybercrime.

• Tra i contenuti rubati ci sono estratti delle interazioni tra clienti e il team di supporto.
• Le persone interessate da quei file sono state contattate direttamente da GitHub.

Per limitare i rischi, l’azienda ha proceduto a modificare tutte le credenziali compromesse. Secondo il team di sicurezza, si tratta di una misura immediata per ridurre vettori di accesso residui.

Chi rivendica l’attacco e il loro passato nelle supply chain

Il gruppo collegato all’operazione è noto come TeamPCP. Al momento GitHub non conferma ufficialmente tutti i dettagli sugli autori, ma le responsabilità attribuite a TeamPCP sono rilevanti.

In passato il gruppo è stato collegato a violazioni simili contro ecosistemi di pacchetti e container. Tra gli episodi citati:

1. Attacchi a repository su PyPI.
2. Manomissioni di pacchetti su npm.
3. Compromissioni di immagini su Docker.
4. Accesso non autorizzato a un account AWS della Commissione europea.

Tempistica operativa e azioni immediate di contenimento

La sequenza degli eventi è stata sintetizzata così dai tecnici di GitHub:

• Pubblicazione della release infetta sui marketplace.
• Installazione da parte di un dipendente.
• Esfiltrazione delle credenziali e accesso ai repository interni.
• Rimozione rapida della versione infetta dai marketplace.
• Reset di tutte le credenziali interne per bloccare l’accesso.

Queste misure hanno ridotto il rischio immediato. L’attività di risposta include anche la notifica agli utenti coinvolti.

Indagine forense e rapporto pubblico atteso

GitHub ha annunciato che l’indagine proseguirà per ricostruire ogni fase dell’intrusione. Al termine verrà pubblicato un report dettagliato.

Cosa comprenderà l’analisi

• Verifica delle modalità di compromissione dell’estensione.
• Valutazione dell’accesso ai singoli repository.
• Controllo di eventuali backdoor o movimenti laterali.
• Misure aggiuntive di hardening per impedire futuri attacchi supply chain.

Alexis Wales, Chief Information Security Officer di GitHub, ha confermato che si stanno seguendo tutte le piste per identificare impatti ulteriori e soggetti responsabili.

Raccomandazioni per sviluppatori e team di sicurezza

In casi di supply chain è essenziale adottare pratiche difensive robuste. Tra i suggerimenti più urgenti per le organizzazioni:

• Controllare e limitare le autorizzazioni delle estensioni IDE.
• Adottare l’autenticazione a più fattori per gli account con accesso ai repository.
• Monitorare attività insolite e log di accesso ai sistemi sensibili.
• Valutare procedure di verifica delle release prima dell’installazione in ambienti produttivi.

L’episodio conferma come le catene di fornitura software rappresentino una vulnerabilità critica, da gestire con policy e controlli continui.