IDOR para aquisição de conta

May 06 2023

Resumo Olá pessoal! Após a conclusão da minha certificação OSCP e desejando mergulhar novamente nas recompensas de bugs, decidi que talvez devesse escrever alguns blogs com base em minhas descobertas anteriores, na esperança de que alguém possa achá-lo útil ou aprender com ele. Este artigo envolve encontrar duas vulnerabilidades IDOR e aproveitá-las para vazar PII, resultando em uma aquisição de conta.

Resumo

Olá pessoas! Após a conclusão da minha certificação OSCP e desejando mergulhar novamente nas recompensas de bugs, decidi que talvez devesse escrever alguns blogs com base em minhas descobertas anteriores, na esperança de que alguém possa achá-lo útil ou aprender com ele.

Este artigo envolve encontrar duas vulnerabilidades IDOR e aproveitá-las para vazar PII , resultando em uma aquisição de conta . A aquisição da conta foi possível devido à maneira como a empresa lidou com o processo de recuperação da conta e foi, de fato, uma das minhas primeiras descobertas quando comecei inicialmente as recompensas de bugs. A emoção de encontrar isso me levou a aprender continuamente horas extras.

O que é esse IDOR de que falo?

Insecure Direct Object Referencemais frequentemente abreviado como “IDOR” é um tipo de vulnerabilidade que pode ser categorizado em access control. IDORsocorrem dentro do aplicativo quando o aplicativo usa a entrada fornecida pelo usuário para acessar o objeto diretamente sem realizar nenhuma verificação para ver se o usuário tem as permissões de autorização corretas. Frequentemente associado ao escalonamento horizontal de privilégios, IDORspode causar efeitos deletérios no aplicativo e em sua base de usuários.

Um excelente exemplo de parâmetros típicos geralmente vulneráveis a IDORs incluem: id= | userID= | messageId=. Entender o fluxo do aplicativo pode facilitar a identificação desses tipos de problemas.

A imagem acima ilustra dois cenários. Scenario Aà esquerda transmite um aplicativo mais seguro onde users 2 and 3tenta acessar registros confidenciais que não pertencem a eles, no entanto, isso resulta em um access denied errorcomo deveria.

Scenario Bà direita, no entanto, mostra um aplicativo vulnerável no qual o agente da ameaça pode emitir solicitações ao servidor da Web e recuperar registros confidenciais de qualquer usuário sem ter o acesso negado.

Se você quiser ler mais sobre IDORs Vickie Li, tem uma postagem de blog fantástica que esclarece os fundamentos desse tipo de vulnerabilidade. Você pode conferir aqui .

O exemplo acima é simples, porém, dependendo da aplicação, você pode aproveitar as informações antes de relatá-las para aumentar o impacto, que é o que sempre pretendo fazer.

Agora que temos uma ideia do que IDORssão, onde podem ser encontrados, bem como o impacto, vamos mergulhar em uma das minhas primeiras descobertas! :)

Reconhecimento

Embora o problema tenha sido corrigido, não consegui obter permissão para divulgação pública completa, portanto, o alvo será referido como: example.com. Como acontece com qualquer alvo, dependendo do scope, a enumeração do subdomínio é a chave para expandir a superfície de ataque. No entanto, a enumeração de subdomínio não é a única maneira de expandir a superfície de ataque, pois também podemos analisar JavaScriptarquivos em busca de informações confidenciais. Nesse caso, decidi começar com o uso de um rápido Google Dorkpara ver se encontrava algum subdomínio interessante antes de usar ferramentas automatizadas para obter mais resultados.

Google Idiota:site:*.example.com

Example.comtinha cerca de 36 subdomínios, portanto, um número razoavelmente bom de subdomínios para trabalhar!
Olhando através deles um por um, anotei dois subdomínios que tinham muitas funcionalidades. Levei cerca de um ou dois dias para navegar por esses subdomínios e testar diferentes recursos enquanto anotava mentalmente alguns dos recursos mais interessantes específicos desse aplicativo. Por exemplo, o aplicativo tinha um recurso onde você poderia criar tickets para receber suporte da equipe em diferentes categorias, como “Problemas de pagamento”.

