Come un singolo token GitHub ha superato il perimetro di un colosso farmaceutico globale

Novo Nordisk mantiene un'infrastruttura di sicurezza multi-livello. L'azienda impiega sistemi avanzati di endpoint detection, segmentazione della rete e un centro operativo di sicurezza dedicato. Queste difese costano milioni di dollari all'anno. Eppure, l'intera architettura è crollata a causa di una singola stringa di testo su un sito web pubblico. La violazione del gigante farmaceutico danese è un caso di studio sul paradosso architettonico del moderno sviluppo software. Un massiccio investimento nella difesa perimetrale è fallito perché un singolo token di autenticazione si trovava nel posto sbagliato.

Ho trascorso anni a comunicare con ricercatori di sicurezza tramite Signal e canali criptati con PGP. La maggior parte di loro non cerca vulnerabilità zero-day complesse in firewall corazzati. Cercano la via di minor resistenza. Nell'incidente di Novo Nordisk, la via è stata un personal access token (PAT) di GitHub ad alti privilegi lasciato nel codice JavaScript lato client su un sottodominio oscuro. Non si è trattato di un attacco sofisticato. È stato un esercizio di scoperta. Una volta che il gruppo di minaccia, noto come FulcrumSec, ha trovato il token a marzo, il perimetro di sicurezza formale è diventato irrilevante. Il token forniva un accesso autenticato. Per i sistemi interni, gli aggressori erano sviluppatori legittimi.

L'anatomia di un'intrusione silenziosa

FulcrumSec ha operato all'interno della rete di Novo Nordisk per più di due mesi prima di essere rilevato. Durante questo periodo, il gruppo ha utilizzato il token GitHub iniziale per clonare repository privati. Questi repository contenevano molto più del semplice codice. Contenevano credenziali secondarie, definizioni di infrastruttura e documentazione interna. Questo è un modello comune nelle intrusioni moderne. Un aggressore usa un piccolo punto d'appoggio per raccogliere segreti più potenti. Non hanno bisogno di sfruttare un bug del software quando hanno le chiavi della porta d'ingresso.

Nel momento in cui Novo Nordisk ha divulgato l'incidente l'11 giugno, gli aggressori avevano esfiltrato 1,3 TB di dati. Questo archivio includeva 700.000 file. Sebbene l'azienda avesse inizialmente descritto l'impatto come limitato a dati di pazienti pseudonimizzati e record di professionisti sanitari, la realtà appare più grave. I dati rubati includono informazioni proprietarie su farmaci commercializzati e non ancora rilasciati, ricerche su studi clinici e modelli di IA interni. FulcrumSec sostiene che le informazioni potrebbero far risparmiare ai concorrenti dai tre ai cinque anni di tempo di sviluppo. Questa è la definizione di un fallimento sistemico. La violazione è passata da un semplice token trapelato alla perdita di proprietà intellettuale fondamentale.

Perché le pipeline di sviluppo sono sistemi di produzione

Le piattaforme di sviluppo sono i sistemi di maggior valore nell'impresa moderna. La maggior parte dei programmi di sicurezza non riconosce questa realtà. Un repository di codice non è più un semplice contenitore per file di testo. È il progetto dell'intero ambiente digitale. Contiene le configurazioni per gli ambienti cloud e le pipeline di distribuzione che inviano il codice ai clienti. Quando un aggressore ottiene l'accesso a un repository, vede il cablaggio dell'organizzazione.

Matt Kimpel, chief information security officer presso Magna5, osserva che gli sviluppatori hanno un accesso permanente ai sistemi che contano di più. Possiedono le credenziali per le pipeline di build e gli ambienti cloud. Questi sistemi si trovano a monte dell'ambiente di produzione. Se un aggressore compromette il codice prima che venga compilato, controlla il prodotto finale. Ciò rende la workstation dello sviluppatore e il repository più critici del server di produzione stesso. Le protezioni tradizionali come le approvazioni dei branch e le revisioni del codice presuppongono che la persona che esegue l'azione sia un dipendente fidato. Se l'identità è compromessa, quegli stessi controlli facilitano l'attacco.

Il rischio invisibile delle identità delle macchine

Le organizzazioni trattano la gestione dei segreti come un problema di strumenti. Acquistano un vault e presumono che il problema sia risolto. L'incidente di Novo Nordisk dimostra che la gestione dei segreti è un problema di identità. Il token GitHub trapelato è un'identità di macchina. A differenza degli account umani, le credenziali delle macchine spesso mancano di proprietari chiari. Non hanno programmi di rotazione coerenti. Frequentemente mancano di un monitoraggio significativo. Questi token persistono per mesi o anni senza cambiamenti.

Shane Barney, CISO di Keeper Security, sottolinea che questa invisibilità trasforma un singolo token in un'intrusione a lungo termine. Quando una credenziale di macchina possiede permessi ampi e nessuno ne monitora l'utilizzo, un aggressore non ha bisogno di elevare i privilegi. L'accesso è già lì. Il raggio d'azione è l'intero ambiente. Questo è il motivo per cui gli aggressori sono rimasti non rilevati per 60 giorni. Non stavano forzando il sistema. Stavano usando il sistema così come era stato progettato per essere usato.

