Um IDOR simples para aquisição de conta
Introdução ao IDOR, o que é IDOR?

IDOR refere-se à referência insegura de objeto direto, o que significa que você obtém acesso a algo que não deve ser acessível a você ou que não possui os privilégios corretos para executar essa ação no aplicativo da web. Tecnicamente, é um problema de controle de acesso que ocorre quando um aplicativo usa entrada fornecida pelo usuário para acessar objetos diretamente sem qualquer verificação de validação para ver se a solicitação foi feita pelo usuário pretendido ou não. O IDOR pode ser ainda relacionado ao escalonamento de privilégios horizontal [explorando o grupo de usuários do aplicativo] e vertical [explorando o usuário administrador].

Portanto, supondo que o nome do programa seja example.com , pois era um programa privado. Inicialmente, não consegui encontrar nenhum problema no domínio principal e, posteriormente, desisti depois de obter 3 duplicatas, pois era um programa privado de 3 anos e recebi o convite por volta de outubro de 2019.
Mais tarde, no ano novo de 2020, com uma nova vibração, comecei cegamente a pesquisar vulnerabilidades no mesmo programa com uma abordagem e metodologia adequadas, dei uma olhada no escopo do programa e vi que havia poucos subdomínios que chamaram minha atenção, pois não havia vulnerabilidades conhecidas, então pensei que era uma boa chance para eu derrubá-lo.
Em duas horas, obtive 4 vulnerabilidades nas quais o controle de conta era uma delas. Vamos ver como foi a abordagem para descobri-lo. Então, primeiro testei a página de login, a página de registro e a página Esqueci a senha. Ao testar a senha esquecida, vi que quando o usuário altera a senha para uma nova senha, o parâmetro Email estava presente no corpo da solicitação junto com a nova senha e o parâmetro confirmar nova senha, então pensei por que não alterar o email para outra pessoa id de e-mail e, finalmente, quando fiz o mesmo, ele me deu acesso total à conta de e-mail alterada.
Pedido Original:-
POST /login/internalResetPasswordSubmit?Toketoken=random_char&m=1234&nid=random_char HTTP/1.1
Host: subdomain.example.com
Cookie: all_required_cookies
{"email":"[email protected]","password":"new_passwd","confirmPassword":"new_passwd"}
POST /login/internalResetPasswordSubmit?Toketoken=random_char&m=1234&nid=random_char HTTP/1.1
Host: subdomain.example.com
Cookie: all_required_cookies
{"email":"[email protected]","password":"new_passwd","confirmPassword":"new_passwd"}
O impacto pode ser aumentado alterando a senha da conta de administrador, obtendo acesso total à conta de administrador.
Eu relatei isso às 12h30 IST em 28 de janeiro
Recebi uma resposta da equipe pela manhã dizendo que não era possível replicar e me pediu para assumir a conta de teste criada por eles. Então, eu queria respondê-los o mais rápido possível, mas quando recebi os comentários em meu relatório, estava na faculdade, então decidi reproduzir o problema em nosso laboratório da faculdade. Para isso, de alguma forma, consegui configurar as ferramentas e os pré-requisitos em nosso computador da faculdade e quando estava tudo pronto finalmente reproduzi o mesmo e mudei a senha da conta teste criada pela Equipe Bugcrowd e editei o perfil com meu nome de usuário para prova de conceito e enviei o relatório.
Dentro de 5 minutos, o relatório foi triado e a prioridade foi definida como P1

E no dia seguinte a empresa distribuiu o Bounty pelo meu envio, que pode ser visto na captura de tela acima.
Então é isso por enquanto e obrigado pela leitura e espero que tenham gostado deste conteúdo, nos encontraremos no próximo post do blog com um novo aprendizado e experiência!!!
Se você gostaria de saber mais sobre mim consulte este site