0
0
Resumo
- A Wiz Research descobriu um novo vetor de ataque no Active Directory do Azure que expôs aplicativos mal configurados a acesso não autorizado.
- Essas configurações incorretas são bastante populares, especialmente com os Serviços de Aplicativo do Azure e o Azure Functions. Com base em nossas varreduras, cerca de 25% dos aplicativos multilocatários se mostraram vulneráveis.
- Encontramos vários aplicativos da Microsoft vulneráveis e de alto impacto. Um desses aplicativos é um sistema de gerenciamento de conteúdo (CMS) que alimenta Bing.com e nos permitiu não apenas modificar os resultados da pesquisa, mas também lançar ataques XSS de alto impacto nos usuários do Bing. Esses ataques podem comprometer os dados pessoais dos usuários, incluindo e-mails do Outlook e documentos do SharePoint.
- Todos os problemas foram relatados à equipe do MSRC. Ele corrigiu os aplicativos vulneráveis, atualizou a orientação do cliente e corrigiu algumas funcionalidades do AAD para reduzir a exposição do cliente. O blog do MSRC pode ser encontrado aqui.
- Para verificar se seu ambiente foi afetado por essa configuração incorreta, consulte a seção “Diretrizes de correção do cliente” do blog.
Fluxo de ataque do BingBang
Introdução
Do Amazon Cognito ao Google Firebase ou ao Microsoft Azure Active Directory, há muitos provedores de identidade baseados em nuvem no mercado que atendem a várias necessidades de negócios. A complexidade de cada IdP facilita configurações incorretas, que podem ser aproveitadas por agentes de ameaças para comprometer os ambientes de produção das organizações.
Nesta postagem de blog, demonstraremos como a própria Microsoft foi vítima dos desafios de configuração do AAD e, inadvertidamente, expôs aplicativos internos a invasores externos. Esses aplicativos nos permitiram visualizar e alterar vários tipos de dados confidenciais da Microsoft. Em um caso específico, conseguimos manipular os resultados da pesquisa em Bing.com e executar ataques XSS em usuários do Bing, potencialmente expondo os dados do Office 365 dos clientes, como e-mails, bate-papos e documentos. Este blog também fornecerá detalhes sobre as configurações incorretas e como detectá-las e atenuá-las em seu ambiente.
Azure Active Directory (AAD)
A Microsoft oferece seu próprio serviço de SSO no Azure, AAD, que é o mecanismo de autenticação mais comum para aplicativos criados nos Serviços de Aplicativo do Azure ou no Azure Functions. O AAD fornece diferentes tipos de acesso à conta: contas de locatário único, multilocatário, contas pessoais ou uma combinação dos dois últimos. Os aplicativos de locatário único só permitem que usuários do mesmo locatário emitam um token OAuth para o aplicativo. Os aplicativos multilocatário, por outro lado, permitem que qualquer locatário do Azure emita um token OAuth para eles. Portanto, os desenvolvedores de aplicativos devem inspecionar os tokens em seu código e decidir qual usuário deve ter permissão para fazer login.
No caso dos Serviços de Aplicativo do Azure e do Azure Functions, vemos um exemplo de livro didático de confusão de Responsabilidade Compartilhada. Esses serviços gerenciados permitem que os usuários adicionem uma função de autenticação com o clique de um botão, um processo aparentemente suave para o proprietário do aplicativo. No entanto, o serviço garante apenas a validade do token. Não está claro para os proprietários de aplicativos que é sua responsabilidade validar a identidade do usuário por meio de declarações OAuth e provisionar o acesso de acordo.
Com a autenticação de locatário único, o impacto é limitado ao locatário do aplicativo – todos os usuários do mesmo locatário podem se conectar ao aplicativo.
Mas com aplicativos multilocatário, a exposição é tão ampla quanto possível – sem a validação adequada, qualquer usuário do Azure poderá fazer logon no aplicativo.
Configurando a locação nos Serviços de Aplicativo do Azure
Essa arquitetura complicada nem sempre é evidente para os desenvolvedores, e a responsabilidade de validar os tokens dos usuários finais não é clara. Como resultado, os erros de configuração e validação são bastante prevalentes.
Ao reconhecer esses problemas e seu impacto potencial, começamos a escanear a Internet em busca de aplicativos expostos. Os resultados nos surpreenderam: 25% de todos os aplicativos multilocatários que examinamos estavam vulneráveis ao bypass de autenticação.
O seguinte estudo de caso sobre o aplicativo “Bing Trivia”, que apelidamos de “#BingBang”, ilustra como a própria Microsoft foi vítima de armadilhas de configuração incorreta e expôs um de seus aplicativos mais críticos a qualquer indivíduo na Internet.
O estudo de caso do BingBang
Parte 1 – Reconhecimento
Para medir o quão comum era essa configuração incorreta, começamos a verificar os Serviços de Aplicativo do Azure e as Funções do Azure em busca de pontos de extremidade expostos. A verificação produziu muitos sites potencialmente vulneráveis, portanto, para restringir o escopo da pesquisa, decidimos nos concentrar no próprio locatário da Microsoft.
Vimos vários aplicativos da Microsoft, mas o primeiro domínio que chamou nossa atenção foi . Dado que o Bing é um produto muito popular nos dias de hoje, qualquer coisa relacionada a ele era de interesse para nós. Para validar a exposição, criamos um novo usuário chamado “Wiz Research” em nosso próprio locatário e tentamos fazer login no Bing Trivia com ele.bingtrivia.azurewebsites.net
A autenticação multilocatária permite que qualquer usuário do Azure emita um token OAuth
Embora não pertencêssemos ao locatário da Microsoft, fizemos login com êxito e chegamos à home page de Curiosidades do Bing.
Começamos a examinar a página à nossa frente. À primeira vista, parecia um pouco banal – apenas um CMS simples com muitas seções amontoadas nele. Para determinar se o sistema era intencionalmente aberto, precisávamos entender seu propósito.
O painel de administração do Bing Trivia, após um login bem-sucedido
Como o aplicativo foi chamado de “Bing Trivia”, assumimos que ele era destinado a conteúdo triviais. No entanto, ao navegar no aplicativo, notamos várias seções interessantes relacionadas ao conteúdo principal do Bing. Uma dessas seções era a seção “Carrosséis”, que continha uma tabela com sugestões de resultados de pesquisa aparecendo no Bing. Outra seção exibia questionários e imagens de fundo, que apareceram na página inicial do Bing.com no mesmo dia. Isso levantou a questão – este painel pode nos permitir modificar os resultados de pesquisa do Bing?
Visualizando o papel de parede diário no Bing Trivia
Visualizando o mesmo papel de parede no Bing.com
Parte 2 – Alterando os resultados da pesquisa
Para verificar nossa capacidade de controlar os resultados da pesquisa do Bing, selecionamos um carrossel no CMS e alteramos ligeiramente seu conteúdo. Queríamos fazer uma pequena mudança, que seria fácil de reverter. Escolhemos a consulta “melhores trilhas sonoras”, que retornou uma lista de trilhas sonoras de filmes altamente recomendadas; então procedemos a alterar o primeiro item, “Duna (2021)”, para o nosso favorito pessoal, “Hackers (1995)“, e salvamos nossa edição.
Modificando o resultado da pesquisa no Bing Trivia
Para nossa surpresa, nosso novo resultado apareceu imediatamente no Bing.com, completo com nosso novo título, miniatura e link arbitrário!
Resultados de pesquisa do Bing para as palavras-chave “melhores trilhas sonoras”
O filme “Duna” foi substituído pelo filme “Hackers”
Isso provou que poderíamos controlar os resultados de pesquisa do Bing e, como confirmaríamos mais tarde, esse controle também se estendeu ao conteúdo da página inicial do Bing.
Para determinar a amplitude da superfície de ataque, decidimos aproveitar esse acesso e testar a viabilidade do XSS com uma carga útil inofensiva de amostra. A carga também funcionou conforme o esperado, então rapidamente revertemos nossas alterações e imediatamente relatamos nossas descobertas à Microsoft.
Parte 3 – Atacando usuários do Bing
Enquanto trabalhávamos com a Microsoft no relatório, começamos a investigar o impacto do XSS. Vimos que o Bing tem uma seção “Trabalho” que permite pesquisar seu diretório organizacional; Ao inspecionar essa funcionalidade, percebemos que ela se baseava na API do Office 365, com o nome de host usado pelo Bing para comunicações relacionadas ao Office. business.bing.com
Isso realmente despertou nosso interesse, já que muitas organizações usam o Office 365 para armazenar seus dados comerciais mais confidenciais. Um ponto de extremidade específico criou tokens JWT para a API do Office 365, por isso geramos uma nova carga útil XSS por meio deste ponto de extremidade:
Nossa carga útil XSS, emitindo um token do Office 365 em nome do usuário
Em seguida, testamos essa carga útil em relação ao nosso antigo ponto de injeção e recuperamos um token válido de nosso usuário “vítima” (neste caso, nossa conta de pesquisa).
Vista da vítima do ataque XSS – roubando o token do Office 365 do usuário
Esse token nos permitiu, como “o invasor”, buscar os dados do Office 365 da vítima, incluindo e-mails, calendários, mensagens do Teams, documentos do SharePoint e arquivos do OneDrive do Outlook. Aqui podemos ver o computador do atacante, lendo com sucesso os e-mails da caixa de entrada da vítima:
Visão do invasor do ataque XSS – lendo os e-mails do Outlook da vítima
Um ator mal-intencionado com o mesmo acesso poderia ter sequestrado os resultados de pesquisa mais populares com a mesma carga útil e vazado dados confidenciais de milhões de usuários. De acordo com a SimilarWeb, o Bing é o 27º site mais visitado do mundo, com mais de um bilhão de visualizações de página por mês – em outras palavras, milhões de usuários poderiam ter sido expostos a resultados de pesquisa mal-intencionados e roubo de dados do Office 365.
Fluxo de ataque completo do BingBang
Aplicações vulneráveis adicionais
Além do aplicativo Bing Trivia, encontramos vários outros aplicativos internos da Microsoft com configurações incorretas semelhantes e exposição a qualquer pessoa que esteja tentando fazer login:
Notícias Mag: Um painel de controle para o MSN Newsletter, capaz de enviar e-mails arbitrários de um e-mail confiável da Microsoft para um público enorme.
API do CNS: Uma API para o Serviço Central de Notificação da Microsoft, capaz de ler e enviar notificações internas para desenvolvedores da Microsoft.
Central de Contato: Uma API para o Contact Center da Microsoft, controlando agentes de call center para representantes de clientes da Microsoft.
PoliCheck: “PoliCheck” é uma ferramenta interna da Microsoft que é usada para verificar se há palavras proibidas no código da Microsoft. Este aplicativo era essencialmente o banco de dados centralizado para as regras do PoliCheck. As regras incluem palavras em mais de 100 idiomas, que vão desde palavrões e insultos a questões geopolíticas e juridicamente controversas.
Blog do Power Automate: Um painel de administração do WordPress, controlando um blog muito ativo hospedado no . Esse painel nos permitiu criar e editar postagens com conteúdo HTML arbitrário e publicá-las em um domínio de Microsoft.com confiável.powerautomate.microsoft.com
COSMOS: Um sistema de gerenciamento de arquivos, gerenciando mais de 4 exabytes (!) de arquivos internos da Microsoft. O COSMOS categoriza arquivos por divisões e equipes da Microsoft e permite a listagem, a leitura e a edição de arquivos no aplicativo.
Todos esses problemas foram relatados à Microsoft. A equipe da Microsoft os corrigiu em tempo hábil e nos concedeu uma recompensa de bugs de US $ 40.000, que doaremos. Embora esses serviços não se enquadrassem no escopo do programa de recompensas, a equipe da Microsoft baseou sua decisão nos aprimoramentos adicionais de produto e orientação para o AAD decorrentes de nossas descobertas.
Diretrizes de correção do cliente
Sou afetado?
Os problemas que identificamos nesta pesquisa podem afetar qualquer organização com aplicativos do Active Directory do Azure que tenham sido configurados como multilocatário, mas não tenham verificações de autorização suficientes.
Com base nos dados de nossas varreduras, avaliamos que a exposição é significativamente mais comum nos aplicativos do Serviço de Aplicativo do Azure e do Azure Functions, onde a responsabilidade de validação não é clara para os desenvolvedores.
Como faço para detectar esses problemas no meu ambiente?
Os administradores podem usar o Portal do Azure para consultar suas entidades de serviço do AAD e procurar qualquer uma configurada para permitir o acesso de vários locatários. Eles devem aparecer em “Registros de aplicativos” ou na seção “Autenticação” da página de cada aplicativo.
Também é possível usar a CLI do Azure para consultar aplicativos multilocatário:
az ad app list --filter "(signinaudience eq 'AzureADMultipleOrgs' or
signinaudience eq 'AzureADandPersonalMicrosoftAccount')" --query "[?web &&
web.homePageUrl].{AppName:displayName, AppID:appId, AppURL:web.homePageUrl}" Para verificar se o aplicativo é vulnerável ou não, use seu navegador da Web para entrar em seu aplicativo com um usuário de um locatário do Azure diferente do seu. Se esse logon for bem-sucedido e seu aplicativo não for destinado a ser exposto a outros locatários do Azure, o aplicativo estará vulnerável.
Os clientes do Wiz podem usar essa consulta para identificar todos os seus ativos potencialmente vulneráveis ou essa consulta para identificar especificamente os Serviços de Aplicativo e as Funções. Também recomendamos que os usuários do Wiz consultem nosso comunicado ao cliente para obter orientação adicional.
Como posso resolver esses problemas?
Se o seu aplicativo não exigir multilocação, basta acessar a página do aplicativo e alternar para a autenticação de locatário único.
Se você precisar conceder acesso de locatário externo, terá várias maneiras de corrigir sua exposição.
Se o seu aplicativo precisar estar disponível em um locatário externo específico que não seja o seu, você poderá exigir a atribuição de usuário ou usar políticas de acesso condicional.
Caso contrário, você precisará implementar a lógica de autorização baseada em declarações executando verificações de token no código do aplicativo. Não há uma solução única para todos, e você deve consultar sua equipe de engenharia para encontrar a solução certa para seu aplicativo. No entanto, recomenda-se consultar a documentação relevante da Microsoft de antemão.
Como posso saber se esse problema foi explorado?
De acordo com a Microsoft, os logs do Active Directory do Azure são insuficientes para fornecer informações sobre atividades passadas. A solução recomendada é visualizar os logs do aplicativo e procurar por logins suspeitos.
Sugestões
Vemos essa questão como um caso de exposição à nuvem. Os provedores de serviços em nuvem permitem que os usuários exponham muitos de seus recursos de nuvem externamente com o clique de um botão. A mesma coisa aconteceu aqui, onde os usuários podiam marcar a caixa errada e expor publicamente seu aplicativo por acidente.
Além disso, os usuários do Serviço de Aplicativo do Azure e do Azure Functions podem não estar totalmente cientes de quem é responsável pela validação dos tokens de acesso. Os usuários que habilitam a autenticação por meio do Portal do Azure podem presumir que seu aplicativo está totalmente protegido. No entanto, os usuários devem implementar validação e autenticação de token adicionais no código de seu aplicativo para garantir a segurança da autenticação.
Resumo
Neste blog, abordamos exemplos do mundo real de configurações incorretas do OAuth, com foco nos próprios aplicativos da Microsoft. Com base no que descobrimos, concluímos que esse problema é facilmente explorável e severamente impactante. É por isso que pedimos a qualquer pessoa que possua aplicativos multilocatários que verifique seu ambiente com as diretrizes fornecidas acima.
Cronograma de divulgação
- 31 de janeiro de 2023 – A Wiz Research relatou o problema do Bing ao MSRC
- 31 de janeiro de 2023 – MSRC emite correção inicial para o aplicativo Bing
- 25 de fevereiro de 2023 – A Wiz Research relatou os outros aplicativos vulneráveis ao MSRC
- 27 de fevereiro de 2023 – MSRC começa a emitir correções para esses aplicativos
- 20 de março de 2023 – O MSRC afirma que todos os aplicativos relatados agora estão corrigidos
- 28 de março de 2023 – MSRC premia a Wiz Research com recompensa de bugs de US $ 40.000
- 29 de março de 2023 – Divulgação pública
FONTE: WIZ