Microsoft, un token senza firma espone l’accesso a Titan

Un token senza firma ha aperto a un 16enne le porte dell’analisi interna di Microsoft

Ogni volta che accediamo a un servizio online, dietro un semplice login avviene uno scambio di informazioni molto più delicato di quanto possa sembrare. Tra applicazioni, server e sistemi di autenticazione viaggiano infatti dei token digitali, piccoli documenti elettronici che indicano chi siamo, quale applicazione stiamo utilizzando e quali autorizzazioni dovremmo avere. La loro affidabilità, però, non dipende soltanto dai dati contenuti al loro interno: è soprattutto la firma digitale a garantire che quel token sia stato realmente emesso dal soggetto autorizzato e che nessuno lo abbia alterato successivamente. Proprio una verifica mancante di questo tipo è stata al centro di una vulnerabilità individuata nei sistemi interni di Microsoft, dove un ricercatore di sicurezza di appena 16 anni è riuscito a ottenere un livello di accesso amministrativo a Titan, un servizio interno utilizzato per l’analisi dei dati.

Che cosa è successo nei sistemi interni di Microsoft?

Il protagonista della scoperta è il ricercatore noto online come Faav, che ha individuato una vulnerabilità nel servizio di analisi interno Titan. L’elemento decisivo dell’attacco è stato un token manipolato, combinato con un nome utente apparentemente banale: “admin”. Una volta accettato dal sistema, il token ha permesso di eseguire query SQL con privilegi amministrativi, trasformando quello che sembrava inizialmente un problema di autenticazione in una potenziale porta d’accesso a una quantità considerevole di metadati.

Secondo quanto raccontato dallo stesso ricercatore, l’accesso ha consentito di visualizzare informazioni relative a circa 25.000 account, 17.990 indirizzi email di dipendenti e 24.569 dashboard presenti nell’ambiente. Ancora più significativo è stato il fatto che Titan risultasse collegato a 17 database di analisi, la cui dimensione complessiva è stata stimata dal ricercatore in circa 17,3 bilioni di righe. Si tratta tuttavia di una stima ricavata dai metadati disponibili e non del numero effettivo di record unici: potrebbero essere compresi dati storici, duplicati o informazioni derivate.

Faav ha segnalato la vulnerabilità al Microsoft Security Response Center il 5 settembre. Microsoft ha provveduto a chiudere l’accesso sfruttabile il 9 settembre, mentre il ricercatore ha ricevuto una ricompensa di 5.000 dollari il 17 settembre. L’episodio è stato successivamente raccontato sul blog del ricercatore, con alcune parti e alcuni numeri modificati o rimossi dopo una revisione effettuata da Microsoft prima della pubblicazione.

Come è stato possibile aggirare l’autenticazione di Titan?

La dinamica della scoperta è particolarmente interessante perché non racconta di un sofisticato exploit costruito attraverso una lunga catena di vulnerabilità. Il 25 agosto, Faav e il suo strumento di intelligenza artificiale chiamato Antares avevano individuato l’API di Titan. Il sito web del servizio risultava accessibile soltanto al personale autorizzato, ma la relativa API era raggiungibile attraverso un host ospitato su Microsoft Azure.

Da quel momento è iniziata una fase di analisi durata circa dieci giorni, durante la quale Antares ha provato diverse variazioni dei token utilizzati dal servizio. Il comportamento anomalo è emerso quando il sistema ha accettato token privi di una firma valida. Rimaneva però un problema: non era stato ancora individuato un nome utente che Titan riconoscesse come autorizzato.

La soluzione è arrivata da un’idea molto meno sofisticata della tecnologia utilizzata per cercarla. Faav ha modificato il campo relativo all’utente inserendo “admin”, una delle denominazioni più ricorrenti nella storia delle configurazioni informatiche. Il server ha interpretato quel valore come un utente locale con privilegi amministrativi e ha quindi eseguito la richiesta SQL. In altre parole, la barriera più importante non è stata superata attraverso una tecnica particolarmente complessa, ma sfruttando una combinazione di token non verificati e gestione permissiva dei privilegi.

Perché la firma digitale di un token è così importante?

Il dettaglio tecnico più importante della vicenda riguarda proprio la firma del token. Un sistema di autenticazione può leggere correttamente informazioni come tenant, applicazione, destinatario e nome utente, ma queste informazioni non hanno lo stesso valore se il server non verifica che il token sia autentico e non sia stato modificato.

Nel caso di Titan, secondo la ricostruzione di Faav, il servizio controllava diversi campi presenti nel token, tra cui tenant, audience, applicazione e utente, ma non verificava adeguatamente la firma. Questo significa che un attaccante poteva intervenire sul contenuto del documento digitale senza che il sistema disponesse di un meccanismo efficace per accorgersene. La firma, infatti, non serve semplicemente a “identificare” un token: permette al destinatario di verificare chi lo ha emesso e se il suo contenuto è rimasto integro.

Il paradosso è che la stessa documentazione relativa alla sicurezza di Azure Application Gateway indica la necessità di validare diversi elementi del token, inclusi firma, emittente, destinatario e scadenza. La vicenda di Titan dimostra quindi quanto possa essere rischiosa la distanza tra una buona pratica formalmente documentata e la sua effettiva applicazione all’interno di un sistema reale.

Che cosa dimostra l’uso dell’intelligenza artificiale nella ricerca?

L’episodio offre anche uno spunto interessante sul ruolo dell’intelligenza artificiale nella cybersecurity. Antares non sembra aver sostituito il ricercatore nella fase decisiva, ma ha svolto un lavoro di esplorazione metodica e ripetitiva che sarebbe stato più oneroso effettuare manualmente. Per circa dieci giorni lo strumento ha continuato a sperimentare varianti dei token fino a individuare il comportamento che consentiva l’accesso.

La decisione determinante, tuttavia, è stata umana: provare a sostituire il nome dell’utente con “admin”. È un esempio significativo di come gli strumenti di IA possano funzionare come moltiplicatori delle capacità di un ricercatore, soprattutto nelle attività che richiedono perseveranza, analisi di numerose varianti e ricerca di anomalie. Il giudizio sulla strada da seguire, almeno in questo caso, è rimasto invece legato all’intuizione del ricercatore.

La vulnerabilità dei token era già conosciuta?

L’aspetto forse più sorprendente è che il problema non appartiene a una categoria di vulnerabilità completamente nuova. I rischi legati alla possibilità di accettare token alterati o di non verificare correttamente gli algoritmi utilizzati sono conosciuti da anni. Già nel 2015, il ricercatore di sicurezza Tim McLean aveva evidenziato problemi in diverse librerie capaci di considerare validi token manipolati attraverso una gestione non corretta dell’algoritmo di firma.

Successivamente, nel 2020, l’Internet Engineering Task Force, l’organizzazione che sviluppa numerosi standard fondamentali per il funzionamento di Internet, ha pubblicato linee guida sulle pratiche di sicurezza relative ai JSON Web Token (JWT). Il principio di fondo rimane semplice: non basta leggere ciò che un token dichiara di essere; il sistema che lo riceve deve verificare in modo rigoroso che quelle informazioni siano autentiche.

Quale sarebbe potuto essere l’impatto dell’accesso?

Nonostante la quantità di informazioni individuate, è importante distinguere tra potenziale impatto e danno effettivamente verificato. Faav ha dichiarato di non aver consultato dati dei clienti e di essersi limitato ai metadati e a due campioni relativi a una singola riga di dati di Bing. La cifra dei 17,3 bilioni di righe, inoltre, rappresenta una stima basata sui metadati dei database e non dimostra che tutte quelle informazioni fossero direttamente accessibili attraverso la vulnerabilità.

Questo elemento è fondamentale per comprendere correttamente l’episodio senza trasformarlo in un caso di violazione di dati su scala già accertata. La vulnerabilità avrebbe potuto consentire un accesso molto più ampio, ma il ricercatore non ha sfruttato il problema per sottrarre o pubblicare dati dei clienti. La distinzione tra ciò che un sistema avrebbe potuto consentire e ciò che è stato concretamente fatto rappresenta uno degli aspetti più importanti nella valutazione di qualsiasi ricerca di sicurezza.

Qual è la lezione per chi sviluppa API e sistemi di autenticazione?

La vicenda Titan ripropone una regola di sicurezza apparentemente elementare, ma ancora oggi essenziale: un token non deve essere considerato attendibile soltanto perché contiene informazioni plausibili. Il server deve verificarne la firma, controllare l’emittente e il destinatario, accertarne la validità temporale e soprattutto stabilire in modo indipendente quali algoritmi di firma siano accettabili.

È altrettanto importante che il sistema non deleghi al token decisioni critiche sui privilegi senza effettuare ulteriori verifiche lato server. Un valore come “admin” può sembrare innocuo quando viene trattato semplicemente come una stringa, ma diventa estremamente pericoloso quando viene utilizzato per determinare privilegi amministrativi senza una corretta catena di autenticazione e autorizzazione.

Il caso Microsoft ricorda così una delle regole più difficili da rispettare nella sicurezza informatica: le vulnerabilità più pericolose non sono necessariamente quelle più spettacolari. A volte una superficie di attacco esposta, una verifica saltata e una configurazione apparentemente banale sono sufficienti per trasformare una semplice API in un punto d’ingresso inatteso. Ed è proprio per questo che, nella cybersecurity, la sicurezza di un sistema dipende tanto dai dettagli implementativi quanto dalla solidità dell’architettura sulla carta.