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