La vulnerabilità denominata nOAuth, individuata in Microsoft Entra ID, permette la compromissione completa degli account nelle applicazioni SaaS vulnerabili con uno sforzo minimo da parte degli attaccanti, costituendo un serio pericolo per le aziende che utilizzano le integrazioni cross-tenant di Entra.

Questa falla mette in luce una debolezza critica nei meccanismi di autenticazione delle applicazioni software-as-a-service (SaaS) vulnerabili. Con un semplice accesso a un tenant Entra — una barriera molto bassa — e conoscendo l’indirizzo email della vittima, un attaccante può ottenere il pieno controllo dell’account dell’utente sull’applicazione vulnerabile.

Una volta ottenuto l’accesso, l’attaccante può visualizzare tutti i dati ai quali l’utente ha accesso all’interno dell’applicazione.

La scoperta è stata segnalata tempestivamente dai ricercatori di Semperis ai fornitori delle applicazioni coinvolte e al Microsoft Security Response Center (MSRC) nel dicembre 2024; il MSRC ha confermato di aver ricevuto la segnalazione e ha aperto il caso numero 93209.

A marzo 2025, Semperis ha comunicato all’MSRC l’intenzione di rendere pubbliche queste informazioni. Il caso è stato chiuso dall’MSRC nell’aprile 2025. “Nei mesi di maggio e giugno 2025 abbiamo continuato a contattare i fornitori di applicazioni vulnerabili e abbiamo condiviso i dettagli con MSRC”, ha dichiarato Eric Woodruff, Chief Identity Architect di Semperis. “Nel giugno 2025 abbiamo ricevuto da MSRC un riscontro sull’importanza, per i fornitori, di seguire le raccomandazioni di sicurezza per difendersi da nOAuth; i fornitori che non le implementano rischiano di essere rimossi dalla Entra App Gallery di Microsoft”.

Rilevare un attacco che abusa di nOAuth è difficile o impossibile. I clienti non hanno a disposizione alcuna opzione di rimedio o mitigazione, se non quella di richiedere ai fornitori di applicazioni aggiornamenti per rendere le applicazioni invulnerabili all’abuso di nOAuth.

È a causa della semplicità di questo abuso, della complessità del rilevamento e dell’esistenza di applicazioni attivamente vulnerabili, che questa vulnerabilità è considerata un rischio grave per i clienti Entra ID.

Che cos’è nOAuth?

Il 20 giugno 2023, Omer Cohen di Descope ha pubblicato la divulgazione intitolata “nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover”. Il problema principale alla base di nOAuth è legato all’uso da parte degli sviluppatori di pratiche scorrette (anti-pattern) nell’implementazione di OpenID Connect (OIDC).

Queste cattive pratiche includono l’adozione di attributi modificabili, come l’indirizzo email, come identificatori univoci degli utenti. Poiché Entra ID permette agli utenti di avere indirizzi email non verificati, basarsi su questo attributo consente a un attaccante di impersonare l’utente anche tra tenant diversi.

Nella sua divulgazione, Descope ha spiegato che l’attacco si sfrutta in una sorta di “zona grigia” di Entra ID, dovuta al fatto che gli sviluppatori fanno affidamento su anti-pattern. Gli esperti di Semperis concordano con questa valutazione, ma evidenziano che ciò lascia esposti gli utenti finali di Microsoft e dei fornitori di applicazioni SaaS (ISV) a questo tipo di attacco.

In risposta alla scoperta di Cohen, il Microsoft Security Response Center (MSRC) ha pubblicato un articolo sui rischi di nOAuth, intitolato “Potenziale rischio di escalation dei privilegi nelle applicazioni Azure AD”. All’interno della comunicazione sull’impatto per i clienti Microsoft, l’articolo dichiarava:

“Microsoft ha identificato diverse applicazioni multi-tenant con utenti che utilizzano un indirizzo e-mail con un proprietario di dominio non verificato. Sebbene gli indirizzi e-mail non verificati non rappresentino un rischio per le applicazioni che non utilizzano rivendicazioni e-mail a scopo di autorizzazione, i proprietari di queste applicazioni sono stati informati e hanno ricevuto indicazioni su come modificare le loro applicazioni, se del caso. Se non avete ricevuto alcuna notifica, significa che la vostra applicazione non ha consumato rivendicazioni e-mail con proprietari di domini non verificati.

