Comportamento da página de login do AWS Console permite que um atacante não autenticado descubra se um usuário usa segundo fator de autenticação
Durante um assessment de segurança, nosso time estava fazendo reconnaissance em um ambiente AWS de um cliente. O objetivo era explorar formas de atacar o ambiente gerando o mínimo de ruído possível que permitisse aos defensores perceber que havia algo errado. Uma destas atividades foi a enumeração de usuários que poderiam ser alvo de ataques de phishing ou outras formas de roubo de credenciais.
Depois de termos construído uma lista de e-mails de contas de root e IDs de usuários IAM com acesso à console, precisávamos encontrar uma forma de descobrir quais seriam os alvos mais fáceis. Sendo profissionais de segurança, nossa esperança é que os usuários tenham autenticação de múltiplos fatores (MFA na sigla em inglês) habilitada, mas na realidade isso é usado com muito menos frequência do que deveria. Então, se fôssemos capazes de excluir de nossa lista usuários com MFA habilitado, poderíamos focar nossa engenharia social ou phishing apenas naqueles em que teríamos maiores chances de sucesso.
Felizmente para nós, a página de login da console da AWS nos permite identificar de forma fácil se um usuário tem MFA habilitado ou não. O workflow de falha de autenticação é diferente nos dois seguintes grupos:
- usuários com MFA habilitado;
- usuários que não existem, que existem mas não tem acesso à console, ou que existem mas não têm MFA habilitado.
Em nossa experiência todas as contas root e a esmagadora maioria de usuários de IAM têm acesso permitido à console web. Então começando de uma lista de usuários que sabidamente existem e removendo aqueles que sabemos ter MFA habilitado, chegaremos a uma boa lista de alvos para roubo de credenciais.
Esse é o comportamento do login da console para um usuário de IAM no grupo 2 quando uma senha incorreta é fornecida:
Mas se o usuário tiver MFA habilitado, independentemente da senha fornecida estar correta, isso é mostrado depois que o botão de Sign In é clicado:
O mesmo ocorre para usuários root, exceto pelo fato de que basta saber seu endereço de e-mail, ao invés de ID de conta AWS e username de um usuário IAM:
Esta diferença permite que um atacante não autenticado determine se um usuário da console tem MFA habilitado. Baseado neste conhecimento, podemos facilmente utilizar o Burp Intruder para tornar o processo de teste em escala bastante mais simples:
É possível que a AWS utilize rate-limiting ou outras técnicas para mitigar esta automação, mas não identificamos nenhum nos testes em pequena escala que realizamos. Um controle que notamos é que, após o término de todo o processo de login falho, um CAPTCHA é apresentado. Mas isso nunca ocorreu entre o fornecimento da senha e o pedido pela console do valor do MFA, ou mesmo após um recarregamento completo da página de login. Então isso não nos impediu de usar a automatização com o Burp.
Antes de publicar este artigo nós reportamos este problema para o time de segurança da AWS, e eles responderam da seguinte forma:
“Thank you for bringing your security concerns to our attention.
AWS is aware of the user enumeration concern you raised and the behavior you described is the expected behavior for the Signin form. AWS chose this behavior in a decision between usability and the value of a username that you protect with MFA. Challenging users for MFA when MFA is disabled creates confusion and a high incidence of legitimate sign-in failures.
If you discover or become aware of other security concerns specific to AWS products and services, please do not hesitate to contact us again at aws-security@amazon.com.”
Escrito por Rodrigo Montoro, Felipe Espósito e Alexandre Sieira.
