Como uma análise simples revelou um IDOR que expôs PII de usuários

Afinal, o que é um IDOR (Insecure Direct Object Reference)?

IDOR é uma vulnerabilidade de controle de acesso na qual a aplicação utiliza referências diretas a objetos internos sem validar se o usuário possui autorização para acessá-los, permitindo acesso não autorizado a recursos de outros usuários.

idor

A fase de reconhecimento

Durante os meus testes em programas de bug bounty costumo realizar algumas etapas de crawlers (que eu assino ser uma das mais importantes) pre-exploração, utilizando ferramentas como: "waybackurls", "waymore", "otx (alienvault) e "Virustotal"" para juntar o máximo de informações possíveis, pois a partir dali, consigo identificar possíveis vetores de entrada. Porém, algo me chamou muito a atenção, um dos vetores que escalonou, de uma simples análise para misconfiguration com chain para um IDOR PII, mas se tratava de um terceiro, mas o impacto foi certeiro.

A misconfiguration

Durante a coleta com o "virustotal" algo me chamou a atenção: https://virustotal.com/vtapi/v2/domain/report?apikey=<SUA-API>&domain=app.target.com nota: você pode criar uma conta para pegar sua API, o que aumenta a entrega da ferramenta.

https://target.com/s-verification/<UUID>?...

Quando acessado, retornava a seguinte mensagem (mesmo atualizando a página, era estático): "Your profile has been verified"

Achei um tanto suspeito pois se tratava de uma verificação que foi realizada ao acessar o endpoint, mas obviamente se eu reportasse isso, com certeza receberia um "N/A" ou "Informativo", então, vem a parte mais importante, "e se eu observar o que está sendo enviado ao por debaixo dos panos?" Foi então que com o Burp acessei o endpoint e ví tudo que estava sendo passado junto e com isso descobri o seguinte, ele enviava um GET com um ID e na resposta retornava:

GET /resources/applicants/<ID>/one

Um baita vazamento de PII, inclusive número de passaporte e URL da foto e outras informações pessoais. E agora vem o principal, se tratava de um third-party a API (*.sumsub.com) que tratava a validação da conta, como argumentar? Se no escopo estava:

Third‑Party: ... or external services without direct impact on our users data.

O IDOR

Agora, vem a importância de tentar mesmo limitado a um cenário, argumentar para escalonar, foi aí que pensei, será que todos aqueles links indexados nos crawlers com o UUID, me trazem diferentes informações das contas? Fiz novamente os testes acessando cada um deles, onde tinham mais de +40 todos vulneráveis, apenas trocando o UUID (normalmente IDORS com UUID não são aceitos, a menos que você consiga uma forma de obte-los e nesse caso foi via o crawler). E me traziam informações de cada usuário ali presente, logo não aceitar esta vulnerabilidade estaria colocando em riscos todos os usuários que estavam ali indexados e seus documentos.

Conclusão

Esse writeup mostra a importância de analisar as requisições que passam por baixo dos panos, pode ser tão importante quanto acessar diretamente uma URL que leva a um possível acesso limitado, uma vez que testado de forma detalhada pode revelar outros pontos (mesmo que fora do escopo) estava vazando dados, uma má configuração da API sumsub, onde não havia quaisquer mecanismos de autenticação baseado em token ou cookies de sessão.

Essa vulnerabilidade foi recompensada num bounty de €975 euros. Com uma severidade média pois dependia da ferramenta de crawling e também do UUID, mas de qualquer maneira o impacto é muito maior do que um simples nível técnico de avaliação.