Roubar a identidade do usuário (PII) chamando uma API diretamente

Hoje decidimos discutir o tema segurança da informação. Publicamos a tradução do artigo do pandey Kunal, detectamos vulnerabilidades e trabalhamos à frente da curva!


Introdução



O roubo de dados pessoais (PII) do usuário se tornou comum para nós. Os invasores encontram muitas maneiras de obter dados pessoais, por exemplo, usando vulnerabilidades XSS e IDOR, divulgação de endpoint de API e muito mais.



O cenário descrito neste artigo pode ser testado simplesmente observando o comportamento do terminal da API. No exemplo abaixo, ao chamar a API, as informações pessoais de qualquer usuário podem ser armazenadas em outros terminais da API.



Explicação



Num dos programas privados da plataforma HackerOne Bug Bounty , para onde fui convidado, foi proposto testar o portal da loja, nomeadamente a secção de trabalhos do vendedor. Aqui, os funcionários da loja podem enviar a qualquer cliente um convite "Fazer pedido". Para obter as informações de que precisam, o vendedor envia esta solicitação aos clientes por e-mail ou por meio de um código QR.







Após receber um link com um convite para efetuar um pagamento, o comprador acessa : payment-na.examle.com/0811ebf4-d7d0-ba31-9ce68648a5a9 e preenche os dados solicitados.







Quando uma solicitação é interceptada, o Burp Suite descobre um endpoint POST API que contém os dados inseridos.



Solicitação



POST /na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 HTTP/1.1

Host: payments-na.example.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

Accept: application/json, text/plain, */*

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Content-Type: application/json;charset=utf-8

X-Cdc-Client: 2.15.45

Content-Length: 125

Origin: https://payments-na.example.com

DNT: 1

Connection: close

Referer: https://payments-na.example.com



{"browser_prefilled":[],"customer_details":{"country":"US"..............},"skipped_fields":[],"user_submitted":true,"action":"continueAddressUnverified"}




Responda







Após o preenchimento do formulário, a operação é concluída. Feito!







Durante o método POST para pagamentos-na.example.com/na/customer/client/v1/session/002420e4-e031-47aa-8d94-6f7c40c248c7 todas as informações são salvas, o pagamento é feito.



Estágio de operação



Os usuários ou invasores podem encontrar outra seção do portal onde podem usar a função "Fazer pedido", assim como no método descrito acima, e receber o seguinte link para pagamento: payment-na.examle.com/fa5daba4-5d50-8f80 –9eb1-ebia3ea6d665 .







Nesse caso, basta preencher o formulário, interceptar a solicitação no Burp Suite, receber uma solicitação POST para payment-na.example.com/na/customer/client/v1/session/xxxx , baixar o endpoint API gerado e descartar outras solicitações nós não os enviamos.



Endpoint de API recebido: payment-na.example.com/na/customer/client/v1/session/96afd42f-4281-4529-9b8c-3ba70b0f000b .



Para mais testes, este terminal também pode ser usado usando o método GET no navegador. Abaixo está uma captura de tela do endpoint de API resultante:







Como podemos ver, nenhuma informação foi adicionada ainda e nenhum parâmetro foi especificado.



Agora vamos recuperar esse link da API e enviá-lo a outros usuários que preencheram os detalhes do pedido. Assim que a vítima clicar neste link da API, todos os dados pessoais do envio anterior que foram armazenados aqui ( / na / cliente / cliente / v1 / sessão / 002420e4-e031-47aa-8d94-6f7c40c248c7 ) serão copiados para o endpoint especificado API: / na / customer / client / v1 / session / 96afd42f-4281-4529-9b8c-3ba70b0f000b .



Depois que a vítima clicar no link API que enviamos a você, todos os dados pessoais do usuário serão copiados para este endpoint.



Do lado da vítima: É







suficiente para um invasor simplesmente visitar este endpoint da API no modo incógnito, e serão copiados os dados da vítima (e-mail, endereço, etc.).



Dados pessoais da vítima:







Dessa forma, os invasores podem obter os dados pessoais de qualquer cliente simplesmente criando um novo endpoint de API de sessão e enviando-o a outros usuários.



Trabalhando em bugs



A equipe de desenvolvimento do portal removeu o método GET, vinculou-o ao método POST e adicionou o cabeçalho do token de autorização à solicitação do método POST acima, onde sempre será autenticado no servidor.



Isso eliminou a possibilidade de repetir o cenário descrito acima - um ataque com cópia de dados pessoais do usuário via API.



Pontos chave



1. Os cenários para tais ataques podem ser diferentes, meu exemplo é apenas um deles. Preste atenção a essas vulnerabilidades e tente cavar mais fundo para criar um cenário semelhante: de que outra forma um invasor poderia atacá-lo.



2. No exemplo descrito, a API do invasor foi autenticada no endpoint da API da vítima porque não houve validação do cabeçalho do token de autorização. Isso permitiu ao servidor copiar os dados pessoais dos clientes para outro endpoint da API.



Curso de eventos:



22 de julho: Relatei a vulnerabilidade para a equipe do portal.



23 de julho: O relatório foi revisado pela equipe e a gravidade foi definida como Média.



23 de julho: Recebeu uma recompensa de $ 500.



27 de julho: Problema resolvido, relatório compilado.



All Articles