Microsoft espone per errore 38 TB di dati riservati appartenenti all'azienda

La divisione Microsoft che si occupa di ricerca in tema di intelligenza artificiale, ha erroneamente fatto trapelare in rete ben 38 TB di dati riservati appartenenti all’azienda di Redmond. L’incidente è venuto a galla in questi giorni, dopo la pubblicazione di una dettagliata analisi tecnica elaborata dai ricercatori di Wiz. Tuttavia Microsoft esponeva per errore i 38 TB di dati riservati non propriamente da “ieri” ma almeno da luglio 2020.

Microsoft ha confermato il problema con una nota ufficiale precisando che un dipendente della sua divisione AI ha pubblicato per sbaglio, in un repository GitHub al quale stava contribuendo, l’URL di un contenitore blob Azure che sarebbe dovuto restare privato.

L’URL in questione conteneva un token Shared Access Signature (SAS) eccessivamente permissivo che offriva pieno accesso al contenuto di un account di archiviazione interno di casa Microsoft. I ricercatori di sicurezza di Wiz sono stati in grado di utilizzare questo token per accedere alle informazioni ed esaminare i dati contenuti nel blob Azure.

I dati esposti includevano i backup dei profili delle workstation di due ex dipendenti della società di Satya Nadella e i messaggi privati scambiati attraverso Teams con i colleghi.

Cosa sono i token SAS e perché è bene usarli con attenzione

La problematica evidenziata mette in evidenza come gli errori possano capitare a tutti: una scarsa attenzione sulle modalità con cui si condividono i dati può avere, in certi casi, conseguenze drammatiche.

I token SAS forniscono un meccanismo per limitare l’accesso e consentire a determinati client di connettersi a risorse specifiche ospitate su Azure Storage. Nel caso in questione, un ricercatore di Microsoft ha involontariamente incluso questo token SAS in un URL di un contenitore di blob Azure. Non c’è quindi alcuna vulnerabilità intrinseca sulla piattaforma Azure e non è richiesta alcuna azione da parte degli utenti Microsoft.

Semmai, l’incidente sottolinea l’importanza di creare e gestire i token SAS in modo corretto. I ricercatori di Wiz, autori della scoperta, osservano che i token SAS – sempre se utilizzati correttamente – offrono un mezzo sicuro per concedere l’accesso alle risorse disponibili in un account di storage cloud. È infatti possibile specificare le risorse con le quali gli utenti possono interagire e definire le autorizzazioni relative a tali risorse, determinando la scadenza del token SAS.

Purtuttavia, sempre secondo Wiz, i token SAS sono scarsamente monitorati e risultano complessi da monitorare. Per questo possono rappresentare un rischio per la sicurezza e il loro utilizzo dovrebbe essere il più limitato possibile. Microsoft, infatti, attualmente non fornisce alcun metodo centralizzato per gestire i token SAS all’interno del portale Azure.

Inoltre, i token SAS possono essere configurati con una durata a tempo indeterminato: ciò significa che potrebbero non avere alcuna scadenza.

Consigli Microsoft per l’utilizzo dei token SAS su Azure Storage

Allorquando si decidesse di utilizzare degli URL SAS, Microsoft raccomanda di porre massima attenzione su una serie di aspetti cruciali. Suggerimenti che, evidentemente, non sono stati applicati con attenzione dall’ex dipendente dell’azienda di Redmond:

Applicare il principio del privilegio minimo: limitare gli URL SAS al più piccolo insieme di risorse alle quali i client devono poter accedere (ad esempio, un singolo blob). Limitare le autorizzazioni a quelle strettamente necessarie per l’applicazione (ad esempio, solo lettura o solo scrittura).
Utilizzare SAS a breve termine: impostare sempre una scadenza a breve termine alla creazione di un token SAS e fare in modo che i client richiedano nuovi URL SAS quando necessario. Azure Storage raccomanda un’ora o meno per tutti gli URL SAS.
Gestire attentamente i token SAS: gli URL SAS concedono l’accesso ai dati e dovrebbero essere trattati come qualunque altro “segreto” da custodire con curane. I token SAS vanno esposti solo ai client che hanno bisogno di accedere a un account di archiviazione.
Avere un piano di revoca: associare i token SAS a una Stored Access Policy per la revoca. In caso di necessità, bisogna essere nelle condizioni di rimuovere la Stored Access Policy e ruotare le chiavi dell’account di archiviazione.
Monitorare l’applicazione: è opportuno tenere traccia della gestione delle richieste di autorizzazione abilitando Azure Monitor e Azure Storage Logs.