0
0
Recentemente, descobri uma falha em um núcleo brasileiro de registro de instituições encarregadas de cadastrar todos os domínios do gTLD “.br” que me permitiu contornar um mecanismo de site captcha dentro de um serviço de pesquisa de banco de dados de inscritos inicialmente por e-mail e posteriormente por CPF. (Equivalente ao documento SSN). Na prática, a partir de uma entrada de endereços de e-mail brasileiros pude enumerar um conjunto de dados público contendo informações básicas com um script python facilmente sem a preocupação deles, que poderiam ser usados do ponto de vista do atacante para envio de faturas e phishing direcionado.
Normalmente, o presente site permite que os usuários verifiquem se há pessoas cadastradas por um determinado e-mail. É necessário preencher um captcha do Google para realizar a consulta.
https://registro.br/tecnologia/ferramentas/pesquisa-de-usuario/
Não muito longe, ao analisar a solicitação/resposta através de ferramentas de desenvolvedor percebi que a consulta original se volta diretamente para uma chamada api ajax exposta com a autorização de token captcha obtida do google. Decidi testar se nestas chamadas havia alguma validação para verificar o token CSRF removendo a carga de um parâmetro recapqueiraResponse, e a API apenas aceitou minha chamada, sem qualquer validação.
A partir de um txt com registros válidos do Gmail brasileiro, pude coletar em 1 hora 16k registros de contabilidade: endereço de e-mail, login e nome completo sem uso de multithreading ou código otimizado.
A consulta de e-mails está fora do escopo do RDAP (https://tools.ietf.org/html/rfc7482),que é um padrão padronizado para critérios de whois, portanto, pude confirmar que não havia qualquer controle de limite de taxa sobre essas consultas.
O objetivo inicial desta pesquisa foi demonstrar a importância de conhecer seus recursos regionais para a OSINT. Manipulação de APIs não documentadas, noções básicas de web e python, mas voltadas para a segurança da API.
Risco real:
Com esses dados, pode ser possível que um invasor envie uma campanha maciça de phishing contendo as seguintes possibilidades: “domínios de renovação- pagamento” ou “páginas de login falsas” para roubar credenciais que sequestrem seus domínios. Esse banco de dados, se obtido em grande escala, também pode ser usado para servir consultas reversas, por exemplo, a partir de um determinado nome que você poderia coletar endereço de e-mail.
Corrigir:
- Evite expor a API ao frontend mascarando-a com javascript
- Garantindo validação adequada com o Google Captcha Response.
- Implemente o Token XSRF para garantir que houve uma sessão válida gerada antes da chamada POST.
O recurso demonstrado ainda está disponível, mas não deve ser usado para fins automatizados e de enumeração 😉
Divulgação responsável
21/08/2020 — reg.br foi contatado com recomendações sobre como corrigir tal falha.
21/08/2020 — No mesmo dia, eles reconheceram que tal função era vulnerável e pediram tempo para corrigi-la.
24/08/2020 — Rapidamente, o problema foi corrigido e resolvido.
25/08/2020 — A instituição me permitiu elaborar um relatório público sobre essa falha.
FONTE: MEDIUM