Per proteggere i clienti e le applicazioni che potrebbero essere vulnerabili all’escalation dei privilegi, Microsoft ha implementato mitigazioni per omettere le richieste di token da proprietari di dominio non verificati per la maggior parte delle applicazioni”.

Microsoft ha anche pubblicato una guida specifica per la migrazione dall’utilizzo delle richieste di informazioni via e-mail. Al momento della stesura di questo articolo, la guida non è più disponibile sul sito Microsoft, anche se è possibile trovare una versione archiviata altrove.

Come si sfrutta nOAuth?

L’exploit di nOAuth si basa su tre elementi principali:

1. La possibilità di configurare un indirizzo email non verificato all’interno di Entra ID.
2. Una registrazione dell’applicazione che accetta e utilizza una email non verificata come identificatore.
3. La presenza di una vulnerabilità nell’applicazione che permetta di sfruttare questa combinazione.

Vediamo ora un esempio concreto di come si può presentare questo tipo di attacco.

Configurare un indirizzo email non verificato in Entra ID

I servizi Microsoft Entra ID e Microsoft 365 prevedono un tenant predefinito associato a un dominio onmicrosoft.com, ad esempio contoso.onmicrosoft.com. Quando un’organizzazione imposta la propria infrastruttura e aggiunge i propri domini personalizzati per i servizi, la verifica della proprietà avviene tramite l’aggiunta di un record TXT o MX. Una volta completata questa verifica, il dominio viene contrassegnato come verificato in Entra ID (Figura 1).

Figura 1. Nome di dominio verificato in Entra ID.

Per abilitare la funzionalità di utenti ospiti in Entra ID, non è obbligatorio che il dominio presente nel suffisso dell’attributo email sia un dominio verificato. Di conseguenza, qualsiasi utente appartenente a qualsiasi tenant Entra può avere qualunque indirizzo email valorizzato nell’attributo mail.

Ad esempio, nella Figura 2 si vede un utente, Adele Vance, il cui attributo mail corrisponde al valore di userPrincipalName.

Figura 2. Account con un indirizzo e-mail verificato che corrisponde a NomePrincipaleutente.

È possibile effettuare una semplice operazione PATCH per modificare questo attributo (come mostrato nella Figura 3).

Figura 3. Esecuzione di un PATCH contro Adele Vance.

Un successivo comando GET conferma che l’email di Adele ora ha un dominio non verificato all’interno del tenant (Figura 4).

Figura 4. Adele Vance ha ora un indirizzo e-mail non verificato.

Verifica della modifica di un indirizzo email

Per verificare che un indirizzo email non verificato venga incluso come rivendicazione in un token ID, si può configurare la registrazione di un’applicazione in Entra ID con un URI di reindirizzamento verso https://jwt.ms e passarle il token ID.

Per le registrazioni di applicazioni effettuate dopo giugno 2023, Entra ID, di default, non emette la rivendicazione per email non verificate. Tuttavia, è possibile modificare questa configurazione tramite un’operazione PATCH sull’oggetto authenticationBehavior della registrazione dell’applicazione, impostando removeUnverifiedEmailClaim su false (Figura 5). Questo procedimento è descritto da Microsoft nell’articolo “Manage application authenticationBehaviors”.

Figura 5. Impostazione di removeUnverifiedEmailClaim su false.

Una volta configurata la registrazione dell’applicazione, la si può utilizzare per simulare il comportamento di un’applicazione vulnerabile e visualizzare il token ID (Figura 6).

Figura 6. Token ID decodificato con un indirizzo e-mail non verificato.

Se un’applicazione consuma questo token ID e impiega l’email come identificatore univoco, non sarà in grado di accorgersi che l’utente non è effettivamente quello legittimo.

Mitigare l’abuso di nOAuth

Come già accennato, la protezione contro l’abuso di nOAuth richiede, in ultima analisi, che gli sviluppatori implementino correttamente i meccanismi di autenticazione, in modo da garantire un identificatore utente unico e immutabile.

