Eric Woodruff | Responsabile dell'architettura dell'identità

Risultati principali

  • Nel testare altre 38 applicazioni dopo la nostra ricerca iniziale, Semperis ha individuato 2 applicazioni vulnerabili all'abuso di nOAuth. Abbiamo segnalato i nostri risultati relativi a queste due applicazioni ai fornitori del software.
  • Una delle applicazioni vulnerabili disponeva di autorizzazioni che consentivano a un aggressore di rientrare in Microsoft 365, rafforzando l'idea che nOAuth può mettere in pericolo non solo i dati nell'applicazione SaaS, ma anche il patrimonio Microsoft 365 di un'organizzazione.
  • Nel nostro ultimo caso con il Microsoft Security Response Center, MSRC ha classificato questa vulnerabilità come moderata. Tuttavia, Semperis conferma la nostra valutazione di GRAVE. nOAuth è ancora difficile da rilevare per i clienti delle applicazioni vulnerabili e impossibile da difendere per i clienti delle applicazioni vulnerabili. L'abuso è documentato pubblicamente ed è di bassa complessità una volta individuata un'applicazione vulnerabile.

Questo articolo è il seguito della nostra ricerca originale su nOAuth. Anche se sembra ieri che abbiamo pubblicato i risultati di tale ricerca al TROOPERS25 e al fwd:cloudsec 2025, la nostra ricerca è iniziata nell'autunno del 2024.

Dopo aver condotto ulteriori ricerche su nOAuth sei mesi dopo il nostro primo colloquio e poi nuovamente un anno dopo la nostra ricerca iniziale, abbiamo scoperto che il rischio di abuso di nOAuth esiste ancora e che molte organizzazioni non sono ancora consapevoli di questa vulnerabilità.

Durante i mesi di ottobre e novembre 2025, abbiamo testato altre 38 applicazioni per verificare la presenza di abusi nOAuth e ne abbiamo individuate 2 vulnerabili. Durante la nostra precedente ricerca, abbiamo testato 104 applicazioni e ne abbiamo individuate 9 vulnerabili. Ciò significa che, in termini percentuali cumulativi, circa l'8% delle app disponibili è vulnerabile a nOAuth.

Comprendere come le app SaaS si integrano con Microsoft 365

Microsoft Graph API è l'API unificata per accedere a tutti i servizi Microsoft 365: Exchange Online, SharePoint, OneDrive e la maggior parte degli altri servizi Microsoft 365. Le applicazioni SaaS di terze parti che desiderano integrarsi con questi servizi richiedono l'accesso a Microsoft Graph in modo da poter interagire con i dati o i servizi degli utenti per loro conto.

Un esempio è Calendly, che richiede l'autorizzazione all'accesso al calendario dell'utente per poter gestire i suoi appuntamenti in Office 365 (Figura 1). Per chiarezza, Calendly non è vulnerabile a nOAuth. Lo stiamo semplicemente utilizzando come applicazione di riferimento per aiutarti a comprendere il comportamento comune delle applicazioni SaaS.

Screenshot che mostra le autorizzazioni concesse all'app Calendly affinché possa essere utilizzata per gestire gli appuntamenti del calendario.
Figura 1. Autorizzazioni Calendly che consentono l'accesso in lettura/scrittura al calendario

Quando un utente accede all'applicazione, purché abbia acconsentito alle autorizzazioni, l'applicazione SaaS riceve un token di accesso OAuth 2.0 da Entra ID. L'applicazione utilizza quindi tale token di accesso con l'API Microsoft Graph per accedere al servizio. In questo esempio, il token di accesso fornito a Calendly dispone delle autorizzazioni Calendar.ReadWrite e Calendar.ReadWrite.Shared.

In molti scenari, l'applicazione SaaS riceve anche un token di aggiornamento (Figura 2). Questo token consente all'applicazione SaaS di mantenere l'accesso ai dati dell'utente, anche se l'utente non sta utilizzando attivamente l'applicazione.

Screenshot che mostra le autorizzazioni concesse all'app Calendly affinché possa utilizzare un token di aggiornamento
Figura 2. Autorizzazioni Calendly che consentono di utilizzare un token di aggiornamento

Perché le applicazioni SaaS necessitano di questo tipo di accesso? Nel nostro esempio, questo accesso consente a Calendly di prenotare gli appuntamenti dei clienti sul tuo calendario, anche se non stai utilizzando attivamente l'app. In questo modo, l'applicazione SaaS può continuare a "lavorare" con i tuoi dati dietro le quinte.

Questo è ottimo per la produttività e non c'è nulla di intrinsecamente sbagliato nelle autorizzazioni richieste. Tuttavia, quando tali autorizzazioni sono combinate con la vulnerabilità a nOAuth, si creano le condizioni affinché gli aggressori possano abusare dell'app e, potenzialmente, tornare a Microsoft 365.

La differenza tra autenticazione e autorizzazione

Per comprendere appieno in che modo nOAuth può facilitare il ritorno a Microsoft 365, è necessario sapere che OpenID Connect (OIDC) facilita l'autenticazione con un token ID, mentre OAuth 2.0 facilita l'autorizzazione con un token di accesso. Quando un token di aggiornamento accompagna un token di accesso, l'applicazione SaaS può ottenere nuovi token di accesso indipendentemente dal fatto che l'utente sia autenticato.

Mettendo da parte le sfumature linguistiche relative all'identità, OIDC facilita l'accesso di un utente a un'applicazione. OAuth 2.0 facilita le autorizzazioni che un'applicazione ha sui dati di un utente. Un token di aggiornamento consente all'applicazione di accedere ai dati dell'utente, anche se l'utente non ha effettuato l'accesso (Figura 3).

Un diagramma che mostra la differenza tra autenticazione e autorizzazione
Figura 3. Diagramma che mostra la differenza tra autenticazione e autorizzazione

Quando un utente accede per la prima volta a un'applicazione, potrebbero verificarsi l'autenticazione e l'autorizzazione: l'applicazione potrebbe ricevere un token ID per l'utente e un token di accesso in modo che l'app possa accedere alle risorse di Microsoft 365. Per l'utente finale, questo processo è generalmente trasparente, tranne quando l'applicazione non è mai stata utilizzata ed è necessario il consenso.

Esistono numerosi framework e librerie per la gestione dei token, ma alla fine è lo sviluppatore dell'applicazione SaaS a determinare come vengono gestiti i token.

Quando un utente effettua successivamente l'autenticazione, l'applicazione può (o meno) tentare di richiedere un nuovo token di accesso e di aggiornamento, se i token esistenti sono ancora validi. Poiché l'autenticazione e l'autorizzazione sono essenzialmente trattate come funzioni diverse, questa disconnessione tra i due flussi consente agli aggressori di agire.

Abuso di nOAuth per il passaggio a Microsoft 365

Durante la nostra ricerca iniziale, abbiamo scoperto un'applicazione vulnerabile che aveva integrazioni con Microsoft 365 con autorizzazioni Calendars.ReadWrite.Shared. Secondo la documentazione Microsoft, questa integrazione:

Consente all'app di creare, leggere, aggiornare ed eliminare eventi in tutti i calendari dell'organizzazione a cui l'utente ha il permesso di accedere. Ciò include i calendari delegati e condivisi.

Preoccupante, ma non tale da consentire un attacco come il business email compromise (BEC).

Questa volta abbiamo riscontrato un insieme di autorizzazioni molto più ampio e preoccupante (Figura 4):

  • Calendari.LeggiScrivi
  • Invia posta
  • Contatti.LeggiScrivi
  • Posta.LeggiScrivi
  • accesso offline
Figura 4. Autorizzazioni sull'applicazione vulnerabile

Come accennato in precedenza, queste autorizzazioni sono preoccupanti perché consentono a un aggressore non solo di compromettere l'utente all'interno dell'applicazione SaaS, ma anche di utilizzare l'interfaccia dell'app per tornare a Microsoft 365.

Ricordiamo che l'autenticazione e l'autorizzazione sono funzioni diverse con token diversi. L'autore dell'attacco ottiene essenzialmente il controllo sull'accesso degli utenti in Microsoft 365 tramite i token di accesso e di aggiornamento gestiti all'interno dell'applicazione SaaS (Figura 5).

Diagramma che illustra un esempio di alto livello di un aggressore che ottiene l'accesso all'account di un utente legittimo
Figura 5. Visualizzazione di un aggressore che ottiene l'accesso all'account di un utente legittimo

Nell'applicazione SaaS vulnerabile, questo comportamento si manifesta con la possibilità per un malintenzionato di inviare e-mail spacciandosi per l'utente compromesso (Figura 6).

Screenshot delle e-mail che impersonano un utente compromesso
Figura 6. E-mail inviata come utente compromesso dall'applicazione SaaS

Poiché l'e-mail proviene da un utente legittimo nel tenant, l'autore dell'attacco dispone ora di un modo efficace per agire come utente compromesso all'interno di Exchange Online (Figura 7).

Screenshot che mostra il contenuto di un'e-mail fraudolenta
Figura 7. L'e-mail ricevuta dalla nostra simulazione di attacco

L'autore dell'attacco non ha accesso diretto al token di accesso, quindi l'interfaccia utente dell'applicazione SaaS determina in che modo può interagire con le risorse di Microsoft 365. Tuttavia, questi risultati rafforzano le nostre preoccupazioni di lunga data relative a nOAuth e al potenziale accesso ai dati e ai percorsi laterali che può consentire.

Ricercare nOAuth è come cercare di dimostrare una negazione

Quando abbiamo pubblicato i nostri risultati nel giugno 2025, le domande più frequenti che abbiamo ricevuto riguardavano il numero totale di applicazioni potenzialmente vulnerabili. Ciò è comprensibile, poiché i numeri indefiniti non fanno notizia.

Tuttavia, era ed è tuttora impossibile quantificare il numero di applicazioni potenzialmente vulnerabili. Una ricerca sul numero di applicazioni SaaS esistenti restituisce un risultato compreso tra 70.000 e oltre 300.000. Il catalogo delle app Microsoft 365 Defenders Cloud elenca 36.932 applicazioni SaaS, ma non tutte si integrano con Entra ID per l'autenticazione.

Indipendentemente da come si calcolino i numeri, si tratterà sempre di una stima approssimativa. Nella fascia bassa, se il 50% di tutte le applicazioni utilizza Entra ID per l'autenticazione, testare 142 (su 35.000) applicazioni ci porta allo 0,4% di test effettuati. Nella fascia alta (di 150.000 app), ci porterebbe allo 0,098% di test effettuati.

In Troopers ho affermato che abbiamo trovato nove applicazioni vulnerabili, ma dubito che abbiamo individuato il 90% di tutte le app vulnerabili. Ora, con le nostre nuove scoperte, dubito che 11 sia il numero totale delle applicazioni vulnerabili esistenti. È semplicemente impossibile saperlo.

Microsoft saprebbe quante applicazioni sono configurate con removeUnverifiedEmailClaim impostato su false e quante app sono esentate dall'uso di questa richiesta. Ma ciò non indica se l'applicazione è vulnerabile.

Per quanto riguarda le autorizzazioni, sebbene abbiamo riscontrato abusi solo nelle applicazioni che integrano Exchange Online, anche le integrazioni con SharePoint e OneDrive sono altrettanto diffuse. Sarebbe ingenuo credere che solo una certa percentuale delle applicazioni con queste integrazioni sia vulnerabile a nOAuth. Esistono centinaia di altre autorizzazioni Microsoft Graph, molte delle quali sarebbero altamente preoccupanti se finissero nelle mani di un malintenzionato. In realtà, questo è l'obiettivo principale di un altro attacco molto comune: la concessione illecita di consensi.

Cronologia e risposta dell'MSRC

  • 18 novembre 2025: grazie alle nuove scoperte relative a Microsoft 365 e alla possibilità di ripristinare l'accesso, abbiamo aperto un caso con MSRC. Abbiamo fornito tutti i dettagli delle scoperte, sia per iscritto che in un video che mostra l'attacco contro il nostro utente di prova. Abbiamo anche chiesto a MSRC di eliminare la possibilità di inviare una richiesta di verifica tramite e-mail non verificata. Come discusso nel nostro post originale, esistono altri modi per ricevere la richiesta di verifica tramite e-mail.
  • 3 dicembre 2025: MSRC ha risposto che il caso è considerato a rischio moderato e lo ha chiuso. Nella sua risposta, MSRC ha dichiarato quanto segue:

Dopo un'attenta analisi, abbiamo valutato questo caso come vulnerabilità di gravità moderata. I nostri rispettivi team di prodotto/servizio sono stati informati in merito e potrebbero lavorare all'aggiunta di ulteriori meccanismi di difesa approfondita, se necessario, nelle versioni future.

Di conseguenza, chiudiamo il caso.

Perché nOAuth è ancora importante

Continueremo a ricercare le applicazioni vulnerabili a nOAuth e a promuovere il cambiamento in Microsoft, per molteplici ragioni:

  • L'abuso di nOAuth è documentato pubblicamente.
  • La ricerca ha dimostrato l'accesso a informazioni sensibili in piattaforme quali i sistemi di gestione delle risorse umane (HRMS).
  • La ricerca ha dimostrato che esistono potenziali percorsi di movimento laterale per tornare a Microsoft 365.
  • I clienti delle applicazioni vulnerabili non hanno alcuna difesa contro nOAuth.
  • I ricercatori nel campo della sicurezza hanno dimostrato che individuare i clienti delle applicazioni SaaS è relativamente facile.
  • Anche utilizzare piattaforme come LinkedIn per individuare utenti privilegiati di applicazioni SaaS e dedurne gli indirizzi e-mail è semplice.

Istantanea Semperis

Sebbene le organizzazioni aziendali non dispongano di difese efficaci contro nOAuth, è importante comprendere il rischio relativo ai propri dati. Prima di adottare una nuova applicazione SaaS, chiedete al fornitore se è a conoscenza della ricerca su nOAuth e segnalategli i nostri blog.

Per i fornitori e gli sviluppatori, seguire le specifiche OpenID Connect di Microsoft è fondamentale per garantire che la propria applicazione non sia vulnerabile a nOAuth. Per ulteriori dettagli, fare riferimento alla nostra precedente ricerca.

Risorse correlate

• Avviso di abuso nOAuth: acquisizione completa dell'account delle applicazioni SaaS cross-tenant Entra
• Sessione on-demand nOAuth (TROOPERS25)