De um email de Newsletter a um account takeover

Em uma das edições da super útil NewsLetter https://cloudseclist.com/ fiquei sabendo de uma falha de login/signup que aplicações integradas com Microsoft Azure AD OAuth podem ter.

Fiquei passado de como é fácil explorar a vulnerabilidade e como parece que os nomes usados no Microsoft Azure AD OAuth foram feitos pras pessoas cometerem o erro de confundir o email e preferred_username (que é a razão da vulnerabilidade existir).

💡 TL;DR do post (ou por que a vulnerabilidade existe?): Ao receber um token Microsoft Azure AD OAuth, deve-se usar o campo preferred_username, ao invés de email pra identificar o usuário. No Azure AD, o campo email está totalmente sob controle do usuário e nada impede que ele escolha o valor [e-mail]. Mais detalhes em https://www.descope.com/blog/post/noauth

Preparando o ambiente de teste

Pra testar a vulnerabilidade, criei uma conta free na Azure (tendo que inserir meu cartão de crédito 😢) e instanciei meu próprio Microsoft Azure AD.

E acabei criando uma porção de usuários nos meus testes 🙆‍♀️

Achando um alvo

Com o Azure AD setado, ficou faltando achar um candidato pra testar a vulnerabilidade. Testei alguns Google Dorkings

"continue with microsoft"
"sign up with microsoft"
"register with microsoft"

Até que achei esta aplicação https://doodle.com/login que pareceu ajeitadinha.

Pra checar se vale a pena gastar tempo testando uma aplicação, a minha métrica preferida é estimar se alguém liga pra aplicação de fato. Faço isso olhando basicamente as redes sociais da companhia. Para nossos amigos do Doodle, mais de 4k followers, mais de 100 colaboradores e série A de investimento pareceu bem convicente.

Disclaimer: Não. Não achei uma aplicação vulnerável de primeira. Tive que testar uma dúzia de sites diferentes. Mas eu estava de férias, então fez parte da diversão.

Testando a vulnerabilidade

Pra testar se o site era vulnerável, criei no Azure AD um usuário chamado attacker e setei o campo email para [redacted]@doodle.com (que achei no finado https://search.illicit.services 😢).

Ao tentar logar com [e-mail]

BUM. Estava logado com a conta que atribui no campo email ([redacted]@doodle.com ). Aparentemente, a conta não tinha muito uso, infelizmente ☹️. (depois descobri que era de um dos fundadores. Isso deve ter chamado atenção no email que enviei 😆)

Sim. A exploração é tão simples quanto isso. E ainda deve existir uma porção de sites vulneráveis por aí. Então encontre e reporte pros proprietários 🙏.

Avisando nossos amigos

Usando o belo serviço https://hunter.io/search/doodle.com encontrei os emails

• [e-mail]
• [e-mail] que deveriam ser capazes de ajudar no assunto.

Escrevi um email simples contando processo que fiz e com algumas imagens dia 27/06. Email bem curto mesmo.

Dia 30/06 me responderam. Relativamente rápido, pensei. Com uma resposta bem amigável e consciente. Parabéns pessoal do suporte e comunicação da Doodle.

O Fix

Hoje (11/07) antes de escrever essa história, testei pra ver se tinham resolvido a vulnerabilidade. Como os prints abaixo mostram, a vulnerabilidade foi de fato resolvida. Acabaram não precisando de nenhuma ajuda minha 😆. Pra ser honesto, até hoje ninguém pediu ajuda pra fazer o fix.

Infelizmente não entrei em contato mais com eles pra perguntar como resolveram.

Conclusão

Por fim, ninguém respondeu mais o email que enviei. Porém, como resolveram o problema, resolvi contar a história aqui.

Apesar de ser um fim completamente anti-climático, assim que são os reports no mundo real. Especialmente fora de programas de Bug Bounty. A resposta mais comum para casos assim é apenas o silêncio e o vácuo nos emails 😆.

Espero que esse report incentive mais pessoas a fazerem responsible disclosures de vulnerabilidades (é um jeito de praticar e ajudar os amiguinhos) e dê um panorama de como funciona +/-. Foi uma investigação divertida pra mim. Vou tentar guardar melhor e separar mais evidências nos meus próximos casos.