segunda-feira, 1 de dezembro de 2014

sábado, 29 de novembro de 2014

sexta-feira, 21 de novembro de 2014

segunda-feira, 17 de novembro de 2014

Hacking N Roll 2014: MiSc 300

Neste final de semana foi realizado o 'Hacking N Roll 2014'. O evento é um CTF (Capture The Flag) realizado pelo grupo Insert da UECE. Eu estou preparando alguns videos com algumas das soluções dos desafios apresentados no CTF. Vou começar essa pequena série de vídeos com o desafio 'MiSc 300'.

domingo, 9 de novembro de 2014

Palestra: Game of Bugs (InRedes 2014)

Pessoal,

Nesta terça-feira (11/Nov) eu vou estar palestrando no evento InRedes 2014 (realizado na Estácio FIC - Moreira Campos). O nome da palestra é: "Game of Bugs: As Crônicas de SSL e Bash". Eu vou estar realizando análises técnicas e demonstrações de algumas das maiores vulnerabilidades de 2014.

O Link para inscrições: http://goo.gl/n1Zq0d


quinta-feira, 30 de outubro de 2014

Hacking TRENDnet TEW-823DRU (CVE-2014-8579)

Nesta postagem eu vou estar fazendo uma pequena análise técnica sobre uma vulnerabilidade que eu encontrei no roteador wireless TEW-823DRU da TRENDnet. A vulnerabilidade esta presente na versão '1.00b30' do dispositivo. A vulnerabilidade recebeu o identificador CVE-2014-8579.

Figura 01: Roteador wireless TEW-823DRU (TRENDnet)
 

Análise Inicial do Firmware


O firmware vulnerável foi obtido na página oficial da TRENDnet (na seção de 'suporte'). A partir de uma pequena análise no conteúdo do firmware, é possível identificar a presença de um sistema de arquivos SquashFS (ver figura 02).

Figura 02: Analisando o firmware

A partir da figura 03, é possível verificar o conteúdo do sistema de arquivos e constatar de que o firmware roda em uma plataforma MIPS (muito comum em sistemas embarcados).

Figura 03: Analisando o firmware 02


Disassembly


A vulnerabilidade identificada esta presente no servidor FTP do roteador wireless (localizado em 'bin/KC_FTP'). A partir de um disassembly do arquivo binário do servidor FTP, é possível verificar a presença de uma string 'interessante' na função 'sub_410000' (ver figura 04).

Figura 04: Disassembly 01

Fazendo uma análise específica da função 'sub_410000', é possível verificar de que esta função realiza a autenticação do servidor de FTP. A partir da figura 05, é possível ver que a função realiza uma comparação entre o 'username' e a string 'root' (usuário administrador).

Figura 05: Disassembly 02

Um pouco abaixo da primeira comparação, é possível ver que uma segunda comparação é realizada com a string 'kcodeskcodes' (ver Figura 06).

Figura 06: Disassembly 03

O servidor FTP utiliza um senha hardcoded para o usuário administrador (root). Quem sabe os desenvolvedores da aplicação deixaram essa senha guardada para algum tipo de debugging ou até mesmo um backdoor.

 Conclusão


Nesta postagem eu falei um pouco sobre uma vulnerabilidade que eu identifiquei no servidor FTP do roteador wireless TEW-823DRU da TRENDnet. Eu divulguei a vulnerabilidade para a equipe de suporte da TRENDnet e a vulnerabilidade foi corrigida no novo firmware lançado: versão 1.00b36. Eu contactei o pessoal do MITRE e eles me deram um CVE para identificar a vulnerabilidade (CVE-2014-8579).

Por favor escrevam suas sugestões e comentários!

Obrigado :)

Keep Hacking!

terça-feira, 7 de outubro de 2014

Yo wa Shock: Analisando o Shellshock!

Nesta postagem eu vou estar analisando o bug do momento: Shellshock!. Eu também vou fazer uma rápida análise sobre alguns scripts que ja foram disponibilizados publicamente para realizar o ataque (Metasploit).

