Risultati principali
- Golden SAML, una tecnica di attacco che sfrutta il protocollo SAML single sign-on, è stata utilizzata come exploit successivo alla violazione, aggravando il devastante attacco SolarWinds del 2020, una delle più grandi violazioni del 21° secolo.
- L'attacco alla catena di fornitura SolarWinds ha colpito migliaia di organizzazioni in tutto il mondo, compreso il governo degli Stati Uniti, distribuendo codice maligno nel software di gestione e monitoraggio IT Orion dell'azienda.
- Sulla scia di questo attacco, gli esperti CISA e di cybersecurity hanno incoraggiato le organizzazioni con ambienti di identità ibridi a spostare l'autenticazione SAML su un sistema di identità cloud come Entra ID.
- I ricercatori di Semperis Tomer Nahum ed Eric Woodruff hanno scoperto una nuova applicazione di Golden SAML, che può essere sfruttata anche dalle organizzazioni che hanno seguito le precedenti raccomandazioni di sicurezza per difendersi da Golden SAML.
- La nuova tecnica di attacco, denominata Silver SAML, consente di sfruttare SAML per lanciare attacchi da un fornitore di identità come Entra ID contro applicazioni configurate per utilizzarlo per l'autenticazione, come Salesforce.
- A conoscenza di Semperis, non sono stati segnalati attacchi che utilizzano Silver SAML.
- I ricercatori di Semperis valutano questa vulnerabilità come un rischio MODERATO per le organizzazioni. A seconda del sistema compromesso, se Silver SAML viene utilizzato per ottenere un accesso non autorizzato ad applicazioni e sistemi critici per l'azienda, il rischio è GRAVE.
Golden SAML è una tecnica di attacco nota, scoperta da CyberArk e pubblicata da Shaked Reiner. Da anni, Golden SAML è noto per l'estrazione di certificati di firma da Active Directory Federation Services (AD FS) e per l'utilizzo di tali certificati per falsificare le risposte di autenticazione SAML. Oggi presentiamo una nuova applicazione di Golden SAML in Microsoft Entra ID e senza l'uso di AD FS. Ecco Silver SAML.
Che cos'è Silver SAML?
Oggi molte organizzazioni utilizzano Entra ID come identity provider (IdP) per applicazioni software-as-a-service (SaaS) e line-of-business (LOB). SAML è il mezzo principale di autenticazione per queste applicazioni.
In Entra ID, Microsoft fornisce un certificato autofirmato per la firma delle risposte SAML. In alternativa, le organizzazioni possono scegliere di utilizzare un certificato generato esternamente. Tuttavia, questa opzione introduce un rischio per la sicurezza.
Qualsiasi aggressore che ottenga la chiave privata di un certificato generato esternamente può falsificare qualsiasi risposta SAML e firmarla con la stessa chiave privata in possesso di Entra ID. Con questo tipo di risposta SAML falsificata, l'aggressore può accedere all'applicazione come qualsiasi utente.
Il proof of concept discusso in questo post si concentra su Entra ID. Ma questo attacco può essere sfruttato da qualsiasi IdP che consenta l'importazione di certificati di firma SAML generati esternamente.
Per questa prova di concetto, Semperis ha costruito e pubblicato un nuovo strumento, chiamato SilverSAMLForger, che può essere utilizzato per falsificare le risposte SAML firmate. SilverSAMLForger è disponibile su GitHub.
Premessa: SAML, Golden SAML e l'attacco di SolarWinds
SAML è un punto fermo dell'autenticazione moderna. Ad esempio, il 63% delle applicazioni Entra ID Gallery si basa su SAML per l'integrazione. Le integrazioni multi-cloud con Amazon Web Services (AWS), Google Cloud Platform (GCP) e altri si basano su SAML. E molte organizzazioni continuano a investire in SAML per le applicazioni SaaS e LOB grazie alla semplicità della sua implementazione.
SAML d'oro e Solorigate
Nell'ambito dell'attacco alla catena di fornitura globale di SolarWinds (alias Solorigate), Golden SAML è stato uno dei vettori di attacco più innovativi degli aggressori.
Gli aggressori hanno ottenuto l'accesso iniziale a SolarWinds inserendo codice dannoso nella piattaforma Orion dell'azienda, utilizzata per il monitoraggio dell'infrastruttura e la gestione IT. In seguito, gli aggressori hanno sfruttato questo punto d'appoggio per spostarsi lateralmente nell'ambiente AD FS. Da qui hanno rubato il materiale della chiave privata utilizzata per firmare le risposte SAML.
A seguito di questo attacco Golden SAML post-breach, molte organizzazioni hanno dato priorità al passaggio delle applicazioni a Entra ID per l'autenticazione SAML. Questo cambiamento ha eliminato la necessità di gestire una complessa infrastruttura Tier 0 e le chiavi di firma SAML non possono essere esportate da Entra ID. Anche il CISA raccomanda alle organizzazioni con ambienti di identità ibridi di spostare l'autenticazione SAML su sistemi di identità cloud come Entra ID.
Il problema di SAML e dei certificati di firma
Purtroppo, molte organizzazioni gestiscono male i certificati di firma e indeboliscono la sicurezza SAML utilizzando certificati generati esternamente. Dalle nostre osservazioni, le organizzazioni aziendali tendono a:
- Generare certificati di firma autofirmati su un sistema client
- Generare certificati di firma attraverso un'infrastruttura a chiave pubblica (PKI) aziendale, come Active Directory Certificate Services (AD CS).
- Ottenere e utilizzare certificati di firma da un'autorità di certificazione (CA) esterna.
Ad aggravare il problema, ci sono poi le organizzazioni che prendono questi certificati generati esternamente e..:
- Inviare i file PFX dei certificati e le password attraverso canali non sicuri come Teams o Slack.
- Generare i certificati sui computer client, lasciando i certificati disponibili per l'esportazione nell'archivio certificati locale dei computer.
- Generare i certificati sui server web, in genere Microsoft Internet Information Services (IIS), lasciando i certificati disponibili per l'esportazione nell'archivio di certificati locale delle macchine.
Anche per le organizzazioni che utilizzano servizi come Azure Key Vault - un metodo più sicuro per la gestione dei segreti e dei certificati - possono esistere vettori di attacco. (Questi vettori saranno trattati nella prossima sezione).
L'utilizzo di un certificato generato esternamente per la firma delle risposte SAML aumenta la superficie di attacco di qualsiasi IdP, incluso Entra ID. Abbiamo osservato diverse lezioni comuni nelle organizzazioni che generano e gestiscono i certificati di firma SAML esternamente, anziché direttamente all'interno di Entra ID.
- Mancanza di una catena di fiducia con i certificati autofirmati da Entra ID
- Impossibilità di sfruttare la revoca dei certificati con i certificati autofirmati
- Necessità di applicare alla cieca una politica aziendale definita alla gestione dei certificati (di solito basata su uno o entrambi i motivi precedenti)
- La sensazione soggettiva che i certificati autofirmati siano "meno sicuri".
Inoltre, alcune organizzazioni desiderano mantenere una durata del certificato di firma SAML superiore a quella predefinita di Entra ID. Queste organizzazioni emettono certificati esterni, senza rendersi conto che possono semplicemente emettere nuovi certificati da Entra ID e configurare tali certificati in modo che abbiano una durata maggiore.
Molte organizzazioni non comprendono le sfumature dell'utilizzo dei certificati per la firma SAML; i certificati di firma sono semplicemente inglobati nelle direttive e nelle politiche di gestione dei certificati più ampie. Sebbene le pratiche comuni di gestione e ciclo di vita dei certificati siano importanti per molti tipi di sistemi, non si applicano e non dovrebbero applicarsi ai certificati utilizzati per la firma SAML.
La catena di fiducia non è rilevante in SAML. La maggior parte degli IdP e delle applicazioni dei Service Provider (SP) ignora qualsiasi catena di fiducia. A differenza dello scenario server/client che si verifica con i browser web, l'amministratore è effettivamente una parte essenziale della catena di fiducia nelle configurazioni SAML. L'amministratore deve configurare e specificare il certificato di firma di cui fidarsi, in particolare nell'applicazione.
Anche la revoca dei certificati è una pratica rilevante con SAML. Se un certificato di firma è compromesso, un amministratore deve ruotare (cioè sostituire) il certificato nell'SP e nell'IdP. L'OASIS SAML 2.0 Metadata Interoperability Profile Version 1.0 indica specificamente di non utilizzare liste di revoca, Online Certificate Status Protocol (OCSP) o altri meccanismi per la convalida delle chiavi. È invece necessario che l'IdP rimuova le chiavi compromesse dai metadati SAML.
Importazione di certificati esterni
Come mostra la Figura 1, è possibile configurare certificati autofirmati su un'applicazione aziendale (Okta, in questo esempio) nel centro di amministrazione Entra tramite le impostazioni Gestione > Single sign-on > SAML > Certificati SAML dell'applicazione.
Nel riquadro Certificato di firma SAML è possibile importare il proprio certificato per firmare la risposta o le asserzioni SAML(Figura 2).
E Azure Key Vault?
Dobbiamo soffermarci un attimo su Azure Key Vault: uno dei luoghi in cui possono essere archiviati i certificati autofirmati. Volevamo determinare se un aggressore potesse estrarre le chiavi da Key Vault. Spoiler: È possibile. (Se la vostra organizzazione non utilizza Key Vault, passate pure alla sezione successiva).
Azure Key Vault è una famosa soluzione di gestione delle chiavi fornita da Microsoft. Key Vault consente di archiviare e gestire in modo sicuro segreti, chiavi di crittografia e certificati.
Come la maggior parte dei servizi cloud, Key Vault ha due piani che regolano l'accesso e la gestione: il piano di controllo e il piano dati.
- Piano di controllo. I ruoli e le autorizzazioni assegnati al piano di controllo sono associati alle attività amministrative e alle impostazioni di configurazione del Key Vault. Gli utenti, i gruppi o i service principal a cui sono assegnate le autorizzazioni del piano di controllo possono configurare i criteri di accesso, creare i vault delle chiavi ed eseguire altre attività di gestione. I diritti possono essere concessi in modo granulare a un singolo vault, ma spesso sono concessi a livello di gruppo di risorse, abbonamento o gruppo di gestione.
- Piano dati. Il piano dei dati si riferisce ai dati effettivi memorizzati in un caveau delle chiavi: segreti, chiavi e certificati. I diritti assegnati sul piano dati controllano quali utenti o committenti del servizio possono leggere e scrivere materiale crittografico da e verso il caveau delle chiavi. Questi diritti includono la possibilità di leggere le chiavi private dei certificati, il che rappresenta un problema se tali chiavi sono utilizzate per la firma delle risposte SAML.
Le autorizzazioni del Key Vault possono essere concesse tramite il controllo degli accessi basato sui ruoli (RBAC) o i criteri di accesso del Key Vault.
Il modello di permessi RBAC
Con il modello RBAC(Figura 3), qualsiasi utente che ricopre uno dei seguenti ruoli RBAC può recuperare il certificato di un caveau di chiavi.
- Amministratore del Key Vault
- Addetto ai certificati Key Vault
- Amministratore accesso dati Key Vault. Questo ruolo consente di gestire l'accesso aggiungendo o rimuovendo le assegnazioni di ruolo. Pertanto, è possibile assegnare il ruolo di Key Vault Administrator o Key Vault Certificates Officer a qualsiasi entità.
- Collaboratore del vault delle chiavi. Questo ruolo non concede autorizzazioni per il piano dati, ma consente di aggiornare i criteri di accesso del caveau delle chiavi se si utilizza anche il modello di autorizzazione dei criteri di accesso.
La Figura 4 mostra un esempio di autorizzazioni concesse al ruolo Key Vault Administrator.
Una persona che detiene il ruolo Key Vault Contributor, che non ha autorizzazioni sul piano dati per accedere ai segreti e ai certificati del caveau delle chiavi, può comunque estrarli se vengono utilizzati i criteri di accesso. Questo ruolo dispone dell'autorizzazione del piano di controllo Microsoft.KeyVault/*. Questa autorizzazione può essere tradotta in Microsoft.KeyVault/vault/accessPolicies/write, consentendo al titolare di scrivere i criteri di accesso al caveau delle chiavi e di estrarre i segreti del caveau delle chiavi.
Se è possibile aggiungere le autorizzazioni RBAC a livello di gruppo di risorse o di abbonamento, ottenendo il controllo di un account del proprietario del gruppo di risorse o di un account utente che dispone dell'autorizzazione RBAC dell'amministratore del controllo dell'accesso basato sui ruoli o di qualsiasi utente con l'autorizzazione Microsoft.Authorization/roleAssignments/write, è possibile aggiungere le autorizzazioni del caveau delle chiavi. Il caveau delle chiavi erediterà quindi tali autorizzazioni. Come già detto, alcuni ruoli RBAC possono anche modificare direttamente i criteri di accesso al Key Vault.
È possibile accedere ai caveau delle chiavi anche tramite gli account di automazione e le identità gestite che dispongono delle autorizzazioni necessarie.
Il modello di autorizzazioni delle politiche di accesso al Key Vault
In questo modello, è possibile concedere le autorizzazioni di accesso al Key Vault a un utente, servizio o gruppo. È possibile scegliere tra autorizzazioni per chiavi, autorizzazioni per segreti e autorizzazioni per certificati(Figura 5).
È possibile aggiungere criteri di accesso nel riquadro Criteri di accesso del Key Vault (Figura 6).
Qualsiasi aggressore che ottenga il controllo di qualsiasi utente, service principal o gruppo che abbia l'autorizzazione a recuperare il file PFX utilizzato per firmare le asserzioni o le risposte SAML per l'SP attaccato, attraverso le politiche di accesso RBAC o Key Vault, può eseguire un attacco Silver SAML su tale SP.
SAML e Entra ID
SAML, nella sua attuale versione 2.0, ha quasi 20 anni. OASIS ha pubblicato il protocollo nel marzo 2005. Da allora, molte aziende hanno adottato SAML per l'autenticazione federata e le soluzioni SSO basate sul Web. L'implementazione principale del protocollo, e il caso d'uso all'interno di Entra ID, è lo sfruttamento del profilo SSO del browser web.
Un tipico flusso di profili SAML ha tre componenti fondamentali:
- Il service provider (SP), o applicazione; comunemente indicato anche come relying party (RP) nell'ecosistema Microsoft.
- L'Identity Provider (IdP), che nel nostro proof of concept è Entra ID
- L'agente utente, in genere il browser web del cliente (utente finale)
Gli utenti interagiscono con le applicazioni per l'autenticazione in diversi modi, a seconda che l'applicazione sia configurata o supporti flussi avviati dall'SP o dall'IdP.
In un flusso avviato dall'SP(Figura 7), si verifica la seguente sequenza:
- L'utente naviga verso un URL per l'applicazione (SP).
- L'SP genera una richiesta SAML(Figura 8) e reindirizza l'utente all'Entra ID (IdP).
- Entra ID consuma la richiesta SAML.
- Se l'utente non si è ancora autenticato a Entra ID, gli viene richiesto di autenticarsi.
- L'utente si è autenticato con successo all'Entra ID.
- Entra ID genera una risposta SAML(Figura 9) e reindirizza l'utente all'SP.
- L'SP verifica la risposta SAML.
- L'utente riceve l'accesso all'applicazione.
In un flusso avviato dall'IdP(Figura 10), si verifica la seguente sequenza:
- L'utente naviga su myapps.microsoft.com.
- Se l'utente non si è ancora autenticato a Entra ID, gli viene richiesto di autenticarsi.
- L'utente si è autenticato con successo all'Entra ID.
- Entra ID fornisce un elenco di applicazioni disponibili per l'utente in myapps.microsoft.com.
- L'utente seleziona l'applicazione di destinazione.
- Entra ID genera una risposta SAML e reindirizza l'utente all'SP.
- L'SP verifica la risposta SAML.
- L'utente riceve l'accesso all'applicazione.
Il contenuto di un'asserzione SAML comprende diverse informazioni sull'utente finale, o soggetto, in una serie di coppie chiave-valore. Queste informazioni sono spesso indicate come asserzioni SAML e comprendono informazioni quali:
- L'oggetto. L'applicazione utilizza questo componente obbligatorio come identificatore univoco dell'utente. In molte implementazioni, l'oggetto è il nome principale dell'utente (UPN) o l'indirizzo e-mail.
- Informazioni sugli attributi. Queste informazioni possono includere il nome, il cognome, l'indirizzo e-mail e il nome visualizzato dell'utente. L'appartenenza a un gruppo o i ruoli sono spesso forniti in modo che l'applicazione possa prendere decisioni di autorizzazione sui diritti che l'utente deve avere.
- Altre informazioni contestuali sull'autenticazione. Queste informazioni possono includere il tipo di autenticazione utilizzato, l'emittente e il pubblico, nonché informazioni sul timestamp che indicano la finestra di validità della risposta SAML.
Come si fa a garantire che la risposta SAML, che viene gestita dall'utente, non sia stata manomessa? È qui che entra in gioco la firma.
Entra ID supporta sia la firma delle risposte che delle asserzioni SAML. Ad alto livello, lo scopo della firma della risposta e dell'asserzione è quello di verificare che il contenuto della risposta non sia stato manomesso e che l'applicazione possa fidarsi delle informazioni contenute nella risposta. L'applicazione utilizza la firma per convalidare che la risposta è stata generata dall'IdP, che detiene la chiave privata utilizzata per firmare la risposta.
Per questo motivo il furto della chiave privata di firma è un problema critico. Con la chiave di firma in mano, un attore malintenzionato può falsificare una copia di una risposta SAML, eseguendo un attacco Silver SAML.
Esecuzione di un attacco Silver SAML
Per verificare la teoria secondo cui la tecnica di attacco Golden SAML può essere usata contro Entra ID, in quello che abbiamo chiamato attacco Silver SAML, abbiamo creato lo strumento SilverSAMLForger. Questo strumento genera una risposta SAML che duplica una risposta di Entra ID, firmandola con un certificato fornito.
Il nostro concetto di prova di Silver SAML si basa sulla premessa che un'organizzazione utilizzi un certificato di firma generato esternamente, che un aggressore ha ottenuto utilizzando uno dei metodi precedentemente discussi. Consideriamo l'applicazione di Silver SAML sia nei flussi avviati dall'SP che in quelli avviati dall'IDP, poiché entrambi sono suscettibili di attacco.
SAML d'argento in un flusso avviato dall'SP
Attacco SAML in argento utilizzando Entra ID come IdP e Okta come SP. Per sferrare l'attacco in un flusso avviato dall'SP, abbiamo dovuto intercettare la richiesta SAML e sostituire il contenuto della risposta SAML con la risposta SAML contraffatta che abbiamo creato(Figura 11). Abbiamo potuto eseguire queste operazioni facilmente utilizzando Burp Suite.
In questo esempio, abbiamo tentato di falsificare una risposta SAML per l'utente oktaAdministrator@xd6z7.onmicrosoft.com. Questo utente è un Super Administrator in Okta. Non disponiamo della password dell'utente né del suo dispositivo connesso MFA (se configurato).
In primo luogo, abbiamo bisogno di alcuni attributi nelle informazioni sulle richieste SAML, in conformità con quanto impostato al momento della registrazione dell'applicazione sull'IdP. Ad esempio, abbiamo bisogno di UPN, cognome, nome, displayName e objectID. Un utente malintenzionato può facilmente trovare questi attributi nell'admin center di Entra o utilizzando l'API Microsoft Graph.
Dovevamo anche conoscere il destinatario e il pubblico. Queste informazioni erano disponibili nell'admin center di Entra, nel pannello Single sign-on dell'applicazione(Figura 12).
L'esecuzione di SilverSAMLForger.exe con i parametri richiesti produce una stringa codificata in base64 e URL(Figura 13). Ora possiamo copiare questa risposta SAML contraffatta.
Abbiamo copiato la risposta SAML generata nella richiesta HTTPS intercettata(Figura 14) e modificato la risposta in quella contraffatta (Figura 15).
Dopo l'invio della risposta contraffatta, possiamo interrompere l'intercettazione, poiché ora abbiamo effettuato l'accesso come utente mirato(Figura 16).
Attacco SAML Silver in un flusso avviato dall'IdP
I flussi avviati da IdP comportano un rischio molto maggiore per l'organizzazione, poiché non è richiesta alcuna interazione con Entra ID. Se l'applicazione supporta i flussi avviati dall'IdP, è possibile inviare direttamente una risposta SAML all'applicazione(Figura 17).
Per questa parte del proof of concept, abbiamo cercato di eseguire un attacco avviato dall'IdP contro Salesforce.
Abbiamo preso di mira l'utente Patti Fernandez, falsificando una risposta con il suo UPN come oggetto. La risposta(Figura 18) è stata firmata utilizzando lo stesso certificato di firma SAML configurato per Salesforce in Entra ID.
Decodificando questa risposta, si può notare che si tratta di una risposta falsificata per Patti(Figura 19).
In Burp Suite, abbiamo usato Repeater per inviare direttamente la risposta SAML falsificata alla nostra istanza di Salesforce(Figura 20).
Aprendo la risposta in un browser, abbiamo verificato che siamo entrati in Salesforce come Patti, senza alcuna interazione con Entra ID(Figura 21).
Difesa dagli attacchi SAML Silver
Per proteggersi efficacemente dagli attacchi Silver SAML in Entra ID, l'organizzazione deve utilizzare solo certificati autofirmati Entra ID per la firma SAML.
I certificati di firma SAML sono memorizzati nel service principal di un'applicazione SAML in Entra ID. È possibile utilizzare l'API Graph per visualizzare le informazioni esposte sulla chiave di firma. È sufficiente effettuare una richiesta GET al seguente URI:
https://graph.microsoft.com/beta/servicePrincipals/{serviceprincipalobjectid}
La Figura 22 mostra un esempio delle informazioni esposte. Si noti che il materiale della chiave privata non è esportabile, impedendo agli aggressori di raccogliere le informazioni necessarie per sferrare un attacco Silver SAML.
Gli amministratori globali, gli amministratori delle applicazioni, gli amministratori delle applicazioni cloud e qualsiasi utente a cui è stata delegata la proprietà dell'applicazione possono modificare le chiavi di firma disponibili e importare una chiave di firma esterna. Anche se l'applicazione associata dovrà essere aggiornata, le organizzazioni dovrebbero limitare chi ha la proprietà delle applicazioni in Entra ID. È necessario almeno monitorare le modifiche alle chiavi di firma SAML, soprattutto se la chiave non è prossima alla scadenza.
Le organizzazioni possono verificare i presidi di servizio esistenti configurati per SAML e controllare il displayName. Se il certificato utilizzato è generato da Microsoft, il certificato conterrà il valore CN=Microsoft Azure Federated SSO Certificate. Tuttavia, nulla impedisce a un utente malintenzionato di importare un certificato esterno con lo stesso nome di oggetto.
Le organizzazioni possono anche monitorare i registri di audit di Entra ID per le modifiche a PreferredTokenSigningKeyThumbprint in ApplicationManagement. È necessario correlare questi eventi agli eventi Add service principal credential che riguardano il service principal. La rotazione dei certificati scaduti è un processo comune, quindi è necessario determinare se gli eventi di audit sono legittimi. L'implementazione di processi di controllo delle modifiche per documentare la rotazione può aiutare a ridurre al minimo la confusione durante gli eventi di rotazione.
Se un'applicazione supporta sia SAML che OpenID Connect (OIDC) per l'autenticazione, si potrebbe prendere in considerazione la possibilità di modificare l'integrazione con Entra ID per utilizzare OIDC, mitigando questo attacco. La complessità del passaggio da SAML a OIDC dipende in gran parte da come lo sviluppatore dell'applicazione ha implementato gli standard.
Per quanto riguarda le applicazioni, gli sviluppatori possono proteggersi dagli attacchi in vari modi. (Le opzioni dipendono dai metodi e dalle librerie utilizzate nell'implementazione di SAML).
- Richiedere flussi avviati dall'SP, che proteggono dai flussi avviati dall'IdP, i tipi di attacchi più pericolosi.
- Per i flussi avviati dall'SP, seguire le specifiche SAML e garantire che le risposte contengano un valore InResponseTo correlato a una richiesta SAML associata.
- Osservare il tempo in cui l'applicazione riceve una risposta SAML. L'IdP indica una finestra di validità nella risposta, ma gli sviluppatori di applicazioni possono introdurre ulteriori limitazioni logiche alla finestra accettabile per la ricezione di una risposta nei flussi avviati dall'SP.
- Offrire la scelta di utilizzare OIDC, invece di SAML, per l'integrazione.
Non lasciatevi cogliere di sorpresa da Silver SAML
Come l'attacco Golden SAML, gli attacchi Silver SAML hanno il potenziale per essere lievi o devastanti. Con la continua crescita dell'adozione di ambienti di identità ibridi e cloud, ci aspettiamo di vedere più minacce rivolte a IdP come Entra ID. Questo post mostra come Silver SAML sia possibile con Entra ID, ma qualsiasi IdP che permetta di utilizzare certificati autofirmati è suscettibile. Invitiamo le organizzazioni a prendere subito provvedimenti decisivi per colmare le lacune e le vulnerabilità di questi ambienti.
Divulgazione
Questo problema è stato segnalato tramite il Microsoft Security Response Center (MSRC) il 2 gennaio 2024. Microsoft ha risposto il 26 febbraio 2024: "Dopo un'attenta indagine, questo caso è stato valutato come by-design e non soddisfa i requisiti dell'MSRC per l'assistenza immediata. Tuttavia, abbiamo condiviso la segnalazione con il team responsabile della manutenzione del prodotto o del servizio. Essi prenderanno le misure appropriate, se necessario, per aiutare i clienti a rimanere protetti".
Cronologia
- 2 gennaio 2024: Creazione del caso MSRC
- 3 gennaio 2024: Stato del caso cambiato in Revisione/Riproduzione
- 17 febbraio 2024: Revisione dell'articolo di ricerca da parte del MSRC
- 26 febbraio 2024: Risposta del MSRC ricevuta
- 29 febbraio 2024: Divulgazione al pubblico