Pam Dingle, Director of Identity Standards di Microsoft, ha pubblicato poco dopo la divulgazione di nOAuth un articolo dedicato ai comuni anti-pattern degli sviluppatori. È una lettura consigliata: “L’anti-pattern dei falsi identificatori”.

Come evidenziato da Pam nell’articolo, secondo la specifica OpenID Connect (sezione 5.7), l’unico metodo sicuro con cui un’applicazione (SP) può garantire un identificatore utente stabile e univoco è utilizzare la combinazione dei claim di emittente (iss) e soggetto (sub).

In Entra ID, il claim iss è emesso come un URI dell’emittente che contiene l’ID del tenant, garantendo così unicità a livello globale (Figura 7).

Figura 7. La rivendicazione dell’emittente unico.

Il sub (soggetto) è un identificatore “pairwise” che risulta unico per ciascun utente e per ogni ID applicazione (Figura 8). Un aspetto altrettanto fondamentale è che sub è un valore immutabile in Entra ID. Il sistema non permette alcuna trasformazione o modifica di questo claim, garantendone così l’unicità.

Figura 8. La rivendicazione del soggetto unico.

Per ulteriori dettagli sulle rivendicazioni contenute in un token ID rilasciato da Entra ID, è possibile consultare: “Riferimento alle rivendicazioni dei token ID”.

Cambiamenti di Microsoft per limitare l’abuso di nOAuth

Microsoft ha introdotto modifiche in Entra ID affinché tutte le registrazioni di applicazioni create dopo giugno 2023, per impostazione predefinita, non includano più la rivendicazione dell’email se l’indirizzo non risulta verificato. Tuttavia, esistono migliaia di applicazioni SaaS sviluppate prima di quella data, e molti sviluppatori vogliono (o devono) continuare a utilizzare l’indirizzo email; spesso le applicazioni SaaS hanno necessità di inviare email agli utenti finali, e acquisire l’email tramite una rivendicazione è la modalità più semplice per farlo.

Per agevolare gli sviluppatori, Microsoft ha anche introdotto il claim opzionale xms_edov, che permette di verificare se un indirizzo email è confermato. Al momento della scrittura di questo testo, tuttavia, il claim xms_edov sembra trovarsi in una situazione poco chiara, che fa ipotizzare una possibile rimozione futura. Sebbene la documentazione Microsoft indichi che si tratta di un claim facoltativo, non è più presente nell’interfaccia utente per la configurazione dei claim opzionali. Anche se si imposta xms_edov come richiesta facoltativa tramite Graph API, successivamente compare un messaggio che avverte che non si tratta di una richiesta opzionale valida (Figura 9).

Figura 9. Impostazione dell’indicazione xms_edov.

In pratica, uno sviluppatore potrebbe sfruttare queste informazioni per stabilire se l’indirizzo email di un utente sia stato verificato all’interno del tenant (Figura 10).

Figura 10. Il claim xms_edov restituito in un token ID per un indirizzo e-mail non verificato.

La nuova ricerca sull’abuso di nOAuth

Nella propria ricerca, Descope si è concentrata sulle applicazioni SaaS che supportano più provider di identità – come Google, Microsoft, Facebook e altri (Figura 11).

Figura 11. Esempio di più fornitori di identità (Fonte: Descope).

Per migliorare l’esperienza utente, queste applicazioni in genere implementano logiche di fusione degli account. Ad esempio, se mi registro su Medium con il mio account Facebook e poi accedo con quello di Google, il sistema unisce le due modalità di accesso nello stesso account Medium.

Il problema analizzato da Descope è che, dato che qualsiasi account Entra ID poteva includere una rivendicazione email, gli sviluppatori che eseguivano la fusione basandosi sull’email potevano, senza saperlo, consentire a un attaccante di prendere il controllo dell’account di un altro utente.