Observação:

O conteúdo apresentado nesta postagem deve ser reproduzido apenas em um ambiente no qual você possui autorização para a realização de testes de segurança.

ShellShock


O Shellshock explora um bug (alguns consideram como sendo uma funcionalidade) do bash (presente em sistemas Linux e Mac OS X). Para entender melhor a vulnerabilidade vamos dividir a análise em 2 partes: Definição de funções e exploração da vulnerabilidade.

Definição de funções e variáveis de ambiente


No bash podemos definir uma função da seguinte forma:

Figura 01: Definindo uma função
Esta função entretanto não pode ser chamada em uma nova sessão do bash 

Figura 02: Chamando função em nova sessão
Para conseguirmos chamar uma função entre diferentes sessões do bash, precisamos exportar a função como uma nova variável de ambiente.

Figura 03: Exportando a função

 

Explorando a vulnerabilidade


É possível "injetar" mais instruções após o término da definição da função exportada. Os códigos injetados serão executados quando a nova variável de ambiente for processada. A figura 04 apresenta um exemplo no qual um comando ("echo Owned") é injetado após a definição de uma função vazia. Como resultado, o comando injetado é executado pela nova sessão (bash -c).

Figura 04: Injetando comando na variável de ambiente
A figura 05 apresenta mais um exemplo no qual o comando "uname -a" é injetado na definação de uma variável de ambiente.

Figura 05: Injetando comando na varíavel de ambiente 02

 

Exploits publicados: Metasploit 


O pessoal do Metasploit ja publicou alguns módulos (auxiliary) para o ShellShock. Eu vou pegar o módulo "apache_mod_cgi_bash_env" como exemplo. A figura 06 apresenta as opções básicas do módulo.

Figura 06: Módulo apache_mod_cgi_bash_env
O script foi feito para scannear servidores web com arquivos cgi e passa o comando injetado (parâmetro CMD) no 'User-Agent' do cabeçalho HTTP (como demonstrado na figura 07).

Figura 07: Payload no cabeçalho HTTP

Conclusão


Nesta postagem eu fiz uma pequena análise sobre o Shellshock e também demonstrei um módulo do Metasploit publicado para explorar esta vulnerabilidade. Acredito que o Shellshock e o HeartBleed ja podem ser considerados os maiores bugs de 2014 (Mas ainda estamos em Outubro hehehe). Por favor escrevam suas sugestões e comentários!

Obrigado :)

Keep Hacking!

quarta-feira, 1 de outubro de 2014

Palestras: XIV SECOMP

Pessoal,

Próxima semana eu vou estar realizando 2 palestras no evento XIV SECOMP da Faculdade Lourenço Filho (FLF). O evento é aberto ao público (não precisa ser aluno da FLF). As palestras serão as seguintes:
  • Segunda-feira (06/10): Pentest e Estudo de Casos
  • Terça-feira (07/10): Pentest em Web Services
As inscrições serão realizadas até a data de início do evento (06/10) e serão feitas SOMENTE na secretaria da Faculdade Lourenço Filho (Rua Barão do Rio Branco 2101, Centro).

quinta-feira, 4 de setembro de 2014

Análise: iBrute

Pessoal,

A não ser que você viva dentro de uma caverna, é bem provavel de você ja estar informado sobre o vazamento de dados da nuvem da Apple (iCloud). A Apple ja lançou um depoimento oficial¹ sobre o vazamento de dados no qual é anunciado que não existia vulnerabilidade! (entretanto alguns scripts lançados no github antes do anúncio indicam o contrário). Nesta postagem eu queria fazer uma pequena análise sobre o que ja foi divulgado e o script lançado no github.


Vazamento de Dados


Os vazamentos de dados ocorreram no serviço de núvem da Apple (iCloud). Algumas fontes (fora da Apple) indicam que o ataque ocorreu devido a uma falha (a qual a Apple parece não admitir hehe)  presente no mecanismo de autenticação do serviço "Find My iPhone" (o qual não apresentava um mecanismo para detectar ataques de força-bruta).


