Dia 16 de Abril de 2021 o hunter Mayur Fartade realizou o report de uma falha de segurança para o Instagram, mais tarde ele também percebeu que ela se estendia ao Facebook.
Na primeira plataforma ela permitia que um invasor visualizasse detalhes de mensagens, imagens e fotos privadas, já na segunda ela concedia acesso a imagens de páginas que eram conectadas ao Instagram.
Essa vulnerabilidade é comumente conhecida como Insecure Direct Object Reference ou I.D.O.R para os íntimos, nome complicado né? Calma, pequeno gafanho, vamos esclarecer isso.
Primeiro, precisamos entender que as páginas web utilizam-se de um mecanismo chamado de access control para definir que tipo de usuário pode ou não acessar um determinado conteúdo, o I.D.O.R quebra esse mecanismo e permite que um usuário realize acesso a dados que normalmente não teria permissão.
Okk, vamos abstrair mais as coisas. Imagine que um site use da seguinte URL para modificar os dados do usuário
https://www.example.com/edit?id=USER_IDCaso um hacker, consiga modificar dados das vítimas apenas modificando o valor do parâmetro id diz-se que temos um I.D.O.R.
Blz, agora já podemos analisar como isto afeta as plataformas.
O Instragram utiliza-se de um tipo especial de API chamado Graphql ela foi desenvolvida pelo time do Facebook a alguns anos, para solicitar um post / reel / IGTV / story deveria-se fazer uma requisição do tipo POST para https://i.instagram.com/api/v1/ads/graphql/ com os seguintes parâmetros:
doc_id=[DOC_ID]&query_params={“query_params”:{“access_token”:[ACCESS_TOKEN],”id”:”[MEDIA_ID]”}}Onde o doc_id e access_token são valores privados, portanto não foram fornecidos, já id é a identificação da mídia que deseja-se visualizar, no nosso caso ele pode ser obtido por meio de um brute force.
O hunter, então, resolveu modificar os dados do body e igualou o access_token a uma string vazia, da seguinte forma:
doc_id=[DOC_ID]&query_params={“query_params”:{“access_token”:””,”id”:”[MEDIA_ID]”}}Ao enviar a requisição ele obteve todos os dados necessários para acessar a mídia
Onde display_url é a URL do conteúdo.
Como vocês devem imaginar temos um I.D.O.R pois o usuário “bypassou” o controle de acesso e adquiriu dados que não seriam normalmente fornecidos.
Nesta etapa nosso hacker com certeza já conseguiu um bom bounty, mas ele não parou por aqui, e após alguns dias de pesquisa encontrou outro endpoint que continha o mesmo tipo de falha, a URL era a mesma mas os dados contidos no body da requisição deveriam ser da seguinte forma:
access_token=[ACCESS_TOKEN]&variables={“query_params”:{“access_token”:””,”id”:”[MEDIA_ID]”},”fetch_actor_id”:false}&server_timestamps=true&doc_id=[DOC_ID]Entretanto, mesmo com algumas modificações o valor retornado foi pelo servidor era sempre null.
Então ele tentou inserir o access_token com o valor null e adivinhem? Sim. O servidor retornou os dados.
Ótimo, temos dois endpoints vulneráveis que permitem visualizar dados totalmente sensíveis dos usuários do Instagram dessa vez o hunter se deu por vencido, sqn.
Ele ainda conseguiu perceber que esse endpoint divulgava dados de páginas do Facebook, entretanto, o MEDIA_ID desta vez era público e podia ser adquirido por qualquer um.
Por essas falhas ele recebeu o merecidíssimo bounty de $30.000,00 e, não deixando ninguém surpreso a equipe do Facebook resolveu as falhas em incríveis 13 dias.
Desse report quero que vocês percebam que não devem parar de cavoucar um local só por que não tiveram resultados rapidamente, muitas vezes é mais compensador pensar um pouco mais e tentar conseguir um bom bounty do que parar no primeiro problema.