Exploração do Entra OAuth para acesso a aplicativos internos da Microsoft
(research.eye.security)- Pesquisadores confirmaram a possibilidade de acesso a aplicativos internos da Microsoft ao explorar o processo de consentimento e delegação de permissões do Entra OAuth
- Essa falha representa uma nova ameaça à proteção de sistemas internos, pois demonstra a possibilidade de um usuário externo obter uma rota de acesso aos serviços internos
- O mecanismo básico de consentimento e uma configuração insuficiente de permissões são a causa principal
- Os resultados mostraram que, com os controles de segurança existentes, há vulnerabilidade em solicitações de consentimento OAuth e no controle de acesso
- Empresas e organizações identificaram a necessidade de fortalecer a gestão de consentimento e permissões OAuth
Visão geral e contexto da pesquisa
- O Microsoft Entra OAuth é um sistema de autenticação/autorização em que múltiplos aplicativos obtêm acesso a diferentes serviços com o consentimento do usuário
- Os pesquisadores descobriram que, no ambiente-alvo, aplicativos da Microsoft que normalmente são acessíveis apenas internamente podem se tornar acessíveis externamente ao se explorar um cenário específico de consentimento e delegação de permissões
Análise de causa
- A vulnerabilidade ocorre ao explorar o processo de solicitação de consentimento OAuth
- Se um aplicativo não estiver corretamente restringido, um atacante pode obter tokens de recursos internos ao induzir o usuário a conceder consentimento
- Como o mecanismo padrão de consentimento e concessão de permissões não é suficientemente granular, alguns serviços internos passam a ficar expostos externamente
Impacto e risco
- Existe a possibilidade de um usuário malicioso utilizar essa vulnerabilidade para acessar sistemas internos da Microsoft e seus aplicativos
- Se o acesso for permitido, há risco de vazamento de dados sensíveis ou abuso indevido de funcionalidades internas
Resposta e recomendações
- As organizações devem revisar o governo do OAuth e controlar rigorosamente todos os processos de consentimento e atribuição de permissões
- Com base no princípio de menor privilégio, é necessário limitar claramente os recursos consentidos e o escopo das permissões
- É necessário reforçar a governança estabelecendo revisões periódicas de auditoria de aplicativos OAuth e processos de gestão de consentimento
1 comentários
Comentário no Hacker News
A documentação da Microsoft é realmente um pesadelo, então não é surpresa de forma alguma saber que há uma vulnerabilidade. Recentemente configurei login SSO com Entra ID e, felizmente por ser single-tenant, tive que tentar quase aleatoriamente até acertar o escopo correto e as configurações de retorno de campos extras do token de acesso. Quando procurei um guia de início, acabei indo para um monte de subpáginas cheias de termos difíceis típicos da Microsoft e links de documentação que não ajudavam de jeito nenhum.
Isso não é surpreendente. As configurações e a documentação de Oauth2 da Entra estão completamente desorganizadas. Está tão confuso que é evidente que a própria Microsoft não consegue fazê-lo funcionar corretamente. A solução que eles têm para isso é adicionar “mais documentação”, mas já é difícil ler aquela documentação em estilo espaguete que já existe.
A autorização de aplicativos multitenant continua criando problemas inesperados. Eu sou PM (que saiu) e trabalhei no patch aplicado com base na pesquisa da Wiz. Se você dá uma sugestão de correção no artigo, ele recomenda verificar apenas as claims “iss” ou “tid” ao autorizar um app multitenant. A recomendação real é um pouco mais complexa. Se você validar apenas o tenant, qualquer service principal pode acabar tendo acesso autorizado. É sempre necessário validar também o subject no token. Por exemplo, valide o token com a combinação tid+oid ou verifique tenant e subject antes da autorização. Para mais detalhes, confira na documentação oficial de validação de claims.
Ele enfatizou a abordagem de assumir que todos os tokens são falsificados. Deve-se projetar tudo de forma segura por padrão. Mesmo que isso desperdice CPU, cada campo precisa ser validado. Assinatura só faz sentido se houver validação de integridade. Se possível, recomenda-se também validar com o banco de dados de identidade. Ensinamos aos desenvolvedores que tenant, usuário, grupo e recurso devem ser verificados cuidadosamente antes de permitir acesso.
Isso é 100% correto. Na prática, os engenheiros precisam mesmo ler a documentação oficial. O guia relevante pode ser conferido aqui.
Fico curioso se existe um “guia sobre o que conferir” bem claro. Originalmente, coisas assim deveriam ser separadas simplesmente em Yes/No. Nunca ouvi falar de uma checkbox do tipo “Os usuários desse grupo devem conseguir ler notas pessoais de todo mundo?”.
Mesmo ignorando a complexidade da Entra, especialmente com muitos tenants de suporte interno da Microsoft e tenants de clientes 3P misturados sem distinção, é fácil não perceber erros. O que assusta mais é acreditar que só com um “token de autenticação” dá para resolver segurança. Esse tipo de site não deveria ter estado exposto na internet (agora não está mais público). Segurança de rede é realmente colocada em segundo plano, mas é o meio de defesa mais eficaz.
Disseram para migrar para a nuvem, disseram que era mais seguro que intranet, disseram que não precisa manter equipe operacional própria. Eu sou velho e cabeça dura demais, então não consigo entender que um app interno da Microsoft seja acessado de fora.
Há cerca de 10 anos, o Google começou a tendência de eliminar totalmente a VPN com o que chamaram de “Zero Trust”. Isso porque fica muito difícil impedir acesso a dados críticos apenas com alguém entrando na VPN. Então hoje expõem também serviços “internos”, e o controle de permissão por camada fica obrigatório. Isso torna ataques que comprometem vários serviços de uma vez muito mais difíceis. Introdução ao conceito de Zero Trust
Na minha opinião, o fato de aquele app estar exposto na rede pública (ou seja, não ser intranet) não é o problema real. O problema real é que aplicações como essa (Entra ID) são multitenant. Informações críticas de autenticação são salvas e compartilhadas no mesmo banco entre vários tenants (incluindo atacantes maliciosos). Por isso, violações de multitenancy acontecem com frequência. Mesmo com checagem de tenancy no Entra ID o mais robusta que for, a vulnerabilidade permanece. Por exemplo, como no blog, uma requisição entre 2 ou mais tenants (requisição multitenant) é, por padrão, muito difícil de autorizar e um erro pequeno pode gerar risco geral. Comparado a apps single-tenant, o atacante precisa ser usuário daquele tenant, então ataques de pré-autenticação ficam bem mais difíceis.
Mesmo com argumentos de “vá para a nuvem, é mais seguro que intranet, não precisa de equipe própria”, o ponto é que, como mostra o blog, desenvolvedores que fazem autorização de resource server não checam claims básicas no token como issuer, audience e subject. Se esses erros continuarem, ficar em intranet também não adianta. No fim, a questão central não é nuvem vs self-hosting; segurança é essencialmente difícil e o ciclo de melhorias não gira bem até enfrentar problemas reais. Colocar em intranet ou rede VPN não faz essa fragilidade sumir.
Será que “Defence in depth” (defesa em profundidade) já passou de moda?
Para a maioria das empresas, operar servidor próprio ainda é um bom conselho. Mesmo que você seja a maior empresa de reparo de telhado em 3 estados, provavelmente não quer entregar site, e-mail e sistema de reservas inteiros para ela. Quem está nesse fórum talvez consiga provisionar e operar servidor próprio, mas isso não é “usuário comum”.
Achar uma vulnerabilidade de RCE em servidor de build do Windows e dar recompensa de US$ 0 é impensável. Mesmo que não seja zero-day e seja só problema de configuração, se for possível contaminar o ambiente de build com DLL backdoor, pode causar uma catástrofe global.
Mesmo sendo a Microsoft, com muita gente excelente, considerando vazamento recente de master key, engenheiros pedindo para o GPT escrever código em PRs e ainda o CEO dizendo que engenheiro de backend vai acabar sumindo, não acho que dá para confiar naquela empresa. Claro que a maioria reconhece que não há outra escolha. Mesmo assim, ficar lá seria um pouco irresponsável.
Minha opinião é muito simples. Entra* (ou Azure AD etc, não importa se o nome muda) não deve ser usado para AuthZ. Para AuthN, é válido, mas autorização deve ser implementada diretamente. Fazendo AuthZ por conta própria, dá para driblar esse tipo de problema com facilidade. *- Não sei por que o nome mudou. Parece que há uma pessoa na gerência da Microsoft com o lema “mudo o nome, logo existo”
O nome “Azure AD” provoca a impressão de que é apenas AD hospedado no Azure. Na prática, já é mais que isso.
Implementar AuthZ com Entra é aceitável. Basta marcar e atribuir usuários diretamente na caixa “Você precisa atribuir usuários a este aplicativo”[1] No entanto, esta é a única função de AuthZ que a Entra oferece. Não é certo esperar que, se AuthZ não estiver habilitado, a Entra vá gerenciar autorização. Note que uma autorização simples de “permitir/nega” só faz sentido em app onde todos têm permissão igual. Em aplicações mais complexas, usuários têm níveis de acesso diferentes, então a autorização real deve ser implementada dentro da aplicação. [1] Como atribuir acesso do usuário ou grupo no portal de administração
Isso tudo aqui, em apps multitenant do Entra ID, o problema é não poder em lista negra/ branca de apenas tenant específico. Além disso, o MSAL também não funciona para extensões de navegador, então os usuários acabam implementando medidas de segurança adicionais para comunicar com o Entra ID. Com isso, é óbvio surgirem vários problemas.
Azure é realmente confusão. A Okta tem seus problemas, mas a documentação é bem melhor, e apesar do preço caro, permite administrar com separação total sem misturar com serviços da Azure. Considero que isso já vale o custo.