Figura 01: Find My iPhone

iBrute (PoC)


O script pode ser encontrado no github:

https://github.com/hackappcom/ibrute/blob/master/id_brute.py

Vou dividir o script em duas partes principais: Wordlists e Método TryPass 

Wordlists


O script começa abrindo 2 wordlists (a primeira para senhas e a segunda para endereços de e-mail) nas linhas 79 a 86. Dois loops são gerados para percorrer os elementos das 2 wordlists (linhas 90 a 106) e chamar um método TryPass (que recebe exatamente 2 parâmetros: e-mail e senha).

Figura 02: Carregando Wordlists

Método TryPass 


O método começa definindo a URL alvo do ataque (a qual vai receber o parâmetro de e-mail). Os dados descritivos do dispositivo (Ex: versão do iOS e identificador do dispositivo) são enviados em uma requisição JSON (linhas 45 a 58) . O método criar uma requisição para realizar uma autenticação HTTP do tipo 'Basic' (no qual as credenciais são enviadas em Base64 para o servidor).

Figura 03: Método TryPass

Conclusão


Nesta pequena postagem eu falei um pouco sobre o vazamento de dados da iCloud e o script publicado no github como prova de conceito. A Apple afirmou de que não existia vulnerabilidade entretanto corrigiu o problema de autenticação no "Find My iPhone" (no mínimo contraditório ?).

¹ http://www.apple.com/pr/library/2014/09/02Apple-Media-Advisory.html

terça-feira, 26 de agosto de 2014

Engenharia Reversa no Corona SDK (Android / iOS)

Pessoal,

Hoje eu vou estar falando um novamente sobre aplicações mobile e também sobre o framework Corona SDK. Eu também vou estar publicando uma ferramenta que acabei desenvolvendo durante alguns projetos que eu peguei contendo aplicações geradas com o Corona SDK.

Introdução


O Corona SDK é um framework para a criação de aplicações mobile (Android e iOS). As aplicações são geradas utilizando a linguagem LUA e posteriormente são "convertidas" para a linguagem específica de cada plataforma (Java para Android e Objective-C para iOS). O Corona SDK se apresenta bastante famoso no cenário de games para dispositivos mobile.

Processo de criação / decompilação


O Corona SDK na realidade transforma os códigos LUA em uma representação intermediária (bytecodes) e armazena tudo em um arquivo chamado 'resource.car'. Para realizar a decompilação vamos ter que realizar os seguintes passos:
  1. Obter o arquivo 'resource.car' de dentro do arquivo apk / ipa (Tarefa fácil de realizar com um dispositivo jailbroken/rooted)
  2. Extrair os bytecodes de cada arquivo no 'resource.car'
  3. Realizar a decompilação do bytescodes e obter o código fonte (este passo pode ser realizado com alguns decompilers públicos ja existentes)

ResourceCarUnpacker.py


Eu criei um pequeno script em Python para automatizar os passos 2 e 3 do processo de extração / decompilação. O script abre o arquivo 'resource.car', extrai os bytecodes de cada arquivo fonte (em um diretorio chamado 'byteCode') e utiliza o 'unluac.jar' para realizar a decompilação dos bytecodes do LUA (o código fonte é guardado em um diretório chamado 'source').

Figura 01: ResourceCarUnpacker.py

A ferramenta esta disponível para download no github:

https://github.com/pasknel/hacking-com-tapioca/blob/master/ResourceCarUnpacker/ResourceCarUnpacker.py

O unluac (decompiler) esta disponível no sourceforge:

http://sourceforge.net/projects/unluac/

quarta-feira, 20 de agosto de 2014

OWASP Chapter: Fortaleza

Pessoal!

Eu e o Alan Aquino estamos reativando o capítulo OWASP de Fortaleza. Aos que não conhecem, OWASP(Open Web Application Security Project) é uma organização sem fins lucrativos que atua em todo o mundo e é focada em melhorar a segurança de aplicações Web através de pesquisas e compartilhamento de conhecimento.