L'emergere di attori di minaccia secondari

Un secondo gruppo di minaccia che si fa chiamare TheUSERS007 ha rivendicato l'accesso ai sistemi Novo Nordisk tra il 5 e il 7 giugno. Questo gruppo ha preso di mira i dati relativi alla ricerca sull'IA. Ciò suggerisce che una volta che si verifica una fuga importante, altri attori iniziano a sondare la stessa infrastruttura. Una singola vulnerabilità in una pipeline di sviluppo spesso indica debolezze sistemiche più ampie. Se uno sviluppatore lascia un token in uno script pubblico, è probabile che altri sviluppatori seguano modelli insicuri simili. La superficie di attacco non è una mappa statica. È un ambiente dinamico dove un errore invita a ulteriori controlli da parte di molteplici avversari.

Questa intrusione secondaria evidenzia il rischio per i modelli di IA interni. Questi modelli rappresentano il futuro della ricerca farmaceutica. Sono costruiti su anni di dati proprietari e massicci investimenti computazionali. La perdita di questi modelli non è solo una violazione dei dati. È una perdita di vantaggio competitivo. L'ambiente digitale non ha mura fisiche. Una volta che la logica del sistema viene esposta attraverso il codice sorgente e i pesi del modello, il danno è permanente.

Passare da strumenti reattivi al controllo proattivo dell'identità

Per mitigare questi rischi, le organizzazioni devono cambiare il modo in cui vedono l'accesso degli sviluppatori. Un vault è una scatola per i segreti. La gestione dell'identità è il controllo di chi può aprire la scatola e per quanto tempo. L'obiettivo è ridurre la durata di vita di ogni segreto. Se un token scade in quattro ore, una fuga in un file JavaScript è un fastidio temporaneo. Se un token dura un anno, una fuga è una catastrofe.

Centralizzare la gestione dei segreti è un passo necessario. Ogni identità nell'ambiente dovrebbe seguire il principio del privilegio minimo. Ciò significa che un token GitHub dovrebbe avere accesso solo ai repository specifici richiesti per un'attività. Non dovrebbe avere permessi amministrativi ampi su tutta l'organizzazione. La rotazione automatizzata garantisce che le credenziali non sopravvivano al loro scopo. Questa disciplina non impedisce a un aggressore di trovare un token, ma limita ciò che può farci.

Passaggi pratici per la sicurezza delle pipeline

Le organizzazioni dovrebbero iniziare con un inventario delle identità non umane. La maggior parte delle aziende non sa quante chiavi API o account di servizio esistano nel proprio ambiente. Non puoi proteggere ciò che non puoi vedere. Questo inventario dovrebbe includere l'ambito di ogni chiave e la data del suo ultimo utilizzo. Molte organizzazioni scoprono che una grande percentuale dei loro token attivi non è più necessaria. Questi segreti orfani sono bersagli di alto valore per gli aggressori.

Il monitoraggio delle identità delle macchine è vitale quanto il monitoraggio degli accessi umani. I team di sicurezza devono stabilire una linea di base del comportamento normale per gli account di servizio. Se un token GitHub solitamente accede a tre repository da un indirizzo IP noto e improvvisamente inizia a clonare 500 repository da una regione diversa, il sistema dovrebbe attivare un avviso. Il rilevamento deve avvenire a livello di identità. Applicare patch al software è importante, ma in un'era in cui le identità sono il bersaglio principale, la visibilità sull'uso delle credenziali è l'unico modo per catturare un intruso silenzioso.

Passaggi per la riduzione immediata del rischio

1. Scansionare tutti gli asset pubblici per segreti esposti. Utilizzare strumenti automatizzati per trovare token, chiavi API e credenziali di database nel codice lato client.
2. Implementare token a breve durata. Sostituire i personal access token a lunga durata con credenziali granulari e limitate nel tempo ogni volta che la piattaforma lo supporta.
3. Controllare i permessi dei repository. Rimuovere l'accesso amministrativo dai token degli sviluppatori. Assicurarsi che nessun singolo token abbia il potere di clonare l'intero codice sorgente.
4. Abilitare la scansione dei segreti nella pipeline CI/CD. Bloccare qualsiasi commit che contenga un segreto in chiaro prima che raggiunga il repository.
5. Monitorare attività anomale nei repository. Impostare avvisi per clonazioni di massa o accessi da posizioni insolite.

Questo incidente ricorda che il perimetro si è spostato. Non è più al limite della rete. Esiste al livello del singolo token e della specifica identità. Se non gestite queste identità con lo stesso rigore dei vostri server di produzione, le vostre difese sono un'illusione.

Fonti: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528: Steal Application Access Token), DataBreaches.net reporting.

Disclaimer: Questo articolo è solo a scopo informativo ed educativo. Non sostituisce un audit di sicurezza informatica professionale o un servizio di risposta agli incidenti.