Ogni volta che si effettua il login su un servizio online di Microsoft, Google, Facebook e così via, viene creato e rilasciato un token, una sorta di lasciapassare univoco (di solito una lunga serie di caratteri alfanumerici) che permetterà di evitare una nuova autenticazione sugli stessi siti web.
Un eventuale aggressore che riuscisse a intercettare e registrare i token altrui, pur non disponendo delle credenziali (nome utente e password) della vittima, può automaticamente autenticarsi sulle applicazioni web nell’ambito delle quali il token risulta valido.
Vi ricordate l’incidente occorso recentemente in casa Facebook? Ne abbiamo parlato nell’articolo Accedi con Facebook, cosa significa dopo l’attacco che ha coinvolto 50 milioni di account.
SafetyDetective ha in queste ore dato conto di una scoperta realizzata in collaborazione con il ricercatore e “cacciatore di bug” Sahad Nk.
Questa volta è Microsoft ad aver commesso un madornale errore di configurazione. Sahad Nk e SafetyDetective hanno scoperto che inviando un semplice link a qualunque utente, era possibile sottrargli il token autorizzativo per l’accesso ai servizi Microsoft.
Spieghiamo in breve il funzionamento dell’attacco.
I ricercatori si sono accorti che il dominio success.office.com
veniva fatto puntare a una Web App Microsoft Azure utilizzando il suo record CNAME. Tale applicazione, però, dopo una semplice verifica dei record memorizzati a livello di DNS, è risultata inesistente.
Dal momento che Microsoft Outlook, Microsoft Store e Sway autorizzavano l’URL https://success.office.com
come indirizzo valido per l’invio di una wreply ossia del token per il login (molto probabilmente a causa dell’utilizzo della wildcard *.office.com
), i ricercatori non hanno dovuto fare altro che creare una Web App su Azure con lo stesso nome inizialmente previsto da Microsoft nei record DNS.
Il gioco è fatto: inviando all’utente vittima un indirizzo contenente success.office.com
come URL per l’invio del token autorizzativo, i ricercatori hanno dimostrato di essere in grado di impossessarsi dell’altrui identità e accedere ai servizi Microsoft impersonificando un altro soggetto.
Il problema è stato segnalato privatamente a Microsoft nel corso del mese di giugno ed è stato risolto a novembre scongiurando qualunque rischio per gli utenti.
La dimostrazione resa da Sahad Nk e SafetyDetective ben evidenzia quanto errori di configurazione banali solo all’apparenza possano aprire vere e proprie voragini in termini di sicurezza.