Acesse a página pelo link abaixo e inscreva-se na lista.
https://www.owasp.org/index.php/Fortaleza

Por favor, divulguem!

Keep Hacking!

sexta-feira, 15 de agosto de 2014

Python + Android + RE = AndroGuard

Pessoal,

Hoje eu decidi escrever um pouco sobre uma ferramenta que eu descobri recentemente e achei muito interessante (vou fazer um pequeno tutorial hehe)! O AndroGuard é uma ferramenta escrita em Python para realizar engenharia reversa em aplicações para Android (muito bom para análise estática e automatização de tarefas comuns de RE). Espero mostrar nessa postagem uma pouco sobre a utilização do AndroGuard e algumas de suas principais funcionalidades.

Instalação 

 

Você pode instalar o AndroGuard facilmente:
  • hg clone https://androguard.googlecode.com/hg/ androguard 
Python 2.6 (ou superior) é necessário para rodar o AndroGuard. Você também pode instalar alguns pacotes opcionais (Ubuntu/Debian):
  • sudo apt-get install python-dev python-bzutils libbz2-dev libmuparser-dev libsparsehash-dev python-ptrace python-pygments python-pydot graphviz liblzma-dev libsnappy-dev
  • sudo easy_install ipython

 

Análise Estática: Iniciando o Androlyze


Para iniciar o androguard, vamos utilizar o  'androlyze.py' (Figura 01)

Figura 01: Rodando o androlyze.py
 O método 'AnalyzeAPK' pode ser utilizado para iniciar uma análise em um determinado arquivo apk (Figura 02). Este método recebe dois parâmetros de entrada (path do apk e o nome do decompiler que vai ser utilizado) e devolve três variáveis (objetos): apk (APK), dvm (DalvikVMFormat) e dex (VMAnalysis). Vamos ver que informações podemos tirar de cada um desses objetos.

Figura 02: AnalyzeAPK

 

Análise Estática: AndroidManifest.xml


Podemos utilizar nosso objeto apk para tirar algumas informações básicas do AndroidManifest.xml (como por exemplo: Permissões, Activities e Services). Vamos começar visualizando as permissões utilizadas pelo aplicativo (Figura 03).

Figura 03: Listando permissões
Activities também podem ser facilmente exibidas com o método 'get_activities'.

Figura 04: Listando Activities
Broadcast receivers e Services também podem ser listados (Figura 05).

Figura 05: Broadcast receivers e Services
O objeto apk oferece outros métodos muito interessantes para retirar informações básicas sobre o AndroidManifest. Você pode utilizar o método 'show' para pegar uma descrição mais detalhada sobre o arquivo Apk e o AndroidManifest.xml. Eu não coloquei nenhum exemplo de Content Providers por que o apk que eu estou analisando não possui nenhum deles.

Análise Estática: Decompilação

 

O próximo passo é listar os métodos e variáveis de cada classe. Podemos utilizar os método 'get_classes', 'get_methods' e 'get_fields' do objeto dvm para obter as informações desejadas. A figura 06 apresenta um exemplo contendo um pequeno loop para exibir os nomes das variáveis e métodos de todas as classes.

Figura 06: Obtendo informações de classes
Podemos utilizar o método 'get_class' para pegar uma classe específica. Para terminar este pequeno tutorial, podemos também obter o código fonte (ou algo próximo ao original) das classes com o método 'source'. A figura 07 apresenta um exemplo de código fonte obtido de uma classe específica.

Figura 07: Exemplo de decompilação

Conclusão


Nesta postagem eu escrevi um pequeno tutorial sobre o AndroGuard. Esta ferramenta é ótima para análise estática de aplicações desenvolvidas para Android. Eu acredito que a vantagem do AndroGuard é centralizar as funcionalidades de várias ferramentas e um único lugar. Você também utilizar esta ferramenta para automatizar algumas tarefas em seu processo de análise estática. Por favor escrevam suas sugestões e comentários!

Obrigado :)

Keep Hacking!

terça-feira, 22 de julho de 2014