Oltre alle misure implementate da Microsoft, Descope suggerisce che le applicazioni SaaS che permettono la fusione di account interrompano il processo al primo tentativo di accesso tramite un provider diverso, includendo un passaggio di verifica della proprietà dell’email. Condividiamo questo consiglio. Questa verifica può ad esempio consistere in un “magic link” inviato via email, che chiede all’utente di confermare la proprietà dell’indirizzo prima di procedere con la fusione.

Dalla ricerca di Semperis è emerso che questa è una pratica di sicurezza diffusa tra le applicazioni che non risultano vulnerabili all’abuso di nOAuth.

Nel tardo autunno del 2024, durante un’attività esplorativa, i ricercatori di Semperis hanno analizzato il lavoro svolto da Descope e deciso di testarne i concetti su alcune applicazioni SaaS reali. Questa iniziativa si è combinata con l’idea di esplorare la Microsoft Entra App Gallery. La Entra App Gallery è un portale all’interno di Entra ID, gestito da Microsoft, che permette ai fornitori SaaS di terze parti di elencare e presentare applicazioni integrate con Entra ID (Figura 12).

Figura 12. La galleria di app di Microsoft Entra.

Durante l’indagine, il team di Semperis ha esaminato tutte le 1.017 integrazioni OIDC disponibili in quel periodo e ha individuato 104 applicazioni che consentivano la registrazione autonoma degli utenti. In un mercato SaaS molto competitivo, i fornitori tendono infatti a offrire versioni gratuite o di prova con pochissime barriere all’ingresso, consentendo agli utenti di testare l’applicazione senza passare per canali commerciali tradizionali.

Gli esperti di Semperis hanno scelto di concentrarsi su queste applicazioni non solo perché facilitavano la ricerca dal punto di vista pratico, ma anche per garantire che i test restassero entro limiti etici ben definiti.

Per ciascuna applicazione esaminata, è stato utilizzato un tenant “vittima” controllato da Semperis per configurare un account all’interno della piattaforma. Successivamente, un altro tenant – il tenant “attaccante” – è stato impiegato per tentare l’abuso nOAuth contro l’account della vittima. In questo modo, i ricercatori hanno verificato che i test coinvolgessero esclusivamente account di loro proprietà e dati di prova creati appositamente per l’esperimento.

La ricerca di Semperis si differenzia da quella di Descope perché si è concentrata sull’identificazione di applicazioni vulnerabili all’abuso nOAuth cross-tenant su Entra ID. In altre parole, il cliente bersaglio (vittima) è un cliente Microsoft con un tenant Entra ID, mentre l’attaccante sfrutta un tenant Entra ID separato per condurre l’attacco. Il diagramma pubblicato da Descope resta valido anche per illustrare il flusso dell’attacco analizzato da Semperis (Figura 13).

Figura 13. Flusso di abuso di nOAuth (Fonte: Descope).

Tuttavia, nel caso della ricerca di Semperis, l’unico requisito per l’applicazione SaaS era che supportasse Entra ID come metodo di autenticazione. Anche se quasi tutte le applicazioni esaminate offrivano la possibilità di creare un account utente locale, alcune di esse consentivano anche l’uso di più provider di identità, come Google ed Entra ID, mentre altre si limitavano esclusivamente a Entra ID.

Inoltre, si è ipotizzato che se un’applicazione utilizzava solo Entra ID per l’autenticazione, fosse improbabile che gli sviluppatori avessero previsto o implementato la logica di fusione degli account e la verifica dell’email descritta da Descope. Questo perché, presumibilmente, non si aspettavano di dover gestire scenari di collisione tra account provenienti da diversi provider.

Applicazioni vulnerabili

Durante i test condotti su 104 applicazioni, i ricercatori di Semperis hanno identificato 9 applicazioni vulnerabili all’abuso di nOAuth, indicando un tasso di vulnerabilità di circa il 9% tra quelle esaminate. Considerato che queste 104 rappresentano solo una piccola frazione del vasto ecosistema di applicazioni SaaS integrate con Entra ID, si può ipotizzare che, su decine di migliaia di applicazioni disponibili, il problema sia potenzialmente diffuso.

