Risultati principali
- Nel testare 104 applicazioni, Semperis ne ha trovate 9 (ovvero circa il 9%) vulnerabili all'abuso di nOAuth.
- Come è già stato rivelato, la capacità di eseguire nOAuth è di bassa complessità.
- L'abuso di nOAuth sfrutta le vulnerabilità cross-tenant e può portare all'esfiltrazione, alla persistenza e al movimento laterale dei dati delle applicazioni SaaS.
- L'abuso è difficile da individuare per i clienti delle applicazioni vulnerabili e impossibile da difendere per i clienti delle applicazioni vulnerabili.
- I ricercatori di Semperis classificano questa vulnerabilità come potenzialmente GRAVE a causa della bassa complessità dell'attacco e della difficoltà di rilevamento e difesa.
La vulnerabilità nOAuth espone una falla di autenticazione critica nelle applicazioni software-as-a-service (SaaS) vulnerabili. Con il solo accesso a un affittuario Entra - una barriera bassa - e all'indirizzo e-mail dell'utente target, un aggressore può prendere il controllo dell'account dell'utente nell'applicazione vulnerabile. Da lì, l'aggressore può accedere a tutti i dati a cui l'obiettivo ha accesso all'interno dell'applicazione.
Abbiamo prontamente segnalato le nostre scoperte ai fornitori delle applicazioni e al Microsoft Security Response Center (MSRC) nel dicembre 2024; il MSRC ha confermato la ricezione della segnalazione e ha aperto il caso 93209. Nel marzo 2025, abbiamo notificato a MSRC la nostra intenzione di divulgare il caso. L'MSRC ha chiuso il caso nell'aprile 2025. Nei mesi di maggio e giugno del 2025 abbiamo continuato a contattare i fornitori di applicazioni vulnerabili e abbiamo condiviso i dettagli con MSRC. Nel giugno 2025, abbiamo ricevuto un feedback da MSRC che ribadiva che i fornitori devono seguire le raccomandazioni e che quelli che non lo fanno sono soggetti alla rimozione dalla Entra App Gallery.
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, Semperis considera questa vulnerabilità un rischio grave per i clienti Entra ID.
Questo articolo illustra l'esplorazione di nOAuth da parte del team di ricerca sulla sicurezza di Semperis, incentrata sulle applicazioni della Microsoft Entra App Gallery. Abbiamo scoperto nove applicazioni vulnerabili, comprese quelle che potrebbero contenere informazioni di identificazione personale (PII).
Che cos'è nOAuth?
Il 20 giugno 2023, Omer Cohen di Descope ha pubblicato la divulgazione "nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover". Il problema fondamentale che porta a nOAuth è l'uso da parte degli sviluppatori di app di anti-pattern relativi all'implementazione di OpenID Connect (OIDC). Questi anti-pattern includono l'uso di attributi mutabili, come l'indirizzo e-mail, per gli identificatori degli utenti. Poiché Entra ID consente agli utenti di avere un indirizzo e-mail non verificato, l'uso di questo attributo consente l'impersonificazione dell'utente attraverso i confini del tenant. Nella divulgazione Descope ha descritto che l'attacco si colloca in una "zona grigia" di Entra ID, a causa della dipendenza degli sviluppatori dal rispetto di anti-pattern. Sebbene siamo d'accordo con questa affermazione, essa lascia i clienti comuni di Microsoft e del fornitore di applicazioni SaaS (ISV) vulnerabili a questo abuso.
In risposta alla scoperta di Cohen, MSRC ha pubblicato un articolo sui rischi di nOAuth: "Potenziale rischio di escalation dei privilegi nelle applicazioni Azure AD". Come parte della dichiarazione di impatto sui clienti di Microsoft, l'articolo affermava:
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.
Dichiarazione di impatto sui clienti Microsoft
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 funziona l'abuso di nOAuth?
L'abuso di nOAuth richiede tre componenti:
- La possibilità di impostare un indirizzo e-mail non verificato in Entra ID
- Una registrazione dell'App che consente la rivendicazione di un'email non verificata
- Vulnerabilità di un'applicazione a questa combinazione
Vediamo un esempio di come potrebbe apparire questo tipo di abuso.
Impostazione di un indirizzo e-mail non verificato in Entra ID
I servizi Entra ID e Microsoft 365 includono un tenant predefinito con un nome di dominio onmicrosoft.com, come contoso.onmicrosoft.com. Quando le organizzazioni configurano le loro implementazioni e inseriscono i propri nomi di dominio per i servizi, il processo di verifica utilizza un record TXT o MX per verificare la proprietà del dominio. Una volta verificato, il nome di dominio viene contrassegnato come tale in Entra ID(Figura 1).
Per supportare la funzionalità di utente ospite in Entra ID, tuttavia, non è necessario che il suffisso del dominio dell'attributo e-mail sia un dominio verificato. Pertanto, qualsiasi utente di qualsiasi tenant di Entra può avere qualsiasi indirizzo e-mail nell'attributo mail.
Ad esempio, la Figura 2 mostra un utente, Adele Vance, il cui attributo mail ha lo stesso valore dell'attributo userPrincipalName.
Possiamo eseguire un semplice PATCH per modificare questo attributo della posta(Figura 3).
Un altro GET mostra che Adele ha ora un indirizzo e-mail per un dominio che non è verificato all'interno di questo tenant(Figura 4).
Verifica della modifica di un indirizzo e-mail
Se si desidera convalidare l'indirizzo e-mail non verificato come rivendicazione in un token ID, è possibile configurare la registrazione di un'applicazione in Entra ID con un URI di reindirizzamento di https://jwt.ms e passargli il token ID.
Per le registrazioni di app create dopo il giugno 2023, per impostazione predefinita la richiesta di e-mail non verificata non viene emessa da Entra ID. Per modificare la configurazione in modo da consentirlo, è possibile utilizzare un semplice PATCH sull'authenticationBehavior per la registrazione dell'app, impostando removeUnverifiedEmailClaim su false (Figura 5). Questo processo è documentato da Microsoft nell'articolo "Manage application authenticationBehaviors".
Una volta configurata la registrazione dell'applicazione, possiamo usarla per replicare il comportamento di un'applicazione vulnerabile e visualizzare il token ID(Figura 6).
Se questo token ID viene consumato da un'applicazione che utilizza l'email come identificatore univoco, l'applicazione non saprà che l'utente non è, in realtà, l'utente legittimo.
Mitigare l'abuso di nOAuth
Come già detto, la mitigazione dell'abuso di nOAuth richiede in ultima analisi che lo sviluppatore implementi correttamente l'autenticazione per garantire un identificatore unico e immutabile.
Pam Dingle, direttore degli standard di identità di Microsoft, ha pubblicato un articolo poco dopo la divulgazione di nOAuth sugli anti-pattern degli sviluppatori. Vale la pena leggerlo: "L'anti-pattern dei falsi identificatori".
Come sottolinea Pam nell'articolo, secondo le specifiche di OpenID Connect, nella sezione 5.7, la combinazione delle dichiarazioni dell'emittente(iss) e del soggetto(sub) è l'unico modo in cui un'applicazione(SP) può garantire un identificatore utente unico e stabile.
In Entra ID, l'emittente(iss) viene emesso come URI dell'emittente che include l'ID del locatario, che è unico a livello globale(Figura 7).
Il soggetto(sub) è un identificatore a coppie che è unico per ogni utente per ogni ID applicazione(Figura 8). Altrettanto importante è il fatto che sub è un valore immutabile in Entra ID. Entra ID non consente alcun tipo di trasformazione o modifica della rivendicazione oggetto, garantendone l'unicità.
I dettagli sulle rivendicazioni di un token ID emesso da Entra ID sono disponibili qui: "Riferimento alle rivendicazioni dei token ID".
Modifiche di Microsoft per mitigare gli abusi di nOAuth
All'interno di Entra ID, Microsoft ha apportato modifiche in modo che qualsiasi registrazione di app creata dopo il giugno 2023 non emetta, per impostazione predefinita, una richiesta di e-mail se l'indirizzo e-mail non è verificato. Naturalmente, migliaia e migliaia di applicazioni SaaS esistono da prima del giugno 2023 e molti sviluppatori vogliono e devono ancora consumare l'indirizzo e-mail; molte applicazioni SaaS vogliono inviare e-mail agli utenti finali e il consumo attraverso una rivendicazione è il modo più semplice per ottenere tali informazioni.
Per aiutare gli sviluppatori, Microsoft ha introdotto anche il claim opzionale xms_edov, che uno sviluppatore può utilizzare per determinare se un indirizzo e-mail è verificato. Al momento della stesura di questo articolo, tuttavia, l'indicazione xms_edov sembra essere in uno stato di incertezza, il che fa pensare a una sua deprecazione. Sebbene i documenti Microsoft indichino che l'indicazione è facoltativa, non è più disponibile nell'interfaccia utente per l'impostazione delle indicazioni facoltative. L'impostazione di xms_edov come richiesta opzionale tramite Graph API funziona, ma in seguito viene visualizzato un messaggio che indica che non si tratta di una richiesta opzionale valida(Figura 9).
In pratica, un dev potrebbe usare queste informazioni per decidere se l'indirizzo e-mail di un utente è verificato nel tenant(Figura 10).
La nuova ricerca di Semperis sull'abuso di nOAuth
Il focus di Descope
Nella ricerca pubblicata da Descope, l'attenzione è rivolta alle applicazioni SaaS che supportano più fornitori di identità, come Google e Microsoft, Facebook e così via(Figura 11).
Ai fini dell'usabilità, le applicazioni SaaS hanno in genere una logica di fusione degli account. Ad esempio, se mi iscrivo a Medium con un account Facebook e poi accedo con il mio account Google, le due fonti di autenticazione mi portano allo stesso account Medium.
Il problema che Descope ha analizzato è che, poiché qualsiasi account utente in Entra ID poteva contenere la richiesta di e-mail, gli sviluppatori che effettuavano la fusione in base all'e-mail potevano inconsapevolmente consentire a un aggressore di accedere all'account di un utente target.
Oltre ad alcune delle funzionalità implementate da Microsoft, Descope raccomanda che le applicazioni SaaS che supportano la funzionalità di fusione degli account interrompano il flusso al primo tentativo di accesso con una fonte di account diversa, utilizzando una funzione di convalida della proprietà dell'e-mail. Siamo d'accordo con questo consiglio. Questa funzione può assumere la forma di un link magico via e-mail, in cui l'utente riceve un'e-mail che gli chiede di verificare la proprietà prima che avvenga la fusione.
Nella nostra ricerca, abbiamo constatato che questa è una pratica di sicurezza comune tra le applicazioni che si sono dimostrate invulnerabili all'abuso di nOAuth.
Ricerca Semperis
Nel tardo autunno del 2024, nell'ambito di una ricerca esplorativa, abbiamo esaminato la ricerca condotta da Descope e abbiamo deciso di testarla con alcune applicazioni SaaS. Ciò ha coinciso con l'idea di esplorare la Entra App Gallery di Microsoft. La Entra App Gallery è un portale all'interno di Entra ID, gestito da Microsoft, che consente ai fornitori SaaS di terze parti di presentare le applicazioni che si integrano con Entra ID(Figura 12).
Nella nostra ricerca, abbiamo esaminato tutte le 1.017 integrazioni OIDC disponibili in quel momento e abbiamo trovato 104 applicazioni che consentivano l'autoiscrizione all'applicazione. Poiché il mercato SaaS è fortemente competitivo, i fornitori tendono a consentire livelli gratuiti o di prova delle loro applicazioni con poco attrito, consentendo di utilizzare e testare l'applicazione senza dover passare attraverso i canali di vendita. Ci siamo concentrati su queste applicazioni non solo perché offrivano una barriera bassa per la ricerca sulla sicurezza, ma anche per rimanere entro i confini dei test etici.
In ogni applicazione testata, abbiamo utilizzato un tenant "vittima" che abbiamo gestito per configurare un account di nostra proprietà all'interno della piattaforma. Abbiamo poi utilizzato un altro tenant, il tenant "attaccante", per tentare l'abuso di nOAuth contro la nostra vittima. In questo modo, ci siamo assicurati che i nostri test riguardassero solo gli account sotto il nostro controllo e accedessero solo a campioni di dati di prova creati da noi.
La nostra ricerca si differenzia da quella di Descope in quanto eravamo interessati a trovare applicazioni che permettessero l'abuso di Entra ID cross-tenant nOAuth. In sostanza, il cliente bersaglio (vittima) è un cliente Microsoft con un tenant Entra ID e l'attaccante utilizza un altro tenant Entra ID per eseguire l'abuso. Il seguente diagramma di Descope è valido per quanto riguarda il flusso dell'attacco nella nostra ricerca(Figura 13).
Tuttavia, nel nostro caso, l'applicazione SaaS deve solo supportare Entra ID per l'autenticazione. Sebbene quasi tutte le applicazioni SaaS testate supportino un account utente locale, abbiamo riscontrato che alcune applicazioni supportano anche più fornitori di identità, come Google ed Entra ID, mentre altre supportano solo Entra ID.
Inoltre, abbiamo ipotizzato che se un'applicazione supportava solo Entra ID per l'autenticazione, era improbabile che lo sviluppatore avesse implementato la logica di fusione degli account e la verifica delle e-mail rilevata da Descope, in quanto probabilmente lo sviluppatore non si aspettava uno scenario di collisione degli account.
Applicazioni vulnerabili
Nei test effettuati su 104 applicazioni, ne abbiamo trovate 9 vulnerabili all'abuso di nOAuth; ciò significa che la vulnerabilità riguarda circa il 9% delle applicazioni testate. Poiché 104 applicazioni sono solo una goccia nel mare delle applicazioni SaaS integrate con Entra ID, è possibile estrapolare questi numeri rispetto alle decine di migliaia di applicazioni SaaS disponibili.
Tra le applicazioni che abbiamo trovato vulnerabili, abbiamo notato alcune osservazioni interessanti relative alle dimensioni, alla scala e al tipo di applicazione. Abbiamo trovato una piattaforma di sistema di gestione delle risorse umane (HRMS) che, in pratica, sarebbe probabilmente piena di PII. Allo stesso modo, abbiamo trovato applicazioni che si integravano con Microsoft 365 per attività quali l'accesso alla posta e al calendario. Poiché queste integrazioni utilizzano una serie diversa di combinazioni di token di accesso e di aggiornamento, un utente malintenzionato che riesca ad abusare di nOAuth sarebbe in grado non solo di ottenere l'accesso ai dati dell'applicazione SaaS, ma anche potenzialmente di accedere alle risorse di Microsoft 365.
Purtroppo, i test su scala richiedono molto tempo. Oltre a configurare il tenant Entra per eseguire l'abuso, avevamo bisogno di una serie di occhi umani sull'interfaccia dell'applicazione SaaS per determinare se l'attaccante era in grado di ottenere l'accesso all'account della vittima. Sebbene la maggior parte delle applicazioni invulnerabili a questo abuso presentasse in genere un nuovo flusso di accesso all'applicazione, alcune ci hanno semplicemente fatto entrare nella schermata principale dell'applicazione, richiedendoci di esaminare le informazioni sull'account o di tentare di manipolare i dati all'interno dell'applicazione per determinare se l'aggressore fosse nello stesso account della vittima.
Contattare le parti interessate
A seguito di questa ricerca, abbiamo aperto un caso con MSRC. Abbiamo anche cercato di determinare gli stakeholder di ogni ISV che aveva un'applicazione vulnerabile. Dopo aver contattato queste parti interessate, seguendo il principio di Semperis di essere una forza per il bene, ci siamo offerti di aiutarle a risolvere la vulnerabilità nella loro applicazione; alcuni fornitori hanno accettato l'offerta. In questi casi, abbiamo aiutato i fornitori a comprendere il problema ed eseguito ulteriori test sull'abuso di nOAuth contro le loro applicazioni fino a quando il problema non è stato risolto.
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:
- Autenticazione a più fattori (MFA) e forza di autenticazione in Entra ID
- Accesso condizionato
- Soluzioni Zero Trust Network Access (ZTNA) e Cybersecurity for Any Business (CASB)
- Rilevamento e risposta degli endpoint (EDR)
- Rilevamento e risposta estesi (XDR)
Rilevamento abusi nOAuth
Sebbene le soluzioni di SaaS Security Posture Management (SSPM) possano fornire alcune informazioni sulle applicazioni SaaS, in genere si concentrano sulla configurazione e sulla sicurezza esposta ai clienti della piattaforma e non sono in grado di indicare un abuso di nOAuth. Problemi analoghi si riscontrano con le piattaforme secure-browser aziendali e i plug-in del browser, che possono aiutare a evidenziare altre backdoor nelle applicazioni SaaS, ma è improbabile che facciano emergere questo tipo di attacco.
Purtroppo, questo lascia poche opzioni ai clienti:
- Correlazione dei log di autenticazione SaaS con Entra ID all'interno di una piattaforma SIEM
- Chiedere ai propri fornitori informazioni su nOAuth
- Eseguire autonomamente i test di abuso di nOAuth
Dal punto di vista dell'Entra ID, abbiamo esaminato i principi di servizio delle applicazioni multi-tenant e non abbiamo trovato alcun attributo esposto a un cliente che indicasse che l'applicazione consuma richieste di posta elettronica non verificate. Anche se tali attributi esistessero, non ci sarebbe modo di indicare per cosa l'applicazione utilizzi questa richiesta.
Correlazione dei log di autenticazione
Per utilizzare la correlazione dei registri per rilevare l'abuso di nOAuth, è necessario consumare i registri di autenticazione Entra ID in una soluzione di gestione delle informazioni e degli eventi di sicurezza (SIEM), come Microsoft Sentinel. È inoltre necessario consumare i registri di autenticazione dell'applicazione SaaS e correlare i due registri all'interno del SIEM. È necessario cercare gli eventi di autenticazione nella piattaforma SaaS con un evento di autenticazione mancante in Entra ID(Figura 14).
Naturalmente, i risultati della messa in pratica di questa teoria varieranno notevolmente. Sebbene l'oggetto(sub) sia l'identificatore chiave nell'applicazione SaaS, questo valore non viene catturato nei log di accesso Entra ID durante l'autenticazione. Pertanto, l'applicazione SaaS dovrebbe contenere anche attributi come l'UPN o l'indirizzo e-mail all'interno dei suoi log per la correlazione. Allo stesso modo, i log di autenticazione del fornitore SaaS devono essere disponibili in modo da poter essere utilizzati da un SIEM. Altri fattori, come la deriva temporale e la precisione, possono aumentare la difficoltà di rilevare un abuso di nOAuth attraverso la correlazione dei log.
Test per nOAuth e responsabilità del fornitore
L'unica alternativa per un cliente è quella di testare le applicazioni SaaS che utilizza per verificare l'abuso di nOAuth. Prima di farlo, può contattare il fornitore dell'applicazione per chiedere se è a conoscenza di nOAuth e se ha effettuato test contro l'abuso di nOAuth.
Alcuni elementi da notare:
- Certificazioni come il SOC II non hanno indagato su questo abuso. Abbiamo trovato applicazioni vulnerabili i cui fornitori avevano elencato sui loro siti le certificazioni SOC II e altre certificazioni.
- Chiedete al fornitore se ha effettuato test contro questa vulnerabilità. Abbiamo trovato fornitori che credevano di aver risolto il problema, ma siamo stati ancora in grado di eseguire abusi nOAuth contro le loro applicazioni.
Se il fornitore non è in grado di rispondere in modo definitivo a questa domanda, il cliente può eseguire il test su qualsiasi applicazione di interesse. Proprio come i ricercatori di sicurezza, i clienti devono assicurarsi di eseguire i test entro i limiti dell'etica: testando i propri account utente e comprendendo eventuali requisiti contrattuali con il fornitore.
Difesa degli sviluppatori di software contro nOAuth
Gli sviluppatori che utilizzano la richiesta di e-mail devono verificare di non utilizzarla per l'identificazione dell'utente. In tal caso, devono seguire i passaggi documentati da Microsoft per seguire le specifiche OIC, utilizzando issuer e subject.
Gli sviluppatori possono anche esaminare le registrazioni delle loro app per determinare se stanno ricevendo l'indicazione di un'e-mail non verificata. Tuttavia, spetta allo sviluppatore esaminare il proprio codice per determinare come viene utilizzata l'indicazione dell'e-mail.
Esistono anche soluzioni alternative per ricevere i dati dell'attributo dell'e-mail che non provengano da una richiesta nel token ID. OIDC specifica un endpoint UserInfo, implementato all'interno di Entra ID. Questo endpoint può essere utilizzato per ricevere informazioni sull'utente autenticato. Chiamando l'endpoint UserInfo, l'applicazione può ottenere l'indirizzo e-mail dell'utente dopo l'autenticazione, anche se tale indirizzo non è stato verificato. Questo passaggio garantisce che l'indirizzo e-mail non venga utilizzato come identificatore univoco dell'utente.
In questo esempio, possiamo chiamare l'endpoint UserInfo su Adele Vance, che ha un indirizzo e-mail non verificato(Figura 15). L'oggetto, che è l'identificatore unico, corrisponderà a quello del token ID.
Gli sviluppatori che hanno aggiornato il loro codice per risolvere la vulnerabilità nOAuth dovrebbero testare la loro applicazione dopo la correzione per assicurarsi che non sia vulnerabile all'abuso di nOAuth. Nel nostro lavoro di bonifica con i fornitori, la correzione iniziale non sempre ha risolto la vulnerabilità.
Nel comunicare con l'MSRC le nostre scoperte, l'ente ha ribadito che gli sviluppatori devono seguire le raccomandazioni e ci ha rimandato all'articolo che ha pubblicato sulla divulgazione nel 2023. Poiché esistono esigenze legittime per le applicazioni di ottenere l'indirizzo e-mail di un utente, non c'è modo di determinare se un'applicazione utilizza correttamente l'attributo senza testare ogni applicazione. Come abbiamo notato nei nostri test, si tratta di un processo che richiede molto tempo.
MSRC ha inoltre dichiarato di aver comunicato con i fornitori di applicazioni e che quelli che non hanno sistemato le loro applicazioni sono soggetti alla rimozione dalla Entra App Gallery.
Divulgazione e tempistica
Sorpresi di trovare un abuso di nOAuth, soprattutto nelle applicazioni pubblicate nella Entra Gallery, abbiamo aperto un caso con MSRC (assegnato con il numero 93209).
Abbiamo inoltre esortato il Microsoft Identity Product Group a essere più aggressivo nella protezione dei clienti, considerando la difficoltà di rilevamento degli abusi di nOAuth. Abbiamo suggerito di avvertire i clienti dei committenti del servizio che l'applicazione consente di inviare messaggi di posta elettronica non verificati, anche se, come abbiamo notato, non sarebbe un identificatore assoluto di vulnerabilità a nOAuth.
Abbiamo anche indicato le nove applicazioni vulnerabili che abbiamo trovato, nel caso in cui MSRC fosse in contatto con quei fornitori.
- 3 dicembre 2024: Caso creato con MSRC
- 3 dicembre 2024: Caso riconosciuto dal MSRC
- 4 dicembre 2024: Abbiamo fornito ulteriori dettagli sul caso a MSRC
- 17 dicembre 2024: Abbiamo aggiornato il caso con MSRC, segnalando che abbiamo lavorato con un fornitore per risolvere una delle applicazioni vulnerabili.
- 17 marzo 2025: Abbiamo chiesto al MSRC lo stato del caso; non abbiamo ricevuto risposta.
- 18 marzo 2025: Abbiamo notificato al MSRC nel portale l'intenzione di divulgare la sessione di Troopers 2025 (se selezionata).
- 19 marzo 2025: Abbiamo comunicato via e-mail a MSRC l'intenzione di divulgare la vulnerabilità durante la sessione di Troopers (se selezionata) e abbiamo chiesto indicazioni sulla divulgazione, dato che la vulnerabilità originale era già stata divulgata; non abbiamo 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: Abbiamo testato e trovato fornitori di applicazioni che erano vulnerabili a nOAuth; abbiamo notificato nuovamente i fornitori e abbiamo contattato MSRC con le nostre scoperte.
- Giugno 2025: MSRC ha fornito dettagli sulle applicazioni vulnerabili a nOAuth nella galleria delle applicazioni Entra.
- 26 giugno 2025: Divulgazione al pubblico