quarta-feira, 9 de julho de 2014

Palestra: Pentest em SharePoint (ROADSEC 2014)

Pessoal,

Eu vou estar palestrando no ROADSEC 2014 (Fortaleza) no dia 19/07. O tema da palestra vai ser "Pentest em SharePoint". O evento vai ser realizado na Universidade de Fortaleza (UNIFOR). Para maiores informações ai vai o link do evento: 

http://roadsec.com.br/fortaleza





quarta-feira, 18 de junho de 2014

These aren't the droids you are looking for: Android Backdoors

Nesta postagem eu vou mostrar como criar um backdoor simples para um dispositivo Android com o Metasploit e vou fazer uma pequena análise sobre o apk gerado.

Observação:

O conteúdo apresentado nesta postagem deve ser reproduzido apenas em um ambiente no qual você possui autorização para a realização de testes de segurança.

Gerando um Backdoor


Um backdoor (Reverse TCP) para Android pode ser facilmente gerado com o Metasploit. O msfvenom pode ser utilizado para gerar um apk malicioso (Ver Figura 01).
Figura 01: Msfvenom
Vou utilizar o adb para instalar o backdoor em um simulador (Ver Figura 02).

Figura 02: Utilizando Abd para instalar backdoor

Rodando o Backdoor


Uma vez instalado, o backdoor vai aparecer da seguinte maneira no dispostivo:

Figura 03: Backdoor no Simulador

Antes de executar o backdoor, você deve gerar um 'handler' no Metasploit para receber a conexão reversa realizada pelo apk malicioso (Ver Figura 04).

Figura 04: Criando Handler

Execute o backdoor no simulador (ou dispositivo) e veja uma sessão sendo aberta no Metasploit (Ver Figura 05)

Figura 05: Sessão Aberta

Analisando o Backdoor


Vamos agora dar uma olhada melhor no apk gerado pelo Metasploit e ver se conseguimos aprender algumas coisas com ele. 

Taxa de Detecção

Vamos primeiro começar dando uma verificada na taxa de detecção do apk malicioso. A figura 06 apresenta os resultados do VirusTotal para o backdoor.

Figura 06: VirusTotal

O apk gerado apresenta uma taxa de detecção significativa (14 entre 54). A lista completa de detecção pode ser visualizada em https://www.virustotal.com/en/file/ae2133416ecddbe53390b46f6708200a0d2b6515800dfe6823bf5d1b8789640e/analysis/1402957750/

AndroidManifest.xml


O próximo passo é verificar o arquivo AndroidManifest.xml localizado dentro do apk. A figura 07 apresenta algumas informações básicas como nome do pacote e permissões necessárias para o malware.

Figura 07: AndroidManifest.xml 01
A partir da figura 07, é possível verificar que o malware é identificado pelo nome de pacote "com.metasploit.stage" (bastante sugestivo hehe) e utiliza um grande número de permissões (Ex: INTERNET, SEND_SMS e CAMERA). O apk apresenta uma única Activity: ".MainActivity" (ver figura 08).

Figura 08: AndroidManifest.xml 02

Decompilação (Parte 01)


O próximo passo é decompilar o apk e analisar o código fonte da aplicação. A Figura 09 apresenta as classes presentes no apk. É possível verificar a presença de MainActivity (declarada no Manifest.xml) e mais 3 classes (BuildConfig, LoadStage e R).

Figura 09: Classes
Vamos começar analisando a classe MainActivity. A partir da figura 10, é possível verificar de que o método 'AsyncTask()' é chamado logo no momento de criação de MainActivity. O método 'reverseTCP()' é chamado por 'AsyncTask()'.

Figura 10: MainActivity
A figura 11 apresenta o método 'reverseTCP()' e algumas variáveis globais (LHOST e LPORT). O método 'reverseTCP' cria um socket (gerando uma conexão para LHOST) e chama a classe 'LoadStage'.

Figura 11: MainActivity 02