Bug Inicial

Decidi começar analisando como funcionava o processo de inscrição e login - um recurso central que é implementado em quase todos os sites hoje em dia. O fluxo de inscrição do aplicativo da web pode ser resumido como:

O usuário se cadastra por e-mail
O usuário é solicitado a definir um PIN No.e um security questionantes que o processo de criação da conta possa ser concluído. Isso só pode ser definido uma vez e não pode ser alterado
O usuário é solicitado a confirmar o e-mail antes de entrar

Usando o account A, comecei Burpsuitea testar o recurso de emissão de tíquetes e criei duas contas de teste, seguidas da criação de alguns tíquetes em diferentes categorias de suporte para fins de teste. Olhando para o HTTP Historyin Burpsuite, havia algumas chamadas interessantes sendo feitas.

O seguinte POST requestfoi iniciado ao responder a um membro da equipe em um ticket relacionado a reclamações de prêmios:

POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com

grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...

Então, para concluir as descobertas até agora:

Ao se inscrever, cada usuário deve criar um PIN No.esecurity question
O site permite que os usuários façam tickets de suporte para assistência
Para receber suporte, o usuário precisa responder com seus PIN No.e security question answerpara assuntos delicados, como recuperação de conta, reclamações de prêmios e problemas de pagamento
IDORa vulnerabilidade descoberta no sistema de tíquetes permite que um adversário comente em qualquer tíquete de suporte sem ser o proprietário do tíquete ou um membro da equipe

Então, se eu pudesse postar um comentário em qualquer ticket sem ser o proprietário ou ter privilégios de membro da equipe... certamente isso significava que eu poderia ler qualquer ticket também, certo?

Eu capturei a seguinte requisição GET na tentativa de visualizar um ticket pertencente a account Avia account B, porém, isso levou ao 403erro ilegal! Então, eu poderia escrever para qualquer tíquete de suporte, mas não poderia ler o conteúdo de um. Neste ponto, eu realmente queria encontrar qualquer maneira possível de levar isso adiante.

GET Endpoint para ler um ticket no aplicativo da Web

GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close

Ao tentar explorar o recurso de emissão de bilhetes, me deparei com a seguinte solicitação;

GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:

Vazamento de conteúdo do tíquete via API no aplicativo IOS

Durante o reconhecimento inicial, notei algumas APIsolicitações sendo enviadas ao recuperar informações de perfil, além disso, o alvo também tinha um mobile appescopo. Era altamente provável que, embora a leitura de tickets de outros usuários no próprio aplicativo da Web não fosse possível, isso poderia ser obtido por meio do aplicativo móvel, pois poderia ser usado um diferente API version/endpointdo aplicativo da Web.

Iniciando Burpsuitee navegando para a sessão do ticket dentro do aplicativo IOS, cheguei ao seguinte endpoint:

GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com

Então agora eu encontrei dois bugs - era possível escrever em qualquer ticket E visualizar o conteúdo de qualquer ticket pertencente a outro usuário.

Escalando Ticket Ler IDOR > Controle de conta

Nesse ponto, eu praticamente tinha todos os elementos necessários para conseguir uma aquisição de conta. Como era possível ler qualquer ticket, a aquisição da conta do usuário poderia ser realizada através das seguintes etapas:

Visite o /api/v1/support-tickets/234567/postsendpoint e envie-o intruderpara Burpsuiteenumerar o maior número possível de tickets
Greppara palavras-chave como Pin Numberou Security Questiondas respostas
Faça uma nova conta no site e abra um ticket emaccount recovery
O membro da equipe alocado solicitará o nome de usuário da conta que você deseja recuperar junto com o security question answere PIN No., todos os quais podem ser vazados por meio do segundo IDOR encontrado; assim, resultando em uma aquisição de conta.

Embora a aquisição da conta já tenha sido alcançada, o IDOR de gravação do tíquete também pode ser aproveitado. Os nomes de usuário da equipe foram prefixados com o nome da empresa, por exemplo example-John. Um adversário poderia;