Microsoft AI ha involontariamente esposto un segreto dando accesso a 38TB di dati confidenziali per 3 anni

La Microsoft AI involontariamente ha svelato un segreto, consentendo l'accesso a 38TB di dati confidenziali per 3 anni

Il team di ricerca di WIZ ha recentemente scoperto che un token SAS sovradimensionato era rimasto esposto su GitHub per quasi tre anni. Questo token permetteva l’accesso a una massiccia quantità di dati privati, pari a 38 terabyte. Questo stoccaggio Azure conteneva anche ulteriori segreti, come chiavi SSH private, nascosti nei backup del disco di due dipendenti di Microsoft. Questa rivelazione sottolinea l’importanza di robuste misure di sicurezza dei dati.

Cosa è successo?

WIZ Research ha recentemente divulgato un incidente di esposizione di dati trovato nel repository AI di Microsoft su GitHub il 23 giugno 2023.

I ricercatori che gestivano il GitHub hanno utilizzato una funzionalità di condivisione di Azure Storage tramite un token SAS per dare accesso a un bucket di dati di addestramento AI open source.

Questo token era configurato in modo errato, permettendo l’accesso a tutto lo storage cloud dell’account anziché al bucket previsto.

• Perché gli umani temono l’Intelligenza Artificiale (AI)?
• Possono i grandi modelli di linguaggio agire e ragionare veramente? I ricercatori dell’Università dell’Illinois a Urbana-Champaign introducono LATS per un miglior processo decisionale
• Analisi dei dati strategici per domande descrittive

Questo storage conteneva 38TB di dati, incluso un backup del disco di due postazioni di lavoro di dipendenti con segreti, chiavi private, password e oltre 30.000 messaggi interni di Microsoft Teams.

I token SAS (Shared Access Signatures) sono URL firmati per la condivisione di risorse di Azure Storage. Sono configurati con controlli dettagliati su come un client può accedere ai dati: quali risorse sono esposte (account completo, contenitore o selezione di file), con quali permessi e per quanto tempo. Vedi la documentazione di Azure Storage.

Dopo aver comunicato l’incidente a Microsoft, il token SAS è stato invalidato. Dalla prima commit su GitHub (luglio 2020) alla revoca, sono trascorsi <strong)quasi anni<="" consulta="" dal="" di="" la="" p="" presentata="" ricerca="" strong).="" team="" timeline="" tre="" wiz:

Tuttavia, come sottolineato dal team di ricerca WIZ, c’è stata una configurazione errata con la firma di accesso condiviso (SAS).

Esposizione dei dati

Il token permetteva a chiunque di accedere a ulteriori 38TB di dati, tra cui dati sensibili come chiavi segrete, password personali e oltre 30.000 messaggi interni di Microsoft Teams provenienti da centinaia di dipendenti di Microsoft.

Ecco un estratto dei dati più sensibili recuperati dal team Wiz:

Come evidenziato dai ricercatori, questo avrebbe potuto consentire a un attaccante di inserire codice maligno nel blob di archiviazione che sarebbe stato eseguito automaticamente con ogni download da parte di un utente (presumibilmente un ricercatore di intelligenza artificiale) fidandosi della reputazione di Microsoft, il che avrebbe potuto portare a un attacco alla catena di fornitura.

Rischi di sicurezza

Secondo i ricercatori, i token SAS dell’account presentati nella loro ricerca rappresentano un alto rischio di sicurezza. Ciò è dovuto al fatto che questi token sono molto permissivi e a lunga durata, sfuggendo al perimetro di monitoraggio degli amministratori.

Quando un utente genera un nuovo token, viene firmato dal browser e non genera alcun evento di Azure. Per revocare un token, un amministratore deve ruotare la chiave dell’account di firma, revocando quindi tutti gli altri token contemporaneamente.

Curiosamente, il rischio di sicurezza di una funzionalità del prodotto Microsoft (i token SAS di Azure) ha causato un incidente per un team di ricerca di Microsoft, un rischio recentemente menzionato dalla seconda versione della matrice delle minacce di Microsoft per i servizi di archiviazione:

Diffusione dei segreti

Questo esempio evidenzia perfettamente il pervasivo problema della diffusione dei segreti all’interno delle organizzazioni, anche quelle con misure di sicurezza avanzate. In modo intrigante, mette in evidenza come un team di ricerca sull’IA, o qualsiasi team di dati, possa creare indipendentemente token che potrebbero mettere a rischio l’organizzazione. Questi token possono aggirare abilmente le salvaguardie di sicurezza progettate per proteggere l’ambiente.

Strategie di mitigazione

Per gli utenti di Azure Storage:

1 – Evitare i token SAS dell’account

La mancanza di monitoraggio rende questa caratteristica una falla di sicurezza nel tuo perimetro. Un modo migliore per condividere dati esternamente è utilizzare un SAS di servizio con una Stored Access Policy. Questa caratteristica lega un token SAS a una policy, fornendo la capacità di gestire centralmente le policy dei token.

Tuttavia, se non hai bisogno di utilizzare questa funzionalità di condivisione di Azure Storage, è sufficiente disabilitare l’accesso SAS per ogni account di tua proprietà.

2 – Abilita Azure Storage Analytics

L’utilizzo di token SAS attivi può essere monitorato attraverso i log di Storage Analytics per ciascuno dei tuoi account di archiviazione. Azure Metrics consente il monitoraggio delle richieste autenticate da SAS e identifica gli account di archiviazione a cui è stato accesso tramite token SAS, per un massimo di 93 giorni.

Per tutti:

1 – Verifica il perimetro GitHub per le credenziali sensibili

Con circa 90 milioni di account sviluppatori, 300 milioni di repository ospitati e 4 milioni di organizzazioni attive, tra cui il 90% delle Fortune 100, GitHub rappresenta una superficie di attacco molto più ampia di quanto si possa pensare.

L’anno scorso, GitGuardian ha scoperto 10 milioni di segreti rivelati nei repository pubblici, un aumento del 67% rispetto all’anno precedente.

GitHub deve essere monitorato attivamente come parte del perimetro di sicurezza di qualsiasi organizzazione. Gli incidenti che coinvolgono credenziali divulgate sulla piattaforma continuano a causare enormi violazioni per le grandi aziende, e questa falla di sicurezza nella protezione di Microsoft non ci ha fatto dimenticare la violazione dei dati di Toyota di un anno fa.

Il 7 ottobre 2022, Toyota, il produttore automobilistico con sede in Giappone, ha rivelato che aveva esposto accidentalmente una credenziale che consentiva l’accesso ai dati dei clienti in un repository pubblico di GitHub per quasi 5 anni. Il codice è stato reso pubblico da dicembre 2017 a settembre 2022.

Se la tua azienda ha team di sviluppo, è probabile che parte dei segreti dell’azienda (chiavi API, token, password) finisca su GitHub pubblico. Pertanto, è vivamente consigliato verificare la superficie di attacco di GitHub come parte del programma di gestione della superficie di attacco.

Parole finali

Ogni organizzazione, indipendentemente dalle dimensioni, deve essere pronta a affrontare una vasta gamma di rischi emergenti. Questi rischi spesso derivano dal monitoraggio insufficiente delle estese operazioni software all’interno delle moderne imprese di oggi. In questo caso, un team di ricerca sull’IA ha creato e accidentalmente esposto un link di condivisione di archiviazione cloud mal configurato, bypassando le barriere di sicurezza. Ma quanti altri dipartimenti – supporto, vendite, operazioni o marketing – potrebbero trovarsi in una situazione simile? La crescente dipendenza dal software, dai dati e dai servizi digitali amplifica i rischi informatici su scala globale.

Combattere la diffusione di informazioni confidenziali e i rischi ad essa associati richiede una rivalutazione delle capacità di supervisione e governance dei team di sicurezza.