Tra le applicazioni risultate vulnerabili, sono emerse osservazioni interessanti in merito alle dimensioni, alla portata e alla tipologia delle soluzioni. Ad esempio, è stata individuata una piattaforma HRMS (sistema di gestione delle risorse umane) che, con ogni probabilità, conterrebbe un’ampia quantità di dati personali identificabili (PII). Sono state trovate anche applicazioni con integrazioni a Microsoft 365 per funzioni come la gestione della posta elettronica e del calendario.

Poiché queste integrazioni si basano su combinazioni di access token e refresh token differenti, un attaccante che riuscisse a sfruttare nOAuth non solo potrebbe accedere ai dati dell’applicazione SaaS, ma potenzialmente anche a risorse di Microsoft 365.

Purtroppo, testare su larga scala è un’operazione complessa e dispendiosa in termini di tempo. Oltre alla necessità di configurare un tenant Entra appositamente per condurre l’attacco, serviva anche la revisione diretta da parte di più persone sull’interfaccia dell’applicazione SaaS, per verificare se l’attaccante potesse effettivamente accedere all’account della vittima.

Anche se molte applicazioni che si sono dimostrate non vulnerabili a questo attacco presentavano un nuovo flusso di onboarding o accesso, in alcuni casi gli esperti di Semperis hanno potuto semplicemente accedere alla schermata principale dell’applicazione, consultare le informazioni dell’account o cercare di manipolare i dati per determinare se l’attaccante si trovasse nello stesso account della vittima.

Contattare le parti interessate

A seguito di questa analisi, Semperis ha aperto un caso presso il Microsoft Security Response Center (MSRC). Inoltre, i ricercatori di Semperis si sono impegnati a identificare i referenti di ciascun ISV che avesse sviluppato un’applicazione risultata vulnerabile.

Dopo aver contattato questi stakeholder, il team si è offerto di aiutarli a correggere la falla presente nelle loro applicazioni; alcuni fornitori hanno accettato il supporto.

In tali casi, Semperis li ha guidati nella comprensione del problema ed ha condotto ulteriori test per verificare l’abuso di nOAuth sulle loro applicazioni, continuando finché la vulnerabilità non è stata risolta.

Difesa del cliente: mancanza di opzioni

In definitiva, l’unica difesa che un cliente ha contro l’abuso di nOAuth è 1) sollecitare il fornitore a risolvere il problema o 2) abbandonare l’applicazione SaaS.

Poiché l’attacco avviene al di fuori dell’ambito della vittima, i meccanismi di difesa tradizionali non possono fornire protezione. Questi includono:

1. Autenticazione a più fattori (MFA) e forza di autenticazione in Entra ID.
2. Accesso condizionato.
3. Soluzioni Zero Trust Network Access (ZTNA) e Cybersecurity for Any Business (CASB).
4. Rilevamento e risposta degli endpoint (EDR).
5. Rilevamento e risposta estesi (XDR).

Rilevamento abusi nOAuth

Anche se le soluzioni di SaaS Security Posture Management (SSPM) possono offrire una certa visibilità sulle applicazioni SaaS, solitamente si concentrano sugli aspetti di configurazione e sulla sicurezza così come appare ai clienti della piattaforma, senza riuscire a rilevare un abuso di nOAuth.

Problemi simili si riscontrano anche con i secure browser aziendali e con i plug-in per browser: pur potendo aiutare a individuare altre tipologie di backdoor nelle applicazioni SaaS, è improbabile che siano in grado di far emergere questo specifico tipo di attacco.

Purtroppo, questo lascia poche opzioni ai clienti:

1. Correlazione dei log di autenticazione SaaS con Entra ID all’interno di una piattaforma SIEM.
2. Chiedere ai propri fornitori informazioni su nOAuth.
3. Eseguire autonomamente i test di abuso di nOAuth.

Dal lato di Entra ID, Semperis ha analizzato i service principal delle applicazioni multi-tenant e non ha individuato alcun attributo visibile ai clienti che indichi se l’applicazione accetta rivendicazioni di email non verificate. Anche qualora tali attributi fossero presenti, non esisterebbe comunque un modo per specificare l’uso che l’applicazione fa di queste informazioni.

Correlazione dei log di autenticazione