A classe 'LoadStage' apresenta 2 métodos interessantes: 
  • randomJarName: Cria uma String de 20 caracteres aleatórios que vai servir de nome para um arquivo '.jar'.
  • start: Cria um novo arquivo '.jar' () e baixa o conteúdo de um novo arquivo '.dex' pela rede. DexClassLoader e Reflection são utilizados para executar o novo arquivo '.dex' (ultimas 3 linhas do método 'start').   

Figura 12: LoadStage

Decompilação (Parte 02)


Nesta segunda parte vamos analisar o novo '.dex' gerado no dispositivo. A figura 13 apresenta os novos arquivos criados na pasta do aplicativo (observe os nomes aleatórios utilizados nos arquivos).

Figura 13: Novos arquivos gerados (jar e dex)
Eu encontrei um pequeno problema durante o processo de decompilação do arquivo '.dex' (ver figura 14). O arquivo na realidade trata-se de ser um '.odex' (tipo otimizado de '.dex').

Figura 14: Erro na decompilação (Arquivo 'odex')

Para decompilar um arquivo '.odex' vamos ter que tomar alguns passos:
  • Copiar os arquivos de '/system/framework' para a máquina local
    • "adb pull /system/framework/ /tmp/framework/"
  • Obter arquivos 'smali' utilizando o baksmali.jar
    • "java -jar baksmali-2.0.3.jar -a 15 -x /tmp/nome_aleatorio.dex -d /tmp/framework/ -o Backdoor"
  • Reconstruir o 'classes.dex' com smali.jar
    • "java -jar smali-2.0.3.jar -o classes.dex Backdoor/"

Decompilação (Parte 3)


Agora podemos analisar melhor o '.dex' baixado e executado pelo backdoor. O arquivo '.jar' agora é recriado sem problemas. A Figura 15 apresenta as classes presentes (Shell, Stage e StreamForwarder).

Figura 15: Classes 02
Os nomes dos pacotes são novamente bem sugestivos (hehe). A partir da figura 16, é possível verificar que a classe Shell cria um novo processo ('sh') e realiza uma śerie de 'redirecionamentos' para executar cada instrução recebida pelo atacante e retornar a resposta de cada comando executado.

Figura 16: Classe Shell

Conclusão


Nesta postagem eu falei um pouco sobre backdoors em Android (gerados pelo Metasploit) e fiz uma pequena análise sobre eles. O processo de decompilação pode ser reproduzido para outros tipos de malware. Por favor escrevam suas sugestões e comentários!

Obrigado :)

Keep Hacking!

sábado, 17 de maio de 2014

Mini-Curso: Pentest em IPv6

Pessoal!

Estou aqui divulgando o meu mini-curso de "Pentest em IPv6". Neste curso vamos ver a metodologia de um Pentest sendo aplicada para cenários de redes IPv6. Os tópicos do mini-curso:
  1. Introdução 
  2. Scanning em redes IPv6
  3. Exploitation em redes IPv6
  4. Post-Exploitation em redes IPv6
Vai ser um mini-curso de nível "Intermediário/Avançado" por isso eu recomendo o curso para aqueles que ja tem conhecimento de redes (vamos trabalhar muito com cabeçalhos e geração de pacotes) e programação (vamos criar nossas próprias ferramentas para alguns ataques).

O mini-curso vai estar ocorrendo dentro do envento "4º Sábado com TIC". O evento vai ser realizado no dia 31/05/2014. O banner do evento vai aqui embaixo para maiores informações (Obs: O mini-curso vai ser PAGO entretanto as palestras do evento serão grátis).


sexta-feira, 9 de maio de 2014

Análise de Malware 01: ZitMo (Android)

Hoje eu vou estar fazendo uma pequena análise sobre o ZitMo (também conhecido como ZeuS-in-the-Mobile). O ZitMo é um malware para Android e foi desenvolvido com o objetivo de roubar mensagens de SMS do dispositivo da vítima (vamos ver como isso funciona). O arquivo '.apk' pode ser encontrado na URL abaixo:

http://www.mediafire.com/?jvds225lczxrv7o (senha: infected)

Detecção


Podemos verificar algumas detecções iniciais mandando o arquivo '.apk' para o VirusTotal. A figura 01 apresenta a quantidade de anti-vírus que detectaram o arquivo como sendo malicioso.

Figura 01: Taxa de Detecção

A partir da figura 02, é possível verificar de que alguns anti-vírus identificam o arquivo como sendo Zitmo (Ex: Kaspersky) e outros identificam como sendo 'Android/Spy' (Ex: McAfee).

Figura 02: Lista de AVs

 

Informações Básicas


Vamos dar uma olhada no arquivo 'AndroidManifest.xml' e obter algumas informações básicas sobre o malware. A Figura 03 apresenta o início do arquivo 'AndroidManifest.xml'.

Figura 03: Verificando permissões
 É possivel verificar que o malware necessita de 3 permissões:
  • RECEIVE_SMS: Acesso às mensagens de SMS recebidas
  • INTERNET: Acesso à internet
  • READ_PHONE_STATE: Acesso de leitura ao estado do dispositivo
A figura 04 apresenta mais informações sobre o 'AndroidManifest.xml'.

Figura 04: Verificando activities e receivers

A partir da figura 04, é possível verificar de que a aplicação apresenta uma única Activity (identificado como ".Activation") e um broadcast receiver (identificado como ".SmsReceiver"). Tambem é possível constatar de que o receiver utilizado responde às mensagens de SMS recebidas.

Instalando o Apk no Simulador


Vamos agora instalar o malware no simulador (disponível no ADT). A instalação pode ser realizada facilmente com a ferramenta 'adb' da seguinte forma:
  • adb install 'arquivo.apk'
A figura 05 apresenta o malware instalado no simulador. Percebam de que o malware se apresenta ao usuário como 'Trusteer Rapport'.

Figura 05: Malware instalado

A figura 06 apresenta o malware sendo executado (uma única Activity).

Figura 06: Malware sendo executado

Decompilando o código


Vamos decompilar o malware para podermos ter mais informações sobre o seu funcionamento interno. A Figura 07 apresenta as classes presentes na aplicação (6 ao total). 

Figura 07: Decompilação (Classes)

 Classe SmsReceiver


A partir da figura 04, foi possível constatar de que o malware possui um Broadcast Receiver (implementado na classe SmsReceiver). A classe SmsReceiver recebe eventos de mensagens de SMS e encaminha elas para a classe MainService (ver figura 08).

Figura 08: Classe SmsReceiver

Classe MainService


A classe MainService é chamada por SmsReceiver e encaminha as mensagens de SMS recebidas para uma Thread (SmsBlockerThread). A figura 09 apresenta um trecho da classe MainService.

Figura 09: Classe MainService

Thread SmsBlockerThread

 

SmsBlockerThread realiza algumas ações nas mensagens recebidas:
  1. Extração de informação: A Thread retira informações sensíveis da mensagem de SMS. As variáveis 'str1' e 'str2' contém respectivamente a orígem e conteúdo da mensagem. A variável 'str3' apresenta o IMEI do dispositivo.
  2. Envio de informações: Os dados roubados são encaminhados para o método 'postRequest' da classe ServerSession (esta classe é responsável por enviar os dados para um servidor remoto).
Figura 10: SmsBlockThread

Classe ServerSession


Na classe ServerSession podemos constatar alguns pontos:
  1. Localização do servidor remoto: O método 'initUrl' retorna uma String com a localização do servidor remoto (para onde as informações da vítima são enviadas)
  2. Envio das mensagens: As informações roubadas são enviadas através do método postRequest (DefaultHttpClient é utilizado para realizar a requisição HTTP [Variável 'localHttpPost']).
Figura 11: Classe ServerSession

Conclusão


Nesta postagem eu fiz uma pequena análise sobre o ZitMo (ZeuS-in-the-Mobile). Eu devo estar apresentado mais algumas análises de malware no blog. Por favor escrevam suas sugestões e comentários!

Obrigado :)

Keep Hacking!