Food Hacking
Igor Rincon – A.k.a M4dwolf
Continuando a saga através dos aplicativos mobile brasileiros, neste artigo irei explicar como ocorreu a exploração de uma vulnerabilidade de segurança em um aplicativo muito conhecido no Brasil por criar uma estrutura de comunicação para restaurantes e clientes.
Nome do aplicativo: iFood – Delivery de Comida
Fabricante: https://www.ifood.com.br/
Versão: 5.2.8
Descrição da empresa: Desenvolvimento de plataforma para delivery de restaurantes
Resumo da vulnerabilidade: A vulnerabilidade permite que o usuário manipule os preços dos alimentos no aplicativo.
Como descobri a vulnerabilidade ?
Durante minha análise notei que a maioria da comunicação do aplicativo iFood é baseado em formato JSON como vocês irão notar durante a explicação.
Após entrar no aplicativo e fazer um cadastro com minha conta eu defini uma localização falsa em uma cidade para verificar os restaurantes que haviam nela. A primeira tela que me apareceu foi:
(Tela inicial do aplicativo)
Para gerar essa localização, a aplicação faz uma consulta no servidor do iFood especificando um filtro de localização:
(Requisição da lista dos restaurantes)
Logo em seguida selecionei o restaurante “China In Box” pelo simples fato (no meu caso) de ser o primeiro da lista.
Quando clicamos no restaurante, é enviada uma consulta pro servidor requisitando a lista de menus (ou pratos, chamem como preferir) utilizando o ID pertencente ao mesmo. Nos é retornado a seguinte tela:
(Lista de pratos disponível para seleção)
Selecionei alguns objetos no menu e adicionei ao Carro de Compras [1].
(Carro de Compras)
Podemos observar acima o preço de cada produto e também o preço do produto final R$ 267,20.
A falha está na possibilidade de modificação destes preços dentro do envio (POST) quando clicamos para verificar nosso Carro de Compra, segue exemplo:
(Requisição para chamar o carro de compras em hexa – Formato JSON)
(Requisição para chamar o carro de compras em ASCII – Formato JSON)
Alterando os parâmetros através da ferramenta BURP SUITE [2], temos esse retorno:
Conforme podem observar, o atacante neste caso fez uma alteração muito alta no valor e isso pode ser notado pelos restaurantes quando fizerem a verificação do preço. Imaginem um cenário onde apenas pequenos valores são alterados como: R$ 5,00 ou R$ 10,00 e posteriormente o atacante faz uma ligação informando que foi utilizado um cupom de desconto. Perfeitamente aceitável, hm ?
Prova de conceito
Como não tenho nenhum contato com restaurantes para testar o recebimento da requisição do cliente, eu escolhi por fazer uma requisição verídica e posteriormente cancelar.
(Preço de um pedido normal)
(Mesmo pedido modificado com o BURP SUITE)
Após ligar para fazer o cancelamento, o atendente me informou que havia notado algo errado pois um dos pedidos que tem o preço médio de R$ 10,00 – R$ 14,00 estava por R$ 2,50.
Abaixo o e-mail que recebi após fazer o pedido:
(E-mail recebido pelo iFood confirmando minha requisição modificada)
Por fim, quero deixar claro novamente que CANCELEI o pedido e não houve dano/lesão ao restaurante. O iFood falha em validar os valores dos pedidos, deixando a validação á cargo do cliente que como demonstrado, pode ser manipulado.
Responsible Disclosure
Entrei em contato com a empresa responsável pelo APP no dia 27/01/2016 e notifiquei a falha:
Dia que entrei em contato: 27/01/2016
Dia que responderam: 27/01/2016
Dia que enviei o artigo: 27/01/2016
Dia que corrigiram: 28/01/2016
Meios de contato: Através de e-mail conversei com o CTO e o CEO e por telefone com o CTO.
Observação: As empresas no Brasil deveriam seguir exemplo do iFood no quesito de recepção aos pesquisadores de segurança.
Referências
[1]http://blog.redehost.com.br/dicas/e-commerce-o-carrinho-de-compras.html
[2] https://en.wikipedia.org/wiki/Burp_suite
Notícia no G1: http://g1.globo.com/tecnologia/blog/seguranca-digital/post/falha-em-site-de-delivery-ifood-permitia-alterar-precos-de-pedidos.html
Igor, você está de parabéns! Nos mostrou várias vezes que o desenvolvimento de software seguro não é o forte em nosso País!
Isso me faz pensar no que nosso amigo Gustavo nos dizia sobre internet banking em dispositivos mobile. Devem existir falhas similares!
Abraço!
CurtirCurtido por 1 pessoa
Olá, como você fez para capturar as informações do celular com o aplicativo do ifood, qual ferramenta utilizou para isso… algo parecido com Finddler?
CurtirCurtir
Burp Suite.
CurtirCurtir
Muito legal… parabens
CurtirCurtir
Parabéns. ótimo trabalho.
CurtirCurtir
Ola bom dia , tenho uma plataforma semelhante ao iFood e gostaria de pedir que fizesses tais testes na mesma!
http://daprilanches.com.br/
CurtirCurtir
Me manda um email igrrincon@gmail.com
CurtirCurtir
Bro, gostei muito, tu utilizou mais algum aplicativo além do burp suite ?
CurtirCurtir
Só o Ifood e o burp. : )
CurtirCurtir
“(Requisição para chamar o carro de compras em hexa – Formato JSON)”
Não é em hexa, esta encodado em RFC 3986 com o formato percent-encoding.
CurtirCurtir
Obrigado pelo comentário cara!
Se você der uma olhadinha no RFC 3986 na parte que explica percent-enconding verá a seguinte informação:
“A percent-encoded octet is encoded as a character
triplet, consisting of the percent character “%” followed by the two
hexadecimal digits representing that octet’s numeric value.”
Talvez eu tenha errado em explicar especificamente o enconding como “Percent-Enconding” mas os caracteres estão em HEX mesmo, hehe.
Abraços!
CurtirCurtir
Muito Top,parabens pelas descobertas!
CurtirCurtir
Republicou isso em Awesome Democracy Initiatives.
CurtirCurtir