Per riuscire a rilevare un abuso di nOAuth tramite correlazione dei log, è necessario acquisire i registri di autenticazione di Entra ID in una soluzione di Security Information and Event Management (SIEM), come Microsoft Sentinel.

Occorre inoltre raccogliere i log di autenticazione dell’applicazione SaaS e mettere in relazione questi dati all’interno del SIEM.

L’obiettivo è individuare eventi di autenticazione presenti nella piattaforma SaaS che non abbiano un corrispondente evento di autenticazione in Entra ID (Figura 14).

Figura 14. Correlazione logica teorica.

Naturalmente, i risultati dell’applicazione pratica di questo approccio possono variare notevolmente. Anche se il sub (soggetto) è l’identificatore principale usato dall’applicazione SaaS, questo valore non viene registrato nei log di accesso di Entra ID durante l’autenticazione.

Di conseguenza, l’applicazione SaaS dovrebbe includere nei propri log anche attributi come l’UPN o l’indirizzo email per permettere la correlazione. Inoltre, i log di autenticazione del fornitore SaaS devono essere disponibili e accessibili affinché possano essere integrati in un SIEM.

Altri fattori, come la differenza temporale tra i sistemi o la precisione dei dati, possono rendere ancora più difficile individuare un abuso di nOAuth tramite la correlazione dei log.

Test per nOAuth e responsabilità del fornitore

L’unica vera opzione per un cliente è testare direttamente le applicazioni SaaS che utilizza per verificare la presenza di un potenziale abuso di nOAuth. Prima di intraprendere questi test, è consigliabile contattare il fornitore dell’applicazione per chiedere se è a conoscenza di nOAuth e se ha già condotto verifiche specifiche contro questo tipo di abuso.

Alcuni aspetti importanti da considerare:

1. Certificazioni come il SOC II non coprono questa forma di attacco. Sono state identificate applicazioni vulnerabili i cui fornitori esponevano sul proprio sito certificazioni SOC II e altre attestazioni di sicurezza.
2. Chiedere esplicitamente al fornitore se ha testato la propria applicazione contro questa vulnerabilità. In alcuni casi, sono stati trovati fornitori convinti di aver risolto il problema, ma gli esperti di Semperis hanno comunque potuto condurre con successo attacchi nOAuth sulle loro applicazioni.

Se il fornitore non è in grado di fornire una risposta chiara e definitiva, il cliente può scegliere di effettuare personalmente i test sulle applicazioni di interesse.

Proprio come fanno i ricercatori di sicurezza, i clienti devono assicurarsi di operare entro limiti etici: utilizzando i propri account utente e rispettando eventuali obblighi contrattuali con il fornitore.

Difesa degli sviluppatori di software contro nOAuth

Gli sviluppatori che fanno uso della rivendicazione di email devono assicurarsi di non impiegarla come identificatore dell’utente. Se la utilizzano a questo scopo, dovrebbero seguire le linee guida documentate da Microsoft e rispettare le specifiche OIDC, utilizzando issuer e subject come identificatori.

Gli sviluppatori possono anche analizzare le configurazioni delle loro applicazioni per verificare se stanno ricevendo email non verificate come parte delle rivendicazioni. Tuttavia, spetta a loro esaminare il codice dell’applicazione per capire in che modo queste informazioni vengano effettivamente usate.

Esistono inoltre soluzioni alternative per ottenere l’attributo email senza passare per la rivendicazione presente nel token ID. Lo standard OIDC definisce un endpoint UserInfo, che Entra ID implementa. Questo endpoint può essere utilizzato per recuperare informazioni sull’utente autenticato.

Facendo una chiamata a UserInfo, l’applicazione può ottenere l’indirizzo email dell’utente dopo il processo di autenticazione, anche se quell’email non è verificata. Questo approccio aiuta a evitare l’uso dell’email come identificatore univoco dell’utente.

Ad esempio, possiamo interrogare l’endpoint UserInfo per l’utente Adele Vance, che ha un’email non verificata (Figura 15). Il claim sub, che funge da identificatore unico, sarà lo stesso di quello presente nel token ID.

Figura 15. Chiamata dell’endpoint UserInfo.

Gli sviluppatori che hanno modificato il proprio codice per correggere la vulnerabilità nOAuth dovrebbero eseguire test approfonditi sulle loro applicazioni dopo l’aggiornamento, per assicurarsi che non siano più soggette a questo tipo di abuso. Durante le attività di bonifica svolte con i fornitori, gli esperti di Semperis hanno riscontrato che la prima correzione proposta non sempre eliminava completamente la vulnerabilità.

Nelle comunicazioni con il Microsoft Security Response Center (MSRC), quest’ultimo ha sottolineato nuovamente l’importanza che gli sviluppatori seguano le linee guida consigliate e ha fatto riferimento all’articolo pubblicato in occasione della divulgazione del 2023. Poiché esistono esigenze legittime che spingono le applicazioni a richiedere l’indirizzo email di un utente, non esiste un modo automatico per stabilire se un’applicazione stia usando questo attributo in modo sicuro senza effettuare test diretti su ciascuna applicazione.

MSRC ha inoltre dichiarato di aver contattato i fornitori di applicazioni vulnerabili, precisando che quelli che non hanno risolto il problema rischiano la rimozione dalla Entra App Gallery.

Divulgazione e tempistica

Sorprendendosi nel riscontrare la possibilità di abuso di nOAuth, in particolare in applicazioni elencate nella Entra Gallery, i ricercatori di Semperis hanno aperto un caso presso il MSRC, a cui è stato assegnato il numero 93209.

Hanno inoltre sollecitato il Microsoft Identity Product Group ad adottare un approccio più deciso per proteggere i clienti, considerando la difficoltà di individuare gli abusi legati a nOAuth. Tra le raccomandazioni, hanno suggerito di informare i clienti che l’applicazione consente l’invio di indirizzi email non verificati, pur riconoscendo che questo non rappresenta di per sé una prova certa di vulnerabilità a nOAuth.

Infine, hanno condiviso con MSRC l’elenco delle nove applicazioni vulnerabili che avevano individuato, nel caso in cui il centro fosse già in contatto con i rispettivi fornitori.

“L’abuso di nOAuth è una minaccia seria a cui molte organizzazioni potrebbero essere esposte” ha aggiunto Woodruff. “Richiede poco sforzo, lascia pochissime tracce e aggira le protezioni dell’utente finale. Abbiamo confermato che lo sfruttamento è ancora possibile in molte applicazioni SaaS, il che rende questo un appello urgente all’azione. Incoraggiamo gli sviluppatori a implementare le correzioni necessarie per proteggere i propri clienti prima che la falla venga ulteriormente sfruttata”.

• 3 dicembre 2024: Caso creato con MSRC.
• 3 dicembre 2024: Caso riconosciuto dal MSRC.
• 4 dicembre 2024: Forniti ulteriori dettagli sul caso a MSRC.
• 17 dicembre 2024: Aggiornato il caso con MSRC, segnalando che Semperis ha lavorato con un fornitore per risolvere una delle applicazioni vulnerabili.
• 17 marzo 2025: Chiesto a MSRC lo stato del caso; Semperis non ha ricevuto risposta.
• 18 marzo 2025: Notificato a MSRC nel portale l’intenzione di divulgare la sessione di Troopers 2025 (se selezionata).
• 19 marzo 2025: Comunicato via e-mail a MSRC l’intenzione di divulgare la vulnerabilità durante la sessione di Troopers (se selezionata) e chieste indicazioni sulla divulgazione, dato che la vulnerabilità originale era già stata divulgata; Semperis non ha ricevuto risposta.
• 18 aprile 2025: Il caso è stato chiuso da MSRC, affermando che “è stata segnalata una correzione per il problema presentato” senza ulteriori informazioni.
• Aprile – maggio 2025: Sono stati testati e trovati fornitori di applicazioni che erano vulnerabili a nOAuth; i fornitori sono stati nuovamente notificati ed è stato contattato MSRC con le scoperte rilevate.
• Giugno 2025: MSRC ha fornito dettagli sulle applicazioni vulnerabili a nOAuth nella galleria delle applicazioni Entra.
• 26 giugno 2025: Divulgazione al pubblico.