Principais conclusões
- Ao testar 104 aplicações, a Semperis encontrou 9 (ou cerca de 9%) que eram vulneráveis ao abuso do nOAuth.
- Como o abuso já foi divulgado, a capacidade de efetuar nOAuth é de baixa complexidade.
- O abuso do nOAuth explora vulnerabilidades entre inquilinos e pode levar à exfiltração, persistência e movimento lateral de dados de aplicações SaaS.
- Os abusos são difíceis de detetar e impossíveis de defender por parte dos clientes de aplicações vulneráveis.
- Os investigadores da Semperis classificam esta vulnerabilidade como potencialmente SEVERA devido à baixa complexidade do ataque e à dificuldade de deteção e defesa.
A vulnerabilidade nOAuth expõe uma falha crítica de autenticação em aplicações de software como serviço (SaaS) vulneráveis. Com acesso apenas a um inquilino Entra - uma barreira baixa - e ao endereço de correio eletrónico do utilizador alvo, um atacante pode assumir a conta desse utilizador na aplicação vulnerável. A partir daí, o atacante pode aceder a todos os dados a que o alvo tem acesso dentro dessa aplicação.
Comunicámos prontamente as nossas conclusões aos fornecedores de aplicações e ao Centro de Resposta de Segurança da Microsoft (MSRC) em dezembro de 2024; o MSRC acusou a receção do relatório e abriu o processo 93209. Em março de 2025, notificámos o MSRC da nossa intenção de divulgação. O MSRC encerrou o caso em abril de 2025. Durante maio e junho de 2025, continuámos a contactar os fornecedores de aplicações que estavam vulneráveis e partilhámos os detalhes com a MSRC. Em junho de 2025, recebemos feedback do MSRC reiterando que os fornecedores devem seguir as recomendações e que os fornecedores que não o fizerem estão sujeitos a remoção da Galeria de aplicações Entra.
A deteção de um ataque que abuse do nOAuth é difícil ou impossível. Os clientes não dispõem de opções de correção ou atenuação, para além de solicitarem aos fornecedores de aplicações actualizações que tornem as aplicações invulneráveis ao abuso do nOAuth. Devido à simplicidade deste abuso, à complexidade da deteção e à existência de aplicações ativamente vulneráveis, a Semperis considera esta vulnerabilidade um risco grave para os clientes da Entra ID.
Este artigo detalha a exploração do nOAuth pela equipa de investigação de segurança da Semperis, centrada nas aplicações da Microsoft Entra App Gallery. Descobrimos nove aplicações vulneráveis, incluindo as que podem conter informações de identificação pessoal (PII).
O que é o nOAuth?
Em 20 de junho de 2023, Omer Cohen, da Descope, publicou a divulgação "nOAuth: como a configuração incorreta do Microsoft OAuth pode levar à aquisição total da conta". O problema fundamental que leva ao nOAuth é o uso de antipadrões pelos desenvolvedores de aplicativos em relação à implementação do OpenID Connect (OIDC). Esses antipadrões incluem o uso de atributos mutáveis, como um endereço de e-mail, para identificadores de usuário. Uma vez que o Entra ID permite que os utilizadores tenham um endereço de correio eletrónico não verificado, a utilização deste atributo permite a falsificação de identidade do utilizador para além dos limites do locatário. Na divulgação da Descope, foi descrito que o ataque se situa numa "área cinzenta" no Entra ID, devido à dependência dos programadores que seguem antipadrões. Embora concordemos com esta afirmação, ela deixa os clientes mútuos da Microsoft e o fornecedor de aplicações SaaS (ISV) vulneráveis a este abuso.
Em resposta à descoberta de Cohen, o MSRC publicou um artigo sobre os riscos do nOAuth: "Risco potencial de escalonamento de privilégios em aplicações do Azure AD". Como parte da declaração de impacto no cliente da Microsoft, este artigo afirmava:
A Microsoft identificou várias aplicações multi-tenant com utilizadores que utilizam um endereço de correio eletrónico com um proprietário de domínio não verificado. Embora os endereços de correio eletrónico não verificados não representem um risco para as aplicações que não utilizam reivindicações de correio eletrónico para fins de autorização, estes proprietários de aplicações foram notificados e receberam orientações sobre como modificar as suas aplicações, se aplicável. Se não recebeu uma notificação, a sua aplicação não consumiu declarações de correio eletrónico com proprietários de domínios não verificados. Para proteger clientes e aplicações que possam ser vulneráveis ao aumento de privilégios, a Microsoft implementou mitigações para omitir reivindicações de token de proprietários de domínios não verificados para a maioria das aplicações.
Declaração de impacto nos clientes da Microsoft
A Microsoft também publicou orientações específicas sobre a migração da utilização de reivindicações por correio eletrónico. No momento em que escrevo, esse artigo de orientação já não está disponível no site da Microsoft, embora possa encontrar uma versão arquivada noutro local.
Como funciona a utilização abusiva do nOAuth?
O abuso do nOAuth requer três componentes:
- A capacidade de definir um endereço de correio eletrónico não verificado na Entra ID
- Um registo de aplicação que permite a reivindicação de correio eletrónico não verificado
- Vulnerabilidade de uma aplicação a esta combinação
Vejamos um exemplo do que pode ser este tipo de abuso.
Definir um endereço de correio eletrónico não verificado no Entra ID
Os serviços Entra ID e Microsoft 365 incluem um locatário padrão com um nome de domínio onmicrosoft.com, como contoso.onmicrosoft.com. À medida que as organizações configuram suas implantações e integram seus próprios nomes de domínio para serviços, o processo de verificação usa um registro TXT ou MX para verificar a propriedade do domínio. Uma vez verificado, o nome de domínio é marcado como tal no Entra ID(Figura 1).
No entanto, para suportar a funcionalidade de utilizador convidado no Entra ID, o sufixo de domínio do atributo de correio eletrónico não precisa de ser um domínio verificado. Portanto, qualquer usuário em qualquer locatário Entra pode ter qualquer endereço de e-mail no atributo mail.
Por exemplo, a Figura 2 mostra um utilizador, Adele Vance, cujo atributo mail tem o mesmo valor que o atributo userPrincipalName.
Podemos executar um PATCH simples para alterar este atributo de correio eletrónico(Figura 3).
Outro GET mostra que Adele tem agora um endereço de correio eletrónico para um domínio que não é verificado neste inquilino(Figura 4).
Verificar uma alteração de endereço de correio eletrónico
Se quisermos validar o endereço de email não verificado como uma reivindicação em um token de ID, podemos configurar um registro de aplicativo no Entra ID com um URI de redirecionamento de https://jwt.ms e passar o token de ID para ele.
Para registros de aplicativos criados após junho de 2023, por padrão, a reivindicação de email não verificado não é emitida pelo Entra ID. Para modificar a configuração para permitir isso, podemos usar um PATCH simples no authenticationBehavior para o registro do aplicativo, definindo removeUnverifiedEmailClaim como false (Figura 5). Esse processo é documentado pela Microsoft no artigo "Manage application authenticationBehaviors".
Uma vez configurado o registo da nossa aplicação, podemos utilizá-lo para replicar o comportamento de uma aplicação vulnerável e visualizar o token de ID(Figura 6).
Se este token de ID for consumido por uma aplicação que utilize a reivindicação de correio eletrónico como identificador único, a aplicação não saberá que o utilizador não é, de facto, o utilizador legítimo.
Atenuar o abuso do nOAuth
Tal como referido, a atenuação do abuso do nOAuth exige, em última análise, que o programador implemente corretamente a autenticação para garantir um identificador único e imutável.
Pam Dingle, Diretora de Normas de Identidade da Microsoft, publicou um artigo pouco depois da divulgação do nOAuth sobre os antipadrões dos programadores. Vale a pena ler: "O antipadrão do falso identificador".
Como Pam destaca no artigo, de acordo com a especificação do OpenID Connect, na Secção 5.7, uma combinação das reivindicações do emissor(iss) e do sujeito(sub) é a única forma de uma aplicação(SP) poder garantir um identificador de utilizador único e estável.
No Entra ID, o emissor(iss) é emitido como um URI de emissor que inclui o ID do locatário, que é globalmente único(Figura 7).
O sujeito(sub) é um identificador par a par que é único para cada utilizador para cada ID de aplicação(Figura 8). Igualmente importante, sub é um valor imutável na Entra ID. A Entra ID não permite qualquer tipo de transformação ou modificação da reivindicação em causa, garantindo a sua exclusividade.
Para mais pormenores sobre as reivindicações contidas numa ficha de identificação emitida pela Entra ID, ver aqui: "Referência das reivindicações de fichas de identidade".
Alterações da Microsoft para mitigar o abuso do nOAuth
No Entra ID, a Microsoft fez alterações para que qualquer registo de aplicação criado após junho de 2023 não emita, por defeito, uma reivindicação de correio eletrónico se o endereço de correio eletrónico não for verificado. Obviamente, milhares e milhares de aplicativos SaaS existem desde antes de junho de 2023, e muitos desenvolvedores ainda querem e precisam consumir o endereço de email; muitos aplicativos SaaS desejam enviar email para usuários finais, e o consumo por meio de uma reivindicação é a maneira mais fácil de obter essas informações.
Para ajudar os programadores, a Microsoft também introduziu a declaração opcional xms_edov, que um programador pode utilizar para determinar se um endereço de correio eletrónico é verificado. No entanto, ao escrever este artigo, a declaração xms_edov parece estar num estado de incerteza, o que nos faz pensar se está a ser descontinuada. Embora os documentos da Microsoft indiquem que a declaração é opcional, ela não está mais disponível na interface do usuário para definir declarações opcionais. A definição de xms_edov como uma declaração opcional por meio da API do Graph funciona, mas você recebe uma mensagem posterior informando que ela não é uma declaração opcional válida(Figura 9).
Em ação, um dev poderia utilizar esta informação para decidir se o endereço de correio eletrónico de um utilizador é verificado no inquilino(Figura 10).
A nova investigação de abuso de nOAuth da Semperis
O enfoque Descope
Na investigação publicada pela Descope, o foco está nas aplicações SaaS que têm suporte para vários fornecedores de identidade, como o Google e a Microsoft, o Facebook, etc.(Figura 11).
Para efeitos de usabilidade, as aplicações SaaS têm normalmente uma lógica de fusão de contas. Por exemplo, se eu me inscrever no Medium com uma conta do Facebook e, mais tarde, iniciar sessão com a minha conta Google, as duas fontes de autenticação acabam por me levar à mesma conta Medium.
O problema que a Descope explorou foi que, como qualquer conta de utilizador no Entra ID podia conter a reivindicação de correio eletrónico, os programadores que faziam a fusão com base no correio eletrónico podiam, sem saber, permitir que um atacante entrasse na conta de um utilizador-alvo.
Para além de algumas das capacidades que a Microsoft implementou, a Descope recomendou que as aplicações SaaS que suportam a funcionalidade de fusão de contas interrompam o fluxo na primeira vez que se tenta iniciar sessão com uma fonte de conta diferente, utilizando uma função para validar a propriedade do correio eletrónico. Concordamos com este conselho. Esta função pode assumir a forma de uma ligação mágica de correio eletrónico, em que o utilizador recebe um correio eletrónico a pedir-lhe que verifique a propriedade antes de a fusão ter lugar.
Na nossa própria investigação, verificámos que esta era uma prática de segurança comum entre as aplicações que se revelaram invulneráveis ao abuso do nOAuth.
Investigação Semperis
No final do outono de 2024, como parte de alguma pesquisa exploratória, estávamos a rever a pesquisa realizada pela Descope e decidimos testá-la contra algumas aplicações SaaS. Isso coincidiu com uma ideia de explorar a Galeria de aplicativos Microsoft Entra. A Entra App Gallery é um portal dentro do Entra ID que a Microsoft gerencia e permite que fornecedores de SaaS de terceiros apresentem essencialmente aplicativos que se integram ao Entra ID(Figura 12).
Na nossa investigação, examinámos todas as 1017 integrações OIDC disponíveis na altura e encontrámos 104 aplicações que permitiam o registo automático na aplicação. Como o mercado SaaS é muito competitivo, os fornecedores tendem a permitir níveis gratuitos ou testes das suas aplicações com pouco atrito, permitindo-lhe utilizar e testar a aplicação sem ter de passar por quaisquer canais de vendas. Concentrámo-nos nestas aplicações não só porque proporcionavam uma barreira baixa para a investigação de segurança, mas também para nos mantermos dentro dos limites dos testes éticos.
Em cada aplicação que testámos, utilizámos um inquilino "vítima" que gerimos para configurar uma conta que possuíamos na plataforma. Em seguida, utilizámos um inquilino diferente, o inquilino "atacante", para tentar abusar do nOAuth contra a nossa própria vítima. Desta forma, garantimos que os nossos testes apenas afectavam contas sob o nosso controlo e apenas acediam a amostras de dados de teste criadas por nós.
Nossa pesquisa é diferente da da Descope, pois estávamos interessados em encontrar aplicativos que permitissem o abuso de nOAuth entre locatários do Entra ID. Essencialmente, o cliente alvo (vítima) é um cliente Microsoft com um locatário Entra ID e o atacante utiliza um locatário Entra ID diferente para efetuar o abuso. O diagrama a seguir da Descope é válido no que se refere ao fluxo de ataque em nossa pesquisa(Figura 13).
No entanto, com nosso foco, o aplicativo SaaS só precisa suportar o Entra ID para autenticação. Embora quase todos os aplicativos SaaS que testamos suportassem uma conta de usuário local, descobrimos que alguns aplicativos também suportavam vários provedores de identidade, como o Google e o Entra ID, enquanto outros suportavam apenas o Entra ID.
Além disso, teorizámos que, se uma aplicação suportasse apenas o Entra ID para autenticação, era improvável que o programador implementasse a lógica de fusão de contas e a verificação de correio eletrónico que a Descope observou, uma vez que o programador provavelmente não esperava um cenário de colisão de contas.
Aplicações vulneráveis
Nos testes de 104 aplicativos, encontramos 9 que eram vulneráveis ao abuso de nOAuth; isso se traduz em vulnerabilidade em cerca de 9% dos aplicativos testados. Como 104 é apenas uma gota no balde de aplicativos SaaS que estão integrados ao Entra ID, é possível extrapolar esses números em relação às dezenas de milhares de aplicativos SaaS disponíveis.
Das aplicações que encontrámos vulneráveis, fizemos algumas observações interessantes relativamente à dimensão, escala e tipo de aplicação. Encontrámos uma plataforma de sistema de gestão de recursos humanos (HRMS) que, na prática, seria provavelmente preenchida com PII. Da mesma forma, encontrámos aplicações que se integravam no Microsoft 365 para tarefas como o acesso ao correio e ao calendário. Como essas integrações usavam um conjunto diferente de combinações de tokens de acesso e atualização, um invasor que abusasse com sucesso do nOAuth seria capaz não apenas de obter acesso aos dados do aplicativo SaaS, mas também de potencialmente acessar os recursos do Microsoft 365.
Infelizmente, testar em escala consome muito tempo. Além de configurar o locatário Entra para realizar o abuso, precisávamos de um conjunto de olhos humanos na interface do aplicativo SaaS para determinar se o invasor conseguiu obter acesso à conta da vítima. Embora a maioria das aplicações que eram invulneráveis a este abuso apresentassem geralmente um novo fluxo de integração na aplicação, algumas simplesmente deixavam-nos cair no ecrã principal da aplicação, exigindo que examinássemos as informações da conta ou tentássemos manipular os dados dentro da aplicação para determinar se o atacante estava na mesma conta que a vítima.
Contactar as partes interessadas
Como resultado desta investigação, abrimos um caso com o MSRC. Também tentámos determinar as partes interessadas em cada ISV que tinha uma aplicação vulnerável. Depois de contactar esses intervenientes, seguindo o princípio da Semperis de ser uma Força do Bem, oferecemos ajuda para resolver a vulnerabilidade da sua aplicação; alguns fornecedores aceitaram a nossa oferta. Nestes casos, ajudámos os fornecedores a compreender o problema e realizámos testes adicionais de abuso do nOAuth nas suas aplicações até a questão estar resolvida.
Defesa do cliente: falta de opções
Em última análise, a única defesa que um cliente tem contra o abuso do nOAuth é 1) instar o fornecedor a resolver o problema ou 2) abandonar a aplicação SaaS.
Uma vez que o ataque ocorre fora do alcance da vítima, os mecanismos de defesa tradicionais não podem proporcionar proteção. Estes incluem:
- Autenticação multifator (MFA) e imposições de força de autenticação no Entra ID
- Acesso condicional
- Soluções Zero Trust Network Access (ZTNA) e Cybersecurity for Any Business (CASB)
- Deteção e resposta de pontos finais (EDR)
- Deteção e resposta alargadas (XDR)
Deteção de abusos nOAuth
Embora as soluções de Gestão da Postura de Segurança SaaS (SSPM) possam fornecer algumas informações sobre as aplicações SaaS, geralmente concentram-se na configuração e na postura de segurança que é exposta aos clientes da plataforma e não são susceptíveis de indicar o abuso do nOAuth. Existem problemas semelhantes com as plataformas de browsers seguros das empresas e os plug-ins de browsers, que podem ajudar a destacar outros backdoors nas aplicações SaaS, mas é pouco provável que revelem este tipo de ataque.
Infelizmente, isto deixa poucas opções para os clientes:
- Correlação de logs de autenticação SaaS com Entra ID em uma plataforma SIEM
- Perguntar aos seus fornecedores sobre o nOAuth
- Realização de testes de abuso do nOAuth
Do ponto de vista da Entra ID, examinamos os princípios de serviço de aplicativos multilocatários e não encontramos nenhum atributo exposto a um cliente que indicasse que o aplicativo consome declarações de e-mail não verificadas. Mesmo que tais atributos existissem, não haveria como indicar para que o aplicativo usa essa reivindicação.
Correlação de registos de autenticação
Para usar a correlação de logs para detetar abuso de nOAuth, seria necessário consumir os logs de autenticação do Entra ID em uma solução de gerenciamento de eventos e informações de segurança (SIEM), como o Microsoft Sentinel. Também seria necessário consumir logs de autenticação do aplicativo SaaS e, em seguida, correlacionar os dois logs no SIEM. Seria necessário procurar eventos de autenticação na plataforma SaaS com um evento de autenticação ausente no Entra ID(Figura 14).
Naturalmente, os resultados de colocar essa teoria em prática variam muito. Embora o assunto(sub) seja o identificador principal no aplicativo SaaS, esse valor não é capturado nos logs de login do Entra ID durante a autenticação. Portanto, o aplicativo SaaS também precisaria conter atributos como UPN ou endereço de email em seus logs para correlação. Da mesma forma, os logs de autenticação do fornecedor de SaaS precisam estar disponíveis de uma forma que possa ser consumida por um SIEM. Outros factores, como o desvio de tempo e a precisão, podem agravar a dificuldade de detetar abusos de nOAuth através da correlação de registos.
Testes para nOAuth e responsabilidade do fornecedor
A única outra opção de um cliente seria testar as aplicações SaaS que consome quanto ao abuso do nOAuth. Antes de o fazer, pode contactar o fornecedor da aplicação para saber se o fornecedor conhece o nOAuth e se efectuou testes contra o abuso do nOAuth.
Alguns pontos a registar:
- Certificações como a SOC II não investigaram este abuso. Encontrámos aplicações vulneráveis cujos fornecedores tinham o SOC II e outras certificações listadas nos seus sites.
- Pergunte especificamente ao fornecedor se foi efectuado algum teste contra esta vulnerabilidade. Encontrámos fornecedores que acreditavam ter resolvido o problema, mas mesmo assim conseguimos efetuar abusos de nOAuth nas suas aplicações.
Se o fornecedor não puder responder definitivamente a esta pergunta, o cliente pode efetuar este teste em qualquer aplicação que o preocupe. Tal como os investigadores de segurança, os clientes devem certificar-se de que estão a efetuar os testes dentro de limites éticos: testar com as suas próprias contas de utilizador e compreender quaisquer requisitos contratuais que possam ter com o fornecedor.
Defesa do programador de software contra o nOAuth
Os programadores que utilizam a declaração de correio eletrónico devem verificar se não a estão a utilizar para a identificação do utilizador. Se estiverem, devem seguir os passos documentados pela Microsoft para seguir as especificações OIC, utilizando o emissor e o assunto.
Os programadores também podem examinar os seus registos de aplicações para determinar se estão a receber a reivindicação de correio eletrónico não verificado. No entanto, cabe ao programador examinar o seu código para determinar como é utilizada a reivindicação de correio eletrónico.
Existem também soluções alternativas para receber os dados do atributo de correio eletrónico sem ser através de uma reivindicação no token de ID. A OIDC especifica um ponto final UserInfo, que é implementado na Entra ID. Este ponto final pode ser utilizado para receber informações sobre o utilizador autenticado. Ao chamar o ponto final UserInfo, a aplicação pode obter o endereço de correio eletrónico do utilizador após a autenticação, mesmo que esse endereço não seja verificado. Este passo assegura que o pedido de correio eletrónico não é utilizado como identificador único do utilizador.
Neste exemplo, podemos chamar o ponto de extremidade UserInfo em Adele Vance, que tem um endereço de correio eletrónico não verificado(Figura 15). O assunto, que é o identificador exclusivo, corresponderá ao do token de ID.
Os programadores que actualizaram o seu código para resolver a vulnerabilidade do nOAuth devem testar a sua aplicação após a correção para garantir que não é vulnerável ao abuso do nOAuth. No nosso trabalho de correção com os fornecedores, a correção inicial nem sempre resolveu a vulnerabilidade.
Ao comunicar com o MSRC sobre as nossas conclusões, este reiterou que os programadores têm de seguir as recomendações e remeteu-nos para o artigo que publicou sobre a divulgação em 2023. Como há necessidades legítimas de as aplicações obterem o endereço de correio eletrónico de um utilizador, não há forma de determinar se uma aplicação está a utilizar corretamente o atributo sem testar cada aplicação. Como observámos nos nossos próprios testes, este é um processo muito moroso.
O MSRC afirmou igualmente que comunicou com os fornecedores de aplicações e que aqueles que não corrigiram as suas aplicações estão sujeitos a serem retirados da Entra App Gallery.
Divulgação e calendário
Surpreendidos com o facto de o nOAuth funcionar de forma abusiva, especialmente em aplicações publicadas na Galeria Entra, abrimos um caso com o MSRC (atribuído o número de caso 93209).
Também instámos o Grupo de Produtos de Identidade da Microsoft a ser mais agressivo na proteção dos clientes, tendo em conta a dificuldade de deteção de abusos do nOAuth. Sugerimos que se avisem os clientes de entidades gestoras de serviços de que a aplicação permite declarações de correio eletrónico não verificadas, apesar de, como referimos, não ser um identificador absoluto de vulnerabilidade ao nOAuth.
Indicámos também as nove aplicações vulneráveis que encontrámos, para o caso de o MSRC estar em contacto com esses fornecedores.
- 3 de dezembro de 2024: Caso criado com a MSRC
- 3 de dezembro de 2024: Caso reconhecido pela MSRC
- 4 de dezembro de 2024: Fornecemos detalhes adicionais do caso ao MSRC
- 17 de dezembro de 2024: Actualizámos o caso com o MSRC, referindo que trabalhámos com um fornecedor para resolver uma das aplicações vulneráveis
- 17 de março de 2025: Perguntámos ao MSRC sobre o estado do processo; não recebemos resposta
- 18 de março de 2025: Notificámos o MSRC no portal sobre a intenção de divulgar em sessão no Troopers 2025 (se selecionado)
- 19 de março de 2025: Notificámos o MSRC por correio eletrónico sobre a intenção de divulgar em sessão no Troopers (se selecionado) e pedimos orientações sobre a divulgação, uma vez que a vulnerabilidade original já tinha sido divulgada; não recebemos resposta
- 18 de abril de 2025: O caso foi encerrado pelo MSRC, afirmando que "foi comunicada uma correção para o problema que apresentou" sem mais informações
- abril - maio de 2025: Testámos e encontrámos fornecedores de aplicações que eram vulneráveis ao nOAuth; notificámos novamente os fornecedores e contactámos o MSRC com as nossas conclusões
- junho de 2025: O MSRC forneceu pormenores sobre as aplicações vulneráveis ao nOAuth na Galeria de Aplicações Entra
- 26 de junho de 2025: Divulgação pública
