Upload
valdemir-vieira-junior
View
931
Download
18
Embed Size (px)
DESCRIPTION
Trabalho de gradução interdisciplinar apresentado na Universidade Presbiteriana Mackenzie em Novembro de 2013. Existem diversas técnicas para perícia forense em desktops e estas já estão bastante difundidas. No entanto, no que se refere a computação pessoal o cenário mundial está em plena mudança. Cada vez mais pessoas deixam de utilizar os tradicionais computadores pessoais e concentram suas atividades em smartphones e tablets. Dentre os sistemas operacionais para dispositivos móveis, o que vem mostrando o maior crescimento é o Android, e por isso ele é o foco desta pesquisa. As técnicas de forense digital conhecidas para telefones celulares e desktops não são suficientemente específicas e detalhadas para realização de exames em dispositivos controlados pelo Android. O objetivo do trabalho é apresentar técnicas de perícia forense com métodos específicos para o sistema operacional Android. Para a apresentação destes métodos de perícia forense, foram mapeadas situações reais em que os peritos se encontram durante os processos de extração de dados. Ao final do trabalho foi proposto um estudo de caso, no qual um smartphone com Android é propositalmente infectado com um trojan e este identificado através do uso de algumas das técnicas forenses apresentadas.
Citation preview
UNIVERSIDADE PRESBITERIANA MACKENZIE FACULDADE DE COMPUTAÇÃO E INFORMÁTICA
CIÊNCIA DA COMPUTAÇÃO
VALDEMIR VIEIRA JUNIOR
FORENSE DIGITAL EM DISPOSITIVOS MÓVEIS COM SISTEMA
OPERACIONAL ANDROID
São Paulo
2013
VALDEMIR VIEIRA JUNIOR
FORENSE DIGITAL EM DISPOSITIVOS MÓVEIS COM SISTEMA
OPERACIONAL ANDROID
ORIENTADORA: Professora Drª Maria Ines Lopes Brosso Pioltine
São Paulo
2013
Trabalho de Graduação Interdisciplinar apresentado ao curso de Ciência da Computação, da Faculdade de Computação e Informática da Universidade Presbiteriana Mackenzie, como requisito parcial à obtenção do grau de Bacharel em Ciência da Computação.
AGRADECIMENTOS
Aos meus pais que mesmo não podendo me ajudar diretamente contribuíram
com o que puderam durante a minha jornada.
A minha orientadora, Professora Dra. Maria Inês Lopes Brosso Pioltine, que me
guiou durante todo o desenvolvimento deste trabalho, me ajudando a manter o
foco na pesquisa proposta desde o seu início.
Aos meus colegas de trabalho pelo tempo dedicado a me ouvir falar da
pesquisa e pelas sugestões acrescentadas a este trabalho.
“Não devemos parar de explorar. E o fim de toda a nossa exploração será chegar ao ponto de partida e ver o lugar pela primeira vez”
T. S. Eliot
RESUMO
Existem diversas técnicas para perícia forense em desktops e estas já estão
bastante difundidas. No entanto, no que se refere a computação pessoal o
cenário mundial está em plena mudança. Cada vez mais pessoas deixam de
utilizar os tradicionais computadores pessoais e concentram suas atividades
em smartphones e tablets. Dentre os sistemas operacionais para dispositivos
móveis, o que vem mostrando o maior crescimento é o Android, e por isso ele é
o foco desta pesquisa. As técnicas de forense digital conhecidas para telefones
celulares e desktops não são suficientemente específicas e detalhadas para
realização de exames em dispositivos controlados pelo Android. O objetivo do
trabalho é apresentar técnicas de perícia forense com métodos específicos
para o sistema operacional Android. Para a apresentação destes métodos de
perícia forense, foram mapeadas situações reais em que os peritos se
encontram durante os processos de extração de dados. Ao final do trabalho foi
proposto um estudo de caso, no qual um smartphone com Android é
propositalmente infectado com um trojan e este identificado através do uso de
algumas das técnicas forenses apresentadas.
Palavras-chave: Android, Análise Forense, Segurança, Mobile, Aquisição de
Dados, Smartphones.
ABSTRACT
There are several techniques for forensics on desktops and these are already
quite widespread. However, in regard to personal computers in the world
scenario is full change. More and more people stop using traditional personal
computers and focus their activities on smartphones and tablets. Among the
operating systems for mobile devices, which has shown the greatest growth is
Android, so it is the focus of this research. The digital forensic techniques
known for mobile phones and desktops are not sufficiently specific and detailed
examinations on devices controlled by Android. The objective is to present
forensic techniques with methods specific to the operating system Android. For
the presentation of these methods forensics were mapped actual situations in
which the experts are in the process of data extraction. At the end of the work
we propose a case study in which a smartphone with Android is purposely
infected with a trojan and this identified through the use of some of forensic
techniques presented.
Keywords: Android, Forensics, Security, Mobile, Data Acquisition,
Smartphones.
SUMÁRIO
CAPÍTULO 1. INTRODUÇÃO ....................................................................... 14
1.1 INTRODUÇÃO ........................................................................................ 14
1.2 OBJETIVO .......................................................................................... 15
1.3 MOTIVAÇÃO ....................................................................................... 15
1.4 JUSTIFICATIVA .................................................................................. 16
1.5 TRABALHOS RELEVANTES .............................................................. 16
1.6 METODOLOGIA DE PESQUISA ........................................................ 16
1.7 ORGANIZAÇÃO DO TRABALHO ....................................................... 16
CAPÍTULO 2. O SISTEMA OPERACIONAL ANDROID ............................... 18
2.1 INTRODUÇÃO .................................................................................... 18
2.2 A PLATAFORMA................................................................................. 19
2.3 A MÁQUINA VIRTUAL DALVIK .......................................................... 21
2.3.1 Comparação entre a Sun JVM e a Dalvik VM ............................... 22
2.3.2 O formato dex ............................................................................... 23
2.4 ANDROID SOFTWARE DEVELOPMENT KIT .................................... 24
2.4.1 Android NDK ............................................................................. 25
2.4.2 Android Virtual Devices (AVD) .................................................. 25
2.4.3 Android Debug Bridge - ADB Tools ........................................... 28
2.5 SISTEMAS DE ARQUIVOS ................................................................ 30
2.5.1 FAT32 ........................................................................................ 30
2.5.2 YAFFS2 ..................................................................................... 31
2.5.3 Partições do Sistema de Arquivos ............................................. 32
2.5.4 Formas de Persistência de Dados ............................................ 33
2.6 LOGS DO SISTEMA E DAS APLICAÇÕES ........................................ 35
2.6.1 Log do Kernel do Linux.............................................................. 35
2.6.2 Logs dos Apps ........................................................................... 40
2.7 GOOGLE PLAY .................................................................................. 41
CAPÍTULO 3. SEGURANÇA NO SISTEMA OPERACIONAL ANDROID ..... 42
3.1 INTRODUÇÃO .................................................................................... 42
3.2 PERMISSÃO POR APLICAÇÃO ......................................................... 42
3.3 VULNERABILIDADES NO ARMAZENAMENTO DE INFORMAÇÕES 47
3.4 PROTEÇÃO DOS DADOS NO ANDROID .......................................... 48
3.4.1 Bloqueio de Tela ....................................................................... 48
3.4.2 Criptografia de Dados................................................................ 50
3.5 SEGURANÇA NA TRANSMISSÃO DE INFORMAÇÕES ................... 51
3.5.1 Autenticação no protocolo SSL/TLS .......................................... 52
3.5.2 Transmissão dos Dados ............................................................ 52
3.6 AMEAÇAS NA TRANSMISSÃO DE DADOS ...................................... 53
3.7 MALWARE .......................................................................................... 53
CAPÍTULO 4. FORENSE DIGITAL NO ANDROID ....................................... 55
4.1 INTRODUÇÃO .................................................................................... 55
4.2 TIPOS DE INVESTIGAÇÃO ................................................................ 56
4.3 AMBIENTE DE TESTES ..................................................................... 57
4.4 PRESERVANDO O ESTADO DO DISPOSITIVEL MÓVEL ................ 59
4.4.1 Passando pelo Bloqueio de Tela ............................................... 59
4.4.2 Isolando o Dispositivo Móvel da Rede ...................................... 62
4.4.3 Conhecendo o Dispositivo ......................................................... 64
4.5 EXTRAINDO INFORMAÇÕES DO DISPOSITIVO.............................. 64
4.5.1 Extração Via Software ............................................................... 64
4.5.2 Extração Via Hardware.............................................................. 66
4.6 ANÁLISE DAS INFORMAÇÕES OBTIDAS ........................................ 66
4.6.1 Ferramentas e Técnicas de Análise de Dados .......................... 66
4.6.2 Análise Forense das Partições SDCard e eMMC ...................... 69
4.6.3 Análise Forense no Sistema de Arquivos YAFFS2 ................... 72
CAPÍTULO 5. ESTUDO DE CASO ............................................................... 73
5.1 INTRODUÇÃO .................................................................................... 73
5.2 METODOLOGIA DE ANÁLISE PROPOSTA ....................................... 73
5.2.1 O Malware Zitmo ....................................................................... 75
5.2.2 Identificação do Malware ........................................................... 75
5.2.3 Engenharia Reversa e Análise do Arquivo APK ........................ 77
5.3 CONCLUSÃO ..................................................................................... 80
CAPÍTULO 6. CONCLUSÃO ........................................................................ 81
6.1 TRABALHOS FUTUROS .................................................................... 81
REFERENCIAS ................................................................................................ 83
LISTA DE TABELAS
Tabela 1 – Vendas de Smartphones por SO no mundo (em milhares de
unidades).......................................................................................................... 19
Tabela 2 – Distribuição das versões do Android .............................................. 21
Tabela 3 – Comparação entre os tamanhos dos arquivos JAR e DEX ............ 24
Tabela 4 – Data de disponibilização do Android SDK ...................................... 24
Tabela 5 – Localização dos arquivos criados pelo AVD ................................... 27
Tabela 6 – Estrutura do diretório /data/data/<ApplicationPackageName> ....... 33
Tabela 7 – Níveis de log ................................................................................... 37
Tabela 8 – Opções de comando de linha do logcat ......................................... 38
Tabela 9 – Técnicas para isolar um dispositivo móvel da rede ........................ 63
Tabela 10 – Partições e sistemas de arquivos ................................................. 67
LISTA DE FIGURAS
Figura 1 – Assinantes da telefonia celular por ano no mundo. ......................... 14
Figura 2 – Visão da arquitetura do SO Android ................................................ 19
Figura 3 – Relação entre versão do Android em aparelhos em uso ................. 21
Figura 4 - Java vs Dalvik .................................................................................. 23
Figura 5 – AVD em execução ........................................................................... 26
Figura 6 – Estrutura de diretórios criados pelo AVD ........................................ 27
Figura 7 – Instalação do Android ADB Tools.................................................... 28
Figura 8 – Ativação do modo de depuração no Android .................................. 29
Figura 9 – Comando adb devices ..................................................................... 29
Figura 10 – Comando adb shell ....................................................................... 30
Figura 11 – Listagem do diretório shared_prefs do aplicativo Phone ............... 33
Figura 12 – Arquivo XML do tipo chave-valor................................................... 34
Figura 13 – Listagem do diretório data/data ..................................................... 34
Figura 14 – Saída do comando dmesg ............................................................ 36
Figura 15 – Saída do comando logcat .............................................................. 37
Figura 16 – Saída do comando dumpsys ......................................................... 39
Figura 17 – Saída do comando dumpstate ...................................................... 40
Figura 18 – Listagem do diretório do app Dropbox .......................................... 41
Figura 19 – Visualização do arquivo de logs do app Dropbox ......................... 41
Figura 20 – Instalação dos Apps Google Maps e Gmail respectivamente ....... 44
Figura 21 – Visualização da permissão de acesso no Manifest.xml ................ 44
Figura 22 – Restrição de acesso no Manifest.xml ............................................ 46
Figura 23 – Aviso do Android sobre fontes desconhecidas .............................. 47
Figura 24 – Tela de configuração de bloqueio do Android ............................... 49
Figura 25 – Bloqueio de tela por código pin, desenho de padrão e senha
alfanumérica respectivamente. ......................................................................... 49
Figura 26 – Tela de opção para criptografar os dados do dispositivo .............. 50
Figura 27 – Criptografia dos dados: telas de aviso e confirmação
respectivamente ............................................................................................... 51
Figura 28 – Exemplo de configuração de conexão SSL/TLS ........................... 53
Figura 29 – Foto mostrando a marca do pattern desenhado. .......................... 60
Figura 30 – Saída do comando lsub ................................................................. 64
Figura 31 – Extração de dados via adb pull sem acesso de root ..................... 65
Figura 32 – Extração de dados via adb pull como root .................................... 65
Figura 33 – Saída do comando mount ............................................................. 67
Figura 34 – Saída do comando strings sobre uma base SQLite ...................... 68
Figura 35 – Visualização de uma base SQLite no hexeditor ............................ 69
Figura 36 – Visualização das tabelas de uma base SQLite ............................. 69
Figura 37 – Opção Mover para o cartão de memória ....................................... 70
Figura 38 – Listagem do diretório /mnt ............................................................. 71
Figura 39 – Diagrama de identificação e análise de malware .......................... 74
Figura 40 – Instalação do APP Trusteer Rapport ............................................. 76
Figura 41 – Visualização dos processos em execução .................................... 76
Figura 42 – Extração do arquivo apk do app suspeito ..................................... 77
Figura 43 – Analise do tráfego de rede do AVD pelo software Wireshark ........ 77
Figura 44 – Visualização do conteúdo do apk do app Zitmo ............................ 77
Figura 45 – Execução da ferramenta APKTools .............................................. 78
Figura 46 – Execução da ferramenta dex2jar................................................... 79
Figura 47 – Visualização do código do Zitmo no JD-GUI ................................. 79
LISTA DE SIGLAS E ABREVIAÇÕES
ADB Android Debug Bridge
API Application Programing Interface
APP Application Software
AVD Android Virtual Device
DVM Dalvik Virtual Machine
DiD Defense in Depth
GC Garbage Collection
GPL GNU Public License
GPS Global Positioning System
GSM Global System for Mobile
HTML HyperText Markup Language
IDE Integrated Development Environment
JVM Java Virtual Machine
MMC MultiMedia Card
MMS Multimedia Messaging Service
NDK Native Code Development
PC Personal Computer
RAM Random Access Memory
SDK Software Development Kit
SIM Subscriber Identity Module
SMS Short Message Service
SO Sistema Operacional
SQL Structured Query Language
SSL Security Sockets Layer
TLS Transport Layer Security
VM Virtual Machine
UI User Interface
USB Universal Serial BUS
XML Extensible Markup Language
YAFFS2 Yet Another Flash File System
14
CAPÍTULO 1. INTRODUÇÃO
1.1 INTRODUÇÃO
No mundo da telefonia pode-se dizer que os dez últimos anos foram da
telefonia celular. O número de assinantes de telefones móveis no mundo inteiro
aumentou de 738 milhões em 2000 para quase seis bilhões em 2011, como
mostra o gráfico da figura 1, e agora o número de assinantes da telefonia
celular ultrapassa o número de linhas telefônicas convencionais (ITU Statistics,
2011).
Figura 1 – Assinantes da telefonia celular por ano no mundo.
Fonte: (ITC Statistics, 2013).
Somente no Brasil, em agosto 2013, o número de assinantes de telefonia
móvel totalizava 268.4 milhões (Anatel, 2013), uma média de 135.45 celulares
para cada 100 habitantes. Com o advento de laptops, palmtops, PDAs e mais
recentemente dos smartphones, a promessa de acesso desimpedido à Internet
global, a qualquer hora, a qualquer lugar (internet ubíqua) já é uma realidade
por meio de equipamentos leves e totalmente portáteis. (Redes de
Computadores e a Internet, 2010).
0
1.000.000.000
2.000.000.000
3.000.000.000
4.000.000.000
5.000.000.000
6.000.000.000
7.000.000.000
Nú
me
ro d
e A
ssin
ante
s
Ano
Assinantes de telefonia celular
Assinantes
15
Dentre esses dispositivos móveis, hoje, a maior parte deles vem com o sistema
operacional Android, do Google, instalado. E a cada nova versão, o sistema
adiciona novas funcionalidades para tirar proveito do hardware dos
dispositivos, que aumenta o poder de processamento a cada poucos meses. O
ultimo smartphone oficial do Google, Nexus 4, por exemplo, tem 2GB de
memória RAM integrada, processador quad-core de 1,5GHz e 16GB de
armazenamento interno. Isso somado a itens como: câmera, acelerômetro,
GPS e suporte a conexões de rede sem fio, fazem do dispositivo muito mais do
que um celular, mas sim uma enorme fonte de informações onde seus usuários
podem armazenar não apenas contatos telefônicos, mas também documentos
importantes através de serviço de cloud computing, traçar rotas com o serviço
de GPS e publicar fotos de viagens família e outros.
Neste cenário, a comunidade forense se depara com um grande desafio já que
as técnicas de extração de dados, já consolidadas para os desktops, não
funcionam para dispositivos com hardware específico para o Android. Numa
análise forense, à medida que o nível de compreensão sobre o sistema
operacional e seu hardware aumentam, novas técnicas de manuseio e
extração de informações relevantes são desenvolvidas. Assim, um profundo
conhecimento do sistema operacional Android, onde as informações nele são
salvas e quais informações buscar, pode trazer dados muito úteis e até
decisivos sobre o seu usuário.
1.2 OBJETIVO
O objetivo da pesquisa é apresentar métodos de perícia forense para
dispositivos móveis com sistema operacional Android.
1.3 MOTIVAÇÃO
Descrever técnicas de análise forense em dispositivos móveis com Android. As
técnicas de perícia forense para desktops já são bastante difundidas e sua
aplicação a smartphones e tablets requer técnicas diferentes. A extração dos
dados será feita de forma a obter todas as informações possíveis do
equipamento.
16
1.4 JUSTIFICATIVA
Nos últimos 4 anos houve um aumento substancial no número de dispositivos
móveis com Android, a tal ponto que este se tornou a plataforma móvel mais
utilizada do mercado.
1.5 TRABALHOS RELEVANTES
A tese de mestrado “Proposta de Método para Análise Pericial em Smatphone
com Sistema Operacional Android”, de André Morum de Lima Simão publicada
em 2011 serviu como guia para este trabalho, nela são abordadas as
dificuldades técnicas para a extração de dados de smartphones Android além
da proposta de uma metodologia para realizar essa recuperação de
informações, onde são abordadas situações reais encontradas pelos analistas
forenses.
O artigo publicado pela Digital Investigation, Android anti-forensics through a
local paradigma, publicado em 2010 por Alessandro Distefano, Gianluigi Mea e
Francesco Pace, onde algumas técnicas para dificultar o acesso às
informações dos dispositivos Android são apresentadas.
Android Forensics: Simplifying Cell Phone Examinations, artigo publicado pela
Edith Cowan University, de autoria de Jeff Lessard e Gary Kessler, publicado
em 2010, onde mais técnicas para obtenção de dados são apresentadas e
utilizadas de forma complementar neste trabalho.
1.6 METODOLOGIA DE PESQUISA
Para o desenvolvimento desta pesquisa optou-se, para uma primeira parte, por
uma pesquisa bibliográfica sobre a plataforma Android.
1.7 ORGANIZAÇÃO DO TRABALHO
A pesquisa foi dividida em 6 (seis) capítulos.
O capítulo 1 apresenta o problema e a justificativa para o trabalho.
O capítulo 2 mostra uma visão sobre o sistema operacional Android. Sua
história, arquitetura, versões e funcionalidades.
17
O capítulo 3 se dedica a mecanismos de segurança no sistema operacional
Android.
O capítulo 4 apresenta as técnicas de perícia forense no Android para extração
e análise de informações.
O capítulo 5 desenvolve o estudo de caso. Um smartphone propositalmente
infectado com um spyware é submetido para análise utilizando as ferramentas
e técnicas apresentadas no capítulo anterior.
O capítulo 6 conclui a pesquisa descrevendo sua relevância a partir dos
resultados obtidos no estudo de caso e apresentando novos temas para
continuidade do trabalho.
18
CAPÍTULO 2. O SISTEMA OPERACIONAL ANDROID
2.1 INTRODUÇÃO
O Google planejando entrar no mercado de celulares com seus serviços de
internet encontrou-se no impasse de não possuir uma plataforma para isso.
Então em agosto de 2005 adquiriu a Android Inc³. Após um tempo sem notícias
é anunciada, em 2007, a Open Handset Alliance, que coloca o Android
oficialmente no mundo Open Source. Em 2008 a versão 1.0 do SDK é lançada,
assim como o primeiro celular com o sistema, o G1 da HTC. Em 2009, com o
lançamento das versões 1.5, 1.6 e 2.x, viu-se uma proliferação de dispositivos
que rodam o sistema. Em 2010, o Android já era o segundo sistema mais
utilizado em smartphones, atrás apenas do então bem sucedido Blackberry
(Learning Android, 2011).
Quando o Google comprou a Android Inc, em 2005, o CEO na época, Eric
Schmidt, deixou claro que a ambição do Google era muito maior do que ver o
sistema rodando em um simples telefone. A intenção da empresa e ver o
sistema rodando em todos os lugares e fazendo tudo, como o Google é uma
empresa de media, quanto mais pessoas utilizarem os seus produtos, mais
fácil adicionar novos serviços e propagandas junto com eles(Learning Android,
2011).
Atualmente o Google licencia alguns aplicativos proprietários como Gmail e
Maps, e ganha algum dinheiro com o Google Play (Learning Android, 2011).
Desde o primeiro telefone com o sistema, lançado em 2008, até torna-se o SO
para dispositivos móveis mais utilizado, o número de usuários do sistema
Android continua a aumentar a cada ano.
A tabela 1 mostra os números de vendas de smatphones a usuários finais por
sistema operacional em 2013. Por ela é possível ver a dominância do sistema
da Google além de um crescimento em relação ao ano anterior.
19
Tabela 1 – Vendas de Smartphones por SO no mundo (em milhares de unidades)
Sistema Operacional
Unidades vendidas em 2013
Participação no mercado em 2013 (%)
Unidades vendidas em 2012
Participação no mercado em 2012 (%)
Android 177,898.2 79.0 98,664.0 64.2
iOS 31,899.7 14.2 28,935.0 18.8
Microsoft 7,407.6 3.3 4,039.1 2.6
BlackBerry 6,180.0 2.7 5.2
Bada 838.2 0.4 7,991.2 2.7
Symbian 630.8 0.3 4,208.8 5.9
Outros 471.7 0.2 9,071.5 0.6
Total 225,326.2 100.0 153,772.9 100.0 Fonte: (Gartner, Agosto de 2013).
2.2 A PLATAFORMA
O Android é um SO (sistema operacional) construído especificamente para
dispositivos móveis, ele tem como base o kernel do Linux. Ele inclui interface
gráfica rica, aplicações para o usuário final, bibliotecas, frameworks, suporte
multimídia entre outros. A figura 2 apresenta uma visão da arquitetura do SO.
Figura 2 – Visão da arquitetura do SO Android
Fonte: (Android Developers, 2013).
20
Abaixo uma breve descrição de cada camada da arquitetura do sistema:
Kernel: o Android, a partir da versão 4.0.4, utiliza a versão 3.0 do Kernel
do Linux. O Kernel é responsável pelo gerenciamento dos processos, da
memória e do hardware do dispositivo, agindo como uma camada de
abstração entre hardware e software (Linux Command Line and Shell
Scripting Bible, 2008).
Bibliotecas: escritas em C/C++, fazem parte de todo sistema Linux. No
Android, são invocadas através de uma interface Java. Dentre essas
bibliotecas estão disponíveis gerenciadores de janela (window
manager), base de dados SQLite, suporte a gráficos 2D e 3D entre
outros (Learning Android, 2011).
Ambiente de execução do Android: é a camada de execução da Dalvik
VM que fornece as aplicações funcionalidades disponíveis na biblioteca
Java (Learning Android).
Framework de aplicações: aberto e de desenvolvimento colaborativo,
promove a reutilização de funções entre as aplicações. A mesma API
(Application Program Interface) disponível para as aplicações nativas do
Android está, também, disponível aos desenvolvedores.
Camada de aplicação: conjunto básico de aplicativos que são
distribuídos com a plataforma Android.
Uma característica do Android que fica evidenciada pela figura acima é que,
não existe diferença entre aplicações nativas e as criadas por outros
desenvolvedores, já que os dois tipos utilizam as bibliotecas providas pela
Dalvik VM. Esse fato evidencia que qualquer desenvolvedor pode criar
aplicações poderosas para o Android.
A tabela 2 e o gráfico de pizza da figura 3 são baseados no número de
dispositivos com Android que acessaram o Google Play, em um período de 14
dias terminando em 4 de Março de 2013.
21
Tabela 2 – Distribuição das versões do Android
Versão Codenome Data de Lançamento API Level
Distribuição
1.0 23 de setembro de 2008
1
1.1 9 de fevereiro de 2009
2
1.5 Cupcake 30 de abril de 2009 3
1.6 Donut 15 setembro 2009 4
2.1 Eclair 30 de outubro 2009 7
2.2 Froyo 20 de maio 2010 8 1.7%
2.3 – 2.3.2 Gingerbread 6 de dezembro 2010 9
2.3.3 - 2.3.7
10 26.3%
3.1 Honeycomb 22 de fevereiro de 2011
12
3.2 13 0.1%
4.0.3 – 4.0.4
Ice Cream Sandwich
19 de outubro de 2011
15 19.8%
4.1 Jelly Beans 9 de julho de 2012 16 37.3%
4.2 Jelly Beans 13 de Novembro de 2012
17 12.5%
4.3 Jelly Beans 24 de Julho de 2013 18 2.3%
4.4 Kit Kat 31 de Outubro de 2013
19
Fonte: (Android Developers, 2013).
Figura 3 – Relação entre versão do Android em aparelhos em uso
Fonte: (Android Developers, 2013).
2.3 A MÁQUINA VIRTUAL DALVIK
A Dalvik é uma máquina virtual especialmente projetada para a plataforma
Android. Ela foi desenvolvida por Dan Borntein em parceria com a equipe do
Google. Embora seja possível desenvolver aplicativos para o Android em
22
qualquer linguagem que compile para o Java bytecode, a linguagem
predominante é Java. Vale lembrar que a Dalvik Virtual Machine (DVM) utiliza
uma implementação limitada das bibliotecas padrões do Java.
Ao contrário da Java Virtual Machine (JVM), a Dalvik foi projetada para
dispositivos móveis, assim, restrições como memória e duração da bateria,
fizeram parte de sua arquitetura desde o início.
Um outro motivo para o desenvolvimento da Dalvik foi o fato de que, ao
contrário da linguagem Java e de suas bibliotecas, a própria JVM não é livre. A
título de curiosidade: existem algumas iniciativas opensource como o openJDK
e o Apache Harmony. Assim, com uma VM livre, os fabricantes de hardware se
sentiriam mais seguros em adotar a plataforma, pois não teriam que se
preocupar com licenças. (Learning Android, 2011)
2.3.1 Comparação entre a Sun JVM e a Dalvik VM
Em Java o processo segue a seguinte ordem: o arquivo contendo o código
fonte é escrito, depois ele é compilado gerando o arquivo “.class” contendo os
bytecodes (linguagem compreendida pela JVM) e então o código é interpretado
pela JVM. No caso da Dalvik existe uma etapa a mais após a compilação do
arquivo contendo o código fonte em .class. Esse .class sofre uma nova
compilação pelo Dalvik Compiler para gerar o arquivo “.dex” que contém os
bytecodes interpretados pela Dalvik VM. A figura 4 diagrama as fases
envolvidas no processo de compilação pela JVM e pela Dalvik VM (Learning
Android, 2011).
23
Figura 4 - Java vs Dalvik
Fonte: (Learning Android, 2011).
O porquê de não compilar diretamente o código fonte para o Dalvik bytecode
está no fato de que, quando o desenvolvimento da Dalvik começou, a
linguagem Java ainda sofria muitas mudanças, mas os bytecodes da JVM não,
por isso a equipe da Dalvik achou melhor basear-se nos bytecodes ao invés de
a própria linguagem Java. Assim, é possível escrever apps para o Android em
qualquer linguagem que compilada para os bytecodes da JVM.
Outra particularidade da DVM é o sistema de coleta de lixo (Garbage Collection
- GC). Para cada aplicativo é criada uma nova instancia da Dalvik VM, ela é
otimizada para esse comportamento, e o sistema de GC também. E para evitar
que um processo de GC limpe um objeto compartilhado em memória são
utilizados bits de marcação, que indicam que um objeto é alcançável por outro
processo e não deve ser excluído da memória (Bornstein, 2008).
2.3.2 O formato dex
O formato .dex ocupa cerca de metade do espaço em disco que um arquivo
.class, logo, esse formato é otimizado para lidar com a pouca memória dos
dispositivos móveis.
O arquivo .class, produto da compilação do código fonte, é compilado em um
.dex pela ferramenta dx (Ehringer, 2008).
24
Tabela 3 – Comparação entre os tamanhos dos arquivos JAR e DEX
Código Arquivo Jar sem Compressão(bytes)
Arquivo Jar com Compressão
Arquivo DEX sem compressão
Bibliotecas do Sistema
21,445,320 (100%) 10,662,048 (50%) 10,311,972 (48%)
App de navegador web
470,312 (100%) 232,065 (49%) 209,248 (44%)
App de alarme relógio
119,200 (100%) 61,658 (52%) 53,020 (44%)
Fonte: (Ehringer, 2008).
A formato “.dex” usa um pool de constantes de tipo específico como
mecanismo primário para conservar memória. Ao invés de salvar essas
constantes no arquivo class, elas são buscadas no pool de constantes
referenciada pelo seu índice no mesmo. Assim as duplicações existentes no
.class são eliminadas no .dex (Ehringer, 2008, tradução nossa).
2.4 ANDROID SOFTWARE DEVELOPMENT KIT
O Android Software Development Kit (SDK) é um conjunto de ferramentas
utilizadas no desenvolvimento de aplicativos para a plataforma. A cada nova
versão do sistema Android lançada, um no conjunto de ferramentas (API Level)
é disponibilizado aos desenvolvedores para que eles possam utilizar os novos
recursos que são implementados. A tabela 4 mostra a versão do Android alvo
da API Level e o seu ano de lançamento:
Tabela 4 – Data de disponibilização do Android SDK
Plataforma Android API Level Data de Lançamento
4.4 19 31 de Outubro de 2013
4.3.1 18 24 de Julho de 2013
4.2.2 17 11 de Fevereiro de 2013
4.1.2 16 9 de Outubro de 2012
4.0.4 15 29 de Março de 2012
Fonte: (Learning Android, 2011).
No caso do Android, os apps são disponibilizados através do Google Play (visto
em sessão posterior), onde são validados. É possível habilitar o Android para
que seja possível instalar apps de outras fontes mas um aviso de segurança
será exibido para alertar o usuário sobre os riscos.
25
2.4.1 Android NDK
A maioria do apps para Android é escrita na linguagem Java e posteriormente
executada na máquina virtual Dalvik. Porém, há casos em que, por questões
de performance, a aplicação teria um desempenho melhor se partes dela fosse
escrita em uma linguagem compilada diretamente para código nativo. Para
esses casos existe o NDK (Native Code Development). O NDK permite aos
desenvolvedores escrever código em C/C++ que, dependendo da tarefa
executada, pode resultar em ganho de performance como nos casos do uso
intensivo da CPU para cálculos, processamento de sinal e simulação de física
(Android Developers, 2013).
O NDK surgiu em Junho de 2009 e teve cinco revisões até seu lançamento em
Novembro de 2010. Hoje, o NDK suporta as arquiteturas ARMv5TE e ARMv7-A
e futuramente, através de uma parceria entre Google e Intel, suportará a
arquitetura x86 da Intel. Um ponto importante é que não é possível criar
aplicações completas com o NDK, apenas módulos que serão chamados pela
aplicação principal que é executada na Dalvik VM. Seu uso é restrito a otimizar
algumas partes da aplicação, inclusive, os módulos escrito em C/C++ usando o
NDK, são empacotados com o resto da aplicação no arquivo apk (Learning
Android, 2011).
Do ponto de vista da forense e da segurança, a ferramenta de cross-compiling
(compilar um código em uma plataforma tendo como alvo outra) é um
importante ponto de estudo, uma vez que seus componentes podem ser
reutilizados. Por exemplo, na versão 1.5 do Android, o root exploit utilizava um
bug no kernel do Linux para ganhar privilégios de super usuário. Este era
distribuído como código fonte e requeria cross-compiling (Android Forensics,
2011).
2.4.2 Android Virtual Devices (AVD)
Junto com o SDK do Android existe um emulador da plataforma, com ele é
possível criar VM de versões diferentes do Android e observar o
comportamento de uma aplicação em cada uma delas.
26
Antes de criar as VM Android para cada versão do SO é preciso fazer o
download de cada versão da API. Isso é feito no SDK Manager que faz parte
do SDK. Nele são assinaladas as versões do Android com as quais se deseja
trabalhar.
Este emulador tem grande importância para os desenvolvedores que precisam
validar suas aplicações com versões específicas do sistema, mas também tem
grande valor para a investigação forense no que tange personalizar como a
aplicação executará no sistema.
Figura 5 – AVD em execução Fonte: O Autor (utilizando o AVD versão para Windows).
Quando um AVD é executado, os arquivos criados por ela são de grande valor
para a perícia forense e para a área de pesquisa de segurança. Os arquivos
referentes ao armazenamento interno e SD Card são criados no diretório do
usuário.
27
Tabela 5 – Localização dos arquivos criados pelo AVD
Sistema Operacional
Diretório da AVD
Ubuntu Linux /Users/<username>/.android
Windows 7 C:\Users\<username>\.android\avd\android422.avd
A estrutura criada pelo AVD é como a seguir:
Figura 6 – Estrutura de diretórios criados pelo AVD Fonte: O Autor (utilizando o prompt de comando do Windows 7).
Os arquivos que interessam a forense são:
sdcard: imagem do cartão SD (se criado durante a configuração do
AVD)
userdata.img: imagem da partição /data
cache.img: imagem da partição /cache
As partições representadas pelo cache.img e userdata.img são do formato
YAFFS2 que ainda não é suportado pelas ferramentas de analise forense. O
C:. | adbkey | adbkey.pub | adb_usb.ini | androidtool.cfg | androidwin.cfg | ddms.cfg | default.keyset | modem-nv-ram-5554 | repositories.cfg | sites-settings.cfg | +---avd | | Android-422.ini | | | \---Android-422.avd | cache.img | config.ini | emulator-user.ini | hardware-qemu.ini | sdcard.img | userdata-qemu.img | userdata.img | \---cache sdkbin-1_0873bf78-repository-8_xml sdkbin-1_172100de-addons_list-2_xml sdkbin-1_2bfc99d2-sys-img_xml sdkbin-1_9c35fc9e-addon_xml sdkbin-1_e9f1c86d-sys-img_xml sdkbin-1_f30bfa4f-addon_xml sdkbin-1_f9d1c322-sys-img_xml sdkinf-1_0873bf78-repository-8_xml sdkinf-1_172100de-addons_list-2_xml sdkinf-1_2bfc99d2-sys-img_xml sdkinf-1_9c35fc9e-addon_xml sdkinf-1_e9f1c86d-sys-img_xml sdkinf-1_f30bfa4f-addon_xml sdkinf-1_f9d1c322-sys-img_xml
28
sdcard utiliza o formato FAT32 no qual as ferramentas de forense trabalham
muito bem.
É possível aprender muito sobre o SO com a ajuda de um AVD. Como
examinar as conexões de rede, sistema de arquivos e outros artefatos (Android
Forensics, 2011).
2.4.3 Android Debug Bridge - ADB Tools
Uma ferramenta extremamente útil para uma perícia em dispositivos com
Android é o ADB (Android Debug Bridge) Tools. Através dela é possível se
comunicar, controlar e acessar a memória interna de um dispositivo Android e,
se o modo root estiver disponível além de ver as informações salvas pelos
aplicativos no diretório /data/data, que por padrão não estão acessíveis(Android
Developers, 2013).
No Ubuntu 13.04, a ferramenta pode ser instalada com o comando:
Figura 7 – Instalação do Android ADB Tools Fonte: O Autor.
O ADB é composto de três componentes:
Cliente: serviço ADB cliente em execução na estação que tentará a
comunicação com o Android.
Servidor: serviço ADBD (Android Debug Bridge Daemon) em execução
também na estação que tentará a comunicação com o Android.
Serviço (daemon): serviço ADBD em execução no dispositivo Android.
Como descrito acima, o serviço ADBD precisa estar em execução no
dispositivo Android, a figura 8 mostra como é feita a inicialização (Android
Developers, 2013):
sudo apt-get install android-tools-adb
29
Figura 8 – Ativação do modo de depuração no Android Fonte: O Autor (utilizando o AVD versão para Windows).
O primeiro comando após conectar o dispositivo Android ao computador via
cabo USB é o ADB devices. Esse comando lista todos os dispositivos
conectados ao PC.
Figura 9 – Comando adb devices Fonte: O Autor.
A saída do comando acima mostra os identificadores dos dispositivos
conectados no momento.
Para navegar pela estrutura de diretórios da memória interna é utilizado o
comando adb shell. Que permite abrir uma shell no dispositivo Android e
interagir com ele, segue exemplo de sua utilização (Android Forensics, 2011):
luffy@ubuntu:~$ adb devices List of devices attached 7DF600229FFC0000016395910A01600F device
30
Figura 10 – Comando adb shell Fonte: O Autor.
As funcionalidades do ADB evoluem a cada versão do Android, algumas delas
são apresentadas neste capítulo.
2.5 SISTEMAS DE ARQUIVOS
As informações que podem ser recuperadas do Android são uma combinação
dos já conhecidos artefatos encontrados no Linux mais outros novos como os
apps que executam sobre a Dalvik VM e o sistema de arquivos YAFFS2 (Yet
Another Flash File System). Nisso, a variedade de informações que são
armazenadas diretamente pelo usuário do dispositivo móvel, ou pelos apps que
executam no sistema é enorme. Exemplos desses dados são: Mensagens de
texto (SMS/MMS), Contatos telefônicos, Logs de chamadas telefônicas,
mensagens de e-mail (Gmail, Yahoo, Exchange), Mensagens instantâneas
(Whats app, Facebook Messenger), fotos, vídeos, histórico de navegação,
coordenadas GPS, histórico de buscas, rotas de direção, arquivos diversos,
músicas, eventos de calendário, informações financeiras, informações pessoais
salvas por clientes de redes sociais(Facebook, Twitter) e etc (Android
Forensics, 2011).
2.5.1 FAT32
O formato FAT32, muito conhecido pelas partições dos sistemas da Microsoft,
é utilizado como sistemas de arquivos no Android para os seus cartões de
memória e eMMC (MultiMediaCard). Existem algumas razões para o sistema
de arquivos da partição do usuário ser diferente da utilizada pelo Android, uma
delas é a compatibilidade com outros sistemas operacionais. Sistemas
luffy@ubuntu:~$ adb shell shell@android:/ $ ll drwxr-xr-x root root 2013-10-13 13:50 acct drwxr-xr-x root root 1969-12-31 21:00 bootimages drwxrwx--- system cache 2013-10-13 14:53 cache drwxr-xr-x root root 1969-12-31 21:00 chargerimages dr-x------ root root 2013-10-13 13:50 config lrwxrwxrwx root root 2013-10-13 13:50 d -> /sys/kernel/debug drwxrwx--x system system 2013-10-13 20:28 data -rw-r--r-- root root 121 1969-12-31 21:00 default.prop drwxr-xr-x root root 2013-10-13 13:50 dev drwxrwx--- drm system 2013-10-13 13:50 drm drwxrwx--x system system 2013-10-13 13:50 dvp lrwxrwxrwx root root 2013-10-13 13:50 etc -> /system/etc -rwxr-x--- root root 125024 1969-12-31 21:00 init -rwxr-x--- root root 39349 1969-12-31 21:00 init.blackg.rc -rwxr-x--- root root 10031 1969-12-31 21:00 init.blackg.usb.rc
31
Windows da Microsoft, distribuições Linux e o MAC OS X trabalham bem com
esse sistema de arquivos (Android Forensics, 2011).
No Linux partições FAT32 são chamadas de VFAT e se tratando do Android
existem três lugares que usam esse sistema de arquivos (Android Forensics,
2011):
/mnt/sdcard
/mnt/secure/asec
/mnt/emmc
A partição /mnt/secure/asec é criptografada pois nela podem ser gravados os
apps do sistema. Quando a funcionalidade de armazenar um app no SDCard
foi introduzida ao Android adotaram esta solução de encriptação porque as
permissões dos arquivos não são mantidas no FAT32, e isso implica na
possibilidade de acessar os dados da aplicação (Android Forensics, 2011).
A partição SDCard é a partição do usuário. Contém geralmente fotos, vídeos,
arquivos baixados, arquivos temporários e dados de navegação do Google
Maps.
A partição /mnt/emmc é uma parte da memória interna formatada com o
sistema de arquivos FAT32. Alguns dispositivos não tem suporte a cartões de
memória, como o Google Nexus 4 por exemplo. Então contam com uma
memória interna de maior capacidade e a dividem entre sistema operacional,
aplicativos e dados do usuário.
2.5.2 YAFFS2
O YAFFS2 (Yet Another Flash File System) é um sistema de arquivos
opensource desenvolvido especialmente para memórias flash NAND licenciado
sob a GPL (GNU Plublic License). Sendo um sistema desenvolvido para
memórias flash, algumas das importantes características que o YAFFS2 possui
são (Android Forensics, 2011):
Sistema de arquivos de log estruturado (prevenção contra interrupção de
energia)
32
Correção de erros
Capacidade para lidar com setores defeituosos
Rápido e utiliza pouco da memória RAM
Como o seu uso é limitado ao SO Android, não existem ferramentas
(comerciais ou opensource) que suportem esse sistema de arquivos.
Uma particularidade das memórias do tipo NAND flash é que, quando um
arquivo é atualizado sua versão anterior não é imediatamente apagada porque
a memória não permite reescrita (primeiro é preciso apagar todos os blocos de
memória – como num processo de preparação), assim, enquanto não for
executado o garbage collector, o arquivo permanecerá num diretório oculto e
será possível recuperá-lo, apenas não será apresentado pelo sistema (Android
Forensics, 2011).
2.5.3 Partições do Sistema de Arquivos
O sistema de arquivos do Android é dividido em três partes principais:
A partição do sistema /system/: onde ficam as aplicações pré-
instaladas, bibliotecas, Linux kernel, Android framework e etc.
A partição SDCard /sdcard/: que é uma partição livre, onde todos os
aplicativos podem gravar dados e ler dela, bastando ter a permissão
WRITE_TO_EXTERNAL_STORANGE.
A partição de dados do usuário /data/: onde podem estar aplicações,
arquivos do usuário como músicas, vídeos e documentos. Para um
perito, um dos diretórios mais importantes desta partição é o
(/data/data/), onde ficam as bases de dados das aplicações. Neste
diretório as aplicações são separadas pelo nome do pacote e passam
ter a estrutura descrita na tabela abaixo (Learning Android, 2011):
33
Tabela 6 – Estrutura do diretório /data/data/<ApplicationPackageName>
Nome do diretório Descrição do conteúdo
shared_prefs Dados compartilhados da aplicação
lib Bibliotecas requeridas pela aplicação
files Arquivos salvos pelo desenvolvedor
cache Arquivos de cache da aplicação. Como os utilizados
pelos navegadores web
databases Banco de dados SQLite
Fonte: (Android Forensics, 2011).
Na tabela 6 estão listados os diretórios principais que todo App passa a ter
após a sua instalação.
2.5.4 Formas de Persistência de Dados
O Android provê aos desenvolvedores cinco formas de armazenar informação:
Preferencias compartilhadas
Armazenamento interno
Armazenamento externo
SQLite
Network
Preferencia Compartilhadas permitem o desenvolvedor armazenar um par
chave-valor de tipos primitivos (boolean, float, int, long e cadeias de caracteres
- strings) em um formato simplificado do XML (Android Forensics, 2011).
Figura 11 – Listagem do diretório shared_prefs do aplicativo Phone Fonte: O Autor (utilizando o Android ABD Tools para Linux Ubuntu).
A figura 11 mostra a listagem do diretório shared_prefs do app Phone, nativo
do próprio Android. Nos arquivos XML é possível ver o sistema de chave-valor
adotado:
shell@android:/ # ll /data/data/com.android.phone/shared_prefs/ -rw-rw---- radio radio 139 2013-10-12 09:26 PrefCallDuration.xml -rw-rw---- radio radio 126 2013-10-11 20:36 _has_set_default_values.xml -rw-rw---- radio radio 135 2013-10-11 20:36 com.android.phone_preferences.xml -rw-rw---- radio radio 827 2013-10-11 20:36 featureset.xml -rw-rw---- radio radio 230 2013-10-11 20:37 siminfo.xml -rw-rw---- radio radio 482 2013-10-11 20:37 telephony.xml
34
Figura 12 – Arquivo XML do tipo chave-valor Fonte: O Autor.
O Armazenamento Interno é feito no subdiretório de cada app na partição
/data/data e nele pode ser salvo arquivo de qualquer tipo. Por questões de
segurança, abordada em um capítulo posterior, o Android, por padrão, apenas
permite que a própria aplicação acesse seus dados, a seguir uma amostra dos
primeiros resultados da listagem deste diretório em um LG Optimus Black
(P970) (Android Forensics, 2011):
Figura 13 – Listagem do diretório data/data Fonte: O Autor (utilizando o Android ABD Tools para Linux Ubuntu).
O Armazenamento Externo trata dos dados que são salvos no SD Card do
dispositivo móvel. Por se tratar de um cartão removível, as restrições de
segurança são menos severas, por padrão, não é preciso permissão para
acessar os arquivos do cartão de memória. O formato do sistema de arquivos é
o FAT32 por ser um sistema já bastante difundido e facilitar a transferência de
dados do cartão para outro meio ou dispositivo (Android Forensics, 2011).
Além das informações salvas pelo próprio desenvolvedor do app, o Kernel do
Linux e o Android armazenam um registro de logs das atividades das
aplicações e do próprio sistema operacional (Android Forensics, 2011).
O SQLite é uma forma de fazer consultas a dados utilizando a linguagem SQL
mas em um arquivo local. Toda a base SQLite é tratada como um único
arquivo. Ele é de grande utilidade para os desenvolvedores de aplicativos
armazenarem informações de maneira estruturada localmente sem precisar
shell@android:/ # android.phone_preferences.xml < <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="sim_iccid_value_key">89550311000182749434</string> </map> android.phone_preferences.xml < <?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <string name="sim_iccid_value_key">89550311000182749434</string> </map>
shell@android:/ # ll /data/data/ drwxr-x--x app_87 app_87 2013-10-12 02:09 br.com.jr3 drwxr-x--x app_88 app_88 2013-10-12 02:09 ch.smalltech.ledflashlight.free drwxr-x--x app_76 app_76 2013-10-12 01:54 com.adobe.reader drwxr-x--x app_36 app_36 2013-10-11 20:36 com.android.LGSetupWizard drwxr-x--x app_4 app_4 2013-10-11 20:35 com.android.backupconfirm drwxr-x--x app_5 app_5 2013-10-13 00:34 com.android.bluetooth drwxr-x--x app_27 app_27 2013-10-11 20:37 com.android.browser drwxr-x--x app_7 app_7 2013-10-11 20:35 com.android.calculator2 drwxr-x--x app_9 app_9 2013-10-11 20:37 com.android.calendar drwxr-x--x app_28 app_28 2013-10-11 20:37 com.android.cellbroadcastreceiver drwxr-x--x app_11 app_11 2013-10-11 20:35 com.android.certinstaller drwxr-x--x app_12 app_12 2013-10-11 20:37 com.android.chrome drwxr-x--x app_2 app_2 2013-10-11 20:37 com.android.contacts drwxr-x--x app_13 app_13 2013-10-11 20:37 com.android.defcontainer
35
recorrer aos tradicionais RDBMS. Em geral, os bancos SQLite são
armazenados no diretório do aplicativo que o utiliza /data/data/<app name>,
mas não existe ,de fato, uma restrição que obrigue o desenvolvedor a cria-lo
neste local (Android Forensics, 2011).
Poucos apps utilizam este recurso, mas Armazenamento na Rede (Network)
está disponível via API do SDK do Android. Se uma conexão com a internet
está disponível, o app pode armazenar seus dados em um serviço web (SQLite
Documentation, 2013).
Em termos de desenvolvimento, para adicionar a capacidade de comunicação
a uma rede ao aplicativo Android, o desenvolvedor de fazer uso das classes
dos pacotes seguir:
java.net.*
android.net.*
Como referenciado na documentação, esses pacotes oferecem API de baixo
nível para interagir com redes, web services e outros (Android Forensics,
2011).
2.6 LOGS DO SISTEMA E DAS APLICAÇÕES
Arquivos de logs e depuração são dois métodos muito utilizados por
desenvolvedores para manter o controle de suas aplicações e tornar sua
manutenção mais efetiva. Os arquivos de logs guardam informações sobre as
atividades das aplicações enquanto executam e, embora nem sempre, é
possível extrair informações muito uteis destes arquivos. Para analista forenses
e especialistas em segurança é possível obter informações importantes de um
dispositivo Android, analisando os arquivos de logs e depuração dos aplicativos
e do próprio sistema (Android Forensics, 2011).
2.6.1 Log do Kernel do Linux
O Kernel do Linux controla todo o hardware e software de um computador,
alocando memória quando necessário e executando aplicativos quando
solicitado. Também é função do Kernel prover uma API de baixo nível para o
36
acesso ao hardware de um computador pelas aplicações do sistema. As quatro
responsabilidades primárias do Kernel Linux são (Linux Command Line and
Shell Script Bible, 2008):
Gerenciar a memoria do sistema
Gerenciar as aplicações do sistema
Gerenciar o hardware do dispositivo
Gerenciar o sistema de arquivos
Sendo o Kernel o centro de todas as atividades de um dispositivo, sua
capacidade de registrar eventos chaves é altamente desenvolvida. Os logs do
Kernel são acessíveis em um sistema Linux e também no Android pelo
comando dmesg. A seguir uma amostra das atividades registrada em log pelo
Kernel do Linux (Android Forensics, 2011):
Figura 14 – Saída do comando dmesg Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
Como pode ser visto na figura 14, as informações registradas no LG Optimus
Black (P970) são bastante detalhadas e de baixo nível, como a capacidade
momentânea da bateria.
127|shell@android:/ # dmesg 0:42.960] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <4>[13:10:13 13:50:42.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <6>[13:10:13 13:50:42.976] voice_configure_path(at twl4030).....path = 0, cur_twl_mode = 0 <4>[13:10:13 13:50:42.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <4>[13:10:13 13:50:42.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <4>[13:10:13 13:50:44.546] STA connect received 1 <4>[13:10:13 13:50:45.992] [BATTERY] +++ vol:4028, chr:1, muic:8, temp:280, cap:85 <4>[13:10:13 13:50:45.992] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:45.992] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:45.992] [BATTERY] +++ vol:4028, chr:1, muic:8, temp:279, cap:85 <4>[13:10:13 13:50:46.000] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:46.140] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:47.976] [wm9093.c] func:[wm9093_configure_path()], line:(1249), mode( 0) <7>[13:10:13 13:50:52.039] wlan0: no IPv6 routers present <4>[13:10:13 13:50:56.025] [BATTERY] +++ vol:4033, chr:1, muic:8, temp:281, cap:85 <4>[13:10:13 13:50:56.025] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:56.025] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:56.025] [BATTERY] +++ vol:4033, chr:1, muic:8, temp:281, cap:85 <4>[13:10:13 13:50:56.033] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:56.049] [BATTER] cap:85 , muic:8 <4>[13:10:13 13:50:58.150] [bd2802_store_led_onoff] value = 0 <4>[13:10:13 13:50:58.158] LED OFF
37
logcat
Uma ferramenta bastante útil para análise das atividades do Android é logcat.
Com ela é possível visualizar os logs de atividades num fluxo constante, uma
pequena amostra das informações providas pela ferramenta pode ser vista a
seguir (Android Forensics, 2011):
Figura 15 – Saída do comando logcat Fonte: (Android Forensics, 2011).
Nesta saída, exibida na figura 15, é possível obter informações como longitude
e latitude, informações de data e hora e detalhes dos apps em execução. Cada
linha de log começa com uma letra que descreve seu nível. A tabela abaixo
mostra a relação entre as letras e os níveis de log:
Tabela 7 – Níveis de log
Nível de Log Descrição
V Verboso
D Debug
I Informação
W Aviso
E Erro
F Fatal
S Silent Fonte (Android Forensics, 2011).
A ferramenta logcat também suporta alguns parâmetros de linha de comando
que filtram e auxiliam a obtenção de logs específicos. O parâmetro –b, por
exemplo, faz a filtragem do log principal de acordo com o filtro passado depois
dele. É possível utilizar outros filtros ou mesmo fazer um dump do arquivo de
log naquele momento. A tabela 8 mostra os comandos e opções que podem
ser utilizados com o logcat:
ahoog@ubuntu:~$ adb shell logcat I/HtcLocationService( 308): agent - search location by name: oak park, country: united states, state: illinois I/HtcLocationService( 308): agent - no location was found, total: 0 D/AutoSetting( 308): service - CALLBACK - onGetTimeZoneOffset, result: failed, zoneId: , offset: 0 D/LocationManager( 308): removeUpdates: listener = com.htc.htclocationservice.HtcLocationServiceAgent$7@45dfc770 V/AlarmManager( 97): Adding Alarm{463aea28 type 2 com.google.android.location} Jan 05 05:05:25 pm I/HtcLocationService( 308): agent - send current location notify intent, name: Oak Park, state: Illinois, country: United States, lat: 41.8786, lng: -87.6359,tzid:
38
Tabela 8 – Opções de comando de linha do logcat
Opção Descrição
-b <buffer Carrega um buffer alternativo para visualização de logs de evento e radio.
-c Limpa e descarrega todo o log.
-d Faz o dump do log no instante atual
-f <filename> Escreve a saída do log no arquivo passado como parâmetro. O padrão é o prompt
-g Imprime o tamanho do log
-n <count> Configura o número máximo de mudança do log.
-r <kbytes> Muda o buffer de log a cada <kbytes>
-s Configura o filtro padrão para silente
-v <format> Configura o formato da saída do log. O padrão é o formato brief.
Fonte: (Android Developers, 2013).
Combinado o logcat com os comandos da tabela acima pode fornecer
informações importantes como:
Momento de ocorrência dos eventos
Endereço IP do celular, rede e informações de localização
Tipo de encode utilizado nas mensagens SMS
dumpsys
Outra ferramenta de análise de logs é a dumpsys. Com ela é possível obter
informações a cerca de serviços em execução, utilização da memória e outros
detalhes do sistema. A figura 16 mostra a saída (editada por questões de
espaço) do comando dumpsys executada em um LG Optimus Black (P970)
com a versão 4.0.4 do Android (Android Forensics, 2011):
39
Figura 16 – Saída do comando dumpsys Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
A saída de log acima revela informações importantes como:
Serviços em execução
Dump de cada serviço
Informações como memoria, ID e database de cada processo
O que é útil para determinar não apenas qual serviço está executando mas
também qual database ele usa.
dumpstate
O comando de debug dumpstate combina partes dos comandos apresentados
com informações do sistema. A sintaxe e a saída (editada por questões de
espaço) do comando executado em um LG Optimus Black (P970) com a
versão 4.0.4 do Android são apresentadas na figura 17:
luffy@ubuntu:~$ adb shell dumpsys Currently running services: Bridges SUPL_SERVICE SurfaceFlinger WifiExtHMService accessibility account ------------------------------------------------------------------------------- DUMP OF SERVICE accessibility: ------------------------------------------------------------------------------- DUMP OF SERVICE account: Accounts: 4 Account {name=Phone, type=com.lge.sync} Account {[email protected], type=com.facebook.auth.login} Account {[email protected], type=com.dropbox.android.account} Account {[email protected], type=com.google} Active Sessions: 0 ** MEMINFO in pid 1716 [com.gtp.nextlauncher.liverpaper.honeycomb] ** Shared Private Heap Heap Heap Pss Dirty Dirty Size Alloc Free ------ ------ ------ ------ ------ ------ Native 1900 1296 1852 16812 14599 248 Dalvik 2758 11460 2364 13447 10078 3369 Cursor 0 0 0 Ashmem 2 4 0 Other dev 10321 376 780 .so mmap 670 2148 416 .jar mmap 0 0 0 .apk mmap 0 0 0 .ttf mmap 0 0 0 .dex mmap 176 0 0 Other mmap 221 8 28 Unknown 6758 4532 6604 TOTAL 22806 19824 12044 30259 24677 3617
40
Figura 17 – Saída do comando dumpstate Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
O comando precisa ser executado ser executado como root, caso contrário
não mostrará todas as saídas possíveis. A saída do comando é dividida em
várias sessões, como registro de atividades das aplicações, informações sobre
o dispositivo, rede, kernel e outros.
2.6.2 Logs dos Apps
Além dos logs gerados pelo Kernel do Linux e pelo próprio Android, os
desenvolvedores de aplicativos também costumam adicionar a suas aplicações
a capacidade de gerar os seus próprios arquivos de logs. Esses arquivos são
bastante úteis quando há necessidade de obter informações sobre um app
específico.
Um dos serviços de armazenamento de dados em uma plataforma de Cloud
Computing mais utilizados é Dropbox. A estrutura de seu diretório é
apresentada na figura 18:
shell@android:/ # dumpstate ======================================================== == dumpstate: 2013-10-13 20:45:20 ======================================================== Build: IMM76L.P970h30a-SCA-XXX.4DAB73BC Bootloader: unknown Radio: unknown Network: TIM 11 Kernel: Linux version 3.0.8 (elisandro.vidotto@openos-ubuntu) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 PREEMPT Fri Mar 8 19:45:35 BRT 2013 Command line: rs=s mem=512M init=/init videoout=omap24xxvout omap_vout.video1_numbuffers=6 omap_vout.vid1_static_vrfb_alloc=y vram=16M omapfb.vram=0:5M lpj=2334720 fuelgauge=g androidboot.hardware=blackg muic_state=0 thermal_fakemode=0 CRC=0x8dd118f7 ------ UPTIME (uptime) ------ up time: 06:55:22, idle time: 06:25:10, sleep time: 00:00:00 [uptime: 0.1s elapsed] ------ MEMORY INFO (/proc/meminfo) ------ MemTotal: 447856 kB MemFree: 11760 kB Buffers: 2372 kB Cached: 60876 kB SwapCached: 0 kB Active: 317140 kB Inactive: 32636 kB Active(anon): 289284 kB Inactive(anon): 360 kB Active(file): 27856 kB Inactive(file): 32276 kB ------ CPU INFO (top -n 1 -d 1 -m 30 -t) ------
41
Figura 18 – Listagem do diretório do app Dropbox Fonte: (Android Forensics, 2011).
É possível ver a existência do arquivo log.txt abaixo do diretório files.
Visualizando o conteúdo do arquivo tem-se:
Figura 19 – Visualização do arquivo de logs do app Dropbox Fonte: (Android Forensics, 2011).
A partir do seu conteúdo é possível concluir que houve uma tentativa bem
sucedida de autenticação e pelo resto do log (não mostrado acima), é possível
ver que o serviço foi interrompido por uma chamada telefônica (Android
Forensics, 2011).
2.7 GOOGLE PLAY
O Google Play nasceu da unificação entre Google Music, Google Books Store
e o Android Marketplace. Este último, tinha o objetivo de prover um canal
seguro para os usuários do sistema instalarem seus aplicativos (Learning
Android, 2011).
O Google Play (Android Marketplace) em si é um aplicativo. Por ele é possível
obter informações e atualizações dos aplicativos. O Google tornou o processo
de publicação de apps bastante simples. Para disponibilizar um aplicativo no
Google Play, sendo uma empresa ou desenvolvedor autônomo, é preciso: criar
uma conta de desenvolvedor no Google, pagar uma taxa e concordar com os
termos de serviço (Hashimi, Komatineni, 2010).
ahoog@ubuntu:~/htc-inc/data/data$ tree com.dropbox.android/ com.dropbox.android/ ├── databases │ └── db.db ├── files │ └── log.txt ├── lib └── shared_prefs └── DropboxAccountPrefs.xml
ahoog@ubuntu:~/com.dropbox.android$ cat ./files/log.txt 5 1296055108427 com.dropbox.android.provider.DatabaseHelper Creating new Dropbox database. 4 1296055108459 com.dropbox.android.DropboxApplication Not authenticated, so authenticating 4 1296055108466 com.dropbox.android.DropboxApplication No stored login token. 4 1296055108702 com.dropbox.android.DropboxApplication Not authenticated, so authenticating 4 1296055108704 com.dropbox.android.DropboxApplication No stored login token. 4 1296055108704 com.dropbox.android.activity.SimpleDropboxBrowser Didn't authenticate, redirecting to login 4 1296055108713 com.dropbox.android.DropboxApplication Not authenticated, so authenticating 4 1296055108714 com.dropbox.android.DropboxApplication No stored login token. 4 1296055134550 com.dropbox.android.DropboxApplication Authenticating username: [email protected] 4 1296055136507 com.dropbox.android.DropboxApplication Successfully authenticated 6 1296055137501 com.dropbox.android.activity.LoginActivity Dismissed nonexistent dialog box 4 1296055137525 com.dropbox.android.activity.LoginOrNewAcctActivity Successful account login 4 1296055137549 com.dropbox.android.activity.delegate.MenuDelegate Successful Login
42
CAPÍTULO 3. SEGURANÇA NO SISTEMA OPERACIONAL ANDROID
3.1 INTRODUÇÃO
Nas iterações entre aplicações clientes e servidoras a segurança não fica
restrita apenas a rede como configuração de firewall, detecção de intrusos,
antivírus e outros. Os desenvolvedores de aplicativos também devem tomar
todas as medidas para tornar os seus aplicativos seguros na transmissão e
armazenamento local de informações de seus usuários (Applications Security
for the Android Platform Processes, 2012).
A arquitetura do Android já promove um modelo de segurança mais forte do
que o convencional (que atribui a aplicação o mesmo nível de acesso do
usuário que a instalou) e, no campo da análise forense, conhecer os
mecanismos de segurança existentes e os que precisam ser implementados,
bem como os métodos para “burlar” esses bloqueios são de grande
importância para a obtenção de dados e posterior análise.
3.2 PERMISSÃO POR APLICAÇÃO
Nos sistemas operacionais para desktops as aplicações executam sob a conta
do usuário que as iniciou, e recebe o mesmo nível de acesso daquela conta de
usuário. Outra característica é que todos os aplicativos executados por uma
conta de usuário tem o mesmo nível de acesso as APIs do sistema, assim um
editor de texto e um aplicativo de mensagens instantâneas terão o mesmo nível
de acesso a uma conexão internet porque executam sob o mesmo UID. Se o
usuário tem acesso total ao sistema, seus aplicativos também o terão. Esta é a
principal características dos SOs para desktops: aplicativos recebem o mesmo
nível de acesso ao sistema que o usuário que os executou (Applications
Security for the Android Platform Processes, 2012).
No Android, visando à segurança do usuário a modelo de permissões é
diferente. Antes de uma aplicação ser instalada é verificada a assinatura digital
do desenvolvedor que, diferente do SSL, não precisa de uma Autoridade
Certificadora, mas o desenvolvedor precisa manter a chave segura,
principalmente nos casos de apps bancários. Nesses casos, se chave fosse
publicada, um update do aplicativo, feito por uma pessoa mal intencionada e de
43
posse da chave, poderia comprometer os dados do usuário (Android
Forensics).
Em seguida, o arquivo .apk é validado e o arquivo que especifica quais os
acessos que aplicação precisa (contatos telefônicos, mensagens SMS,
conexão internet e outros) é verificado e apresentado ao usuário que deve
aprovar cada uma das solicitações, caso contrário o aplicativo não é instalado.
A diferença no modelo de segurança do Android está em que, após a
instalação do App, é atribuído um usuário e grupo Linux único para a aplicação
e esta executa em seu próprio processo e instância da Dalvik VM (que é
otimizada para este comportamento). Esse modelo assegura o não
compartilhamento de memória, permissões e dados gravados em disco. Assim,
as aplicações acessam apenas os dados e memória de sua própria Dalvik VM
(Android Forensics, 2011).
No caso de aplicações de um mesmo desenvolvedor que precisam
compartilhar informações (Facebook e Facebook Messenger, por exemplo)
este modelo pode ser alterado. O desenvolvedor pode assinar os dois
aplicativos com a mesma assinatura. Neste caso, o processo, a instância da
Dalvik VM, a memória e as informações salvas serão compartilhadas entre os
aplicativos (Android Forensics, 2011).
44
Figura 20 – Instalação dos Apps Google Maps e Gmail respectivamente Fonte: (Android Developers, 2013).
A vantagem do modelo de permissão do Android sobre os dektops fica
evidente no caso de um ataque a um app do sistema, pois nesse caso o
atacante apenas poderia fazer o que o app tem permissão para fazer, diferente
do caso de um ataque a um browser de um sistema desktop onde o atacante
teria todos os privilégios do usuário que iniciou o ataque (Applications Security
for the Android Platform Processes, 2012).
Claro, a maioria dos usuários não lê a requisição de acesso que app faz e
aprova tudo o que é pedido, ainda mais se for um jogo. Por isso grande parte
dos malwares existentes para Android se aproveitam deste ponto fraco, o
usuário, para conseguir diversas permissões.
Todas as permissões que uma aplicação precisa devem ser especificadas no
arquivo Manifest.xml. Por exemplo, uma aplicação que precise monitorar as
mensagens SMS recebidas o faria desta forma:
Figura 21 – Visualização da permissão de acesso no Manifest.xml Fonte: (Android Developers, 2013).
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app.myapp" > <uses-permission android:name="android.permission.RECEIVE_SMS" /> ... </manifest>
45
O Android possui uma série de Strings para permissões do sistema (todas
começam com android.permission, além das que podem ser criadas pelo
próprio desenvolvedor), no momento da instalação o arquivo Manifest.xml é
lido e uma lista de requisições é gerada e apresentada ao usuário, se o usuário
recusar uma, todo o processo de instalação falha (Android Developer, 2013).
O sistema de permissões do Android é dividido em quatro categorias
principais:
O grupo Normal compreende as permissões que não precisam da
intervenção do usuário para serem atribuídas ao app.
As do grupo Dangerous são as que representam algum tipo de risco ao
usuário e ao sistema em si, como acesso a internet e dados pessoais do
usuário. Estes permissões são explicitamente solicitadas ao usuário no
momento da instalação do app.
A categoria de permissão Signature é um modo de identificar o autor do
código, verificar se o app foi alterado e estabelecer a confiança entre os
aplicativos. Um certificado digital é gerado e o app é assinado com ele,
desta forma dois apps com o mesmo certificado digital podem
compartilhar informações de forma segura, e não há necessidade de
intervenção do usuário para autorizar o acesso de um app ao outro.
SignatureOrSystem que se diferencia da Signature pela permissão ser
adicionada ao Android. Este modo é utilizado por fabricantes para
permitir que apps desenvolvidos por diferentes empresas trabalhem em
conjunto com o fabricante. Este tipo de permissão não é recomendada
(Applications Security for the Android Platform Processes, 2011).
Caso um app forneça algum tipo de serviço a outros apps e o desenvolvedor
deseje restringir o acesso e este serviço, ele precisa declara esta permissão no
Manifest.xml desta forma:
46
Figura 22 – Restrição de acesso no Manifest.xml Fonte: (Android Developers, 2013).
O bloco de XML acima define a permissão DEADLY_ACTIVITY como
pertencente ao pacote com.me.app.myapp.permission. O atributo
protectionLevel foi configurado como DANGEROUS que é o tipo de permissão
apropriada (Application Security for the Android Platform Processes, 2012).
O resultado de todas essas barreiras é que o Android possui um sistema
seguro para isolar as informações de seus aplicativos e não há uma maneira
simples para os analistas forenses extraírem as informações (Android
Forensics, 2011).
Por ultimo, os usuários do Android tem a opção de instalar apps de fontes que
não o Google Play. Essa opção pode ser acessada pelo menu de opções da
aplicação nas configurações do sistema (Android Forensics, 2011).
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" > <permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY" android:label="@string/permlab_deadlyActivity" android:description="@string/permdesc_deadlyActivity" android:permissionGroup="android.permission-group.COST_MONEY" android:protectionLevel="dangerous" /> ... </manifest>
47
Figura 23 – Aviso do Android sobre fontes desconhecidas Fonte: O Autor (utilizando o AVD versão para Windows).
Após assinalar a opção para permitir a instalação de apps de outras fontes, o
Android exibe um aviso sobre os riscos envolvidos na operação como na figura
anterior. Instalar Apps de uma fonte que não seja o Google Play faz com que o
Android pule a etapa de validação da assinatura digital (Android Forensics,
2011).
3.3 VULNERABILIDADES NO ARMAZENAMENTO DE INFORMAÇÕES
Os apps podem trocar informações ente eles, e com as APIs de acesso é
possível dizer quais informações podem ser acessadas. Assim é aceitável
esperar que todo o tráfego de informações ocorra pelos canais controlados
pelo sistema mas existem outras formas de acessar informações
sensíveis(Applications Security for the Android Platform Processes, 2011).
Algumas informações são armazenadas na memória interna do dispositivo,
estes dispositivos frequentemente oferecem suporte para cartões de memória
onde também é possível instalar apps. Esses meios de armazenamento podem
ser acessados de um PC bastando retirá-los do dispositivo e plugar no
48
computador(o acesso à memória interna do aparelho também é simples), e
assim ter acesso às informações de um determinado app sem que o controle
de segurança do sistema interfira. Outra forma de acessar a informação
desejada é conseguir acesso de root (tarefa não muito difícil). Esse modo provê
acesso irrestrito ao sistema e a memória.
Com base no exposto acima, seguir o Princípio do Privilégio Mínimo
(armazenando apenas as informações necessárias para o funcionamento do
app), configurando as permissões corretamente (assim outros apps não terão
acesso as informações em tempo de execução do sistema), e criptografando
os dados (em caso de acesso off line as informações, o atacante não poderá
fazer nada) são conhecido como Defense in Depth (DiD) (Applications Security
for the Android Platform Processes, 2011).
3.4 PROTEÇÃO DOS DADOS NO ANDROID
Como foi visto antes, cada app no Android executa sob sua própria conta de
usuário. Isto evita que uma aplicação tenha acesso às informações de outra.
Esta proteção oferecida pelo sistema geralmente não suficiente, de modo que,
as informação de autenticação de um app de sistema bancário, que estão
armazenadas, precisam estar criptografadas para oferecer uma proteção
adicional.
3.4.1 Bloqueio de Tela
O Android oferece algumas proteções básicas contra o acesso não autorizado
as informações do sistema, a primeira barreira é o bloqueio de tela. O sistema
oferece algumas opções para isso como: reconhecimento facial, desenho de
um padrão, código PIN (código numérico de4 dígitos) ou senha alfanumérica. A
segurança aumenta nesta ordem.
49
Figura 24 – Tela de configuração de bloqueio do Android
Fonte: (ghacks, 2012).
Figura 25 – Bloqueio de tela por código pin, desenho de padrão e senha alfanumérica respectivamente. Fonte: O Autor (utilizando o AVD versão para Windows).
Pela figura 25 vemos que o código pin se trata de uma combinação numérica
de quatro números (de 0 a 9) que podem se repetir, em um total de 10.000
combinações possíveis, um bloqueio muito fraco. O pattern lock se trata de
desenho onde é possível uma combinação de até nove posições, sendo que
50
cada elemento da combinação pode aparecer apenas uma vez na sequência.
O que gera um total de 9! combinações possíveis, ou 362 880 combinações,
algo não muito difícil de ser quebrado com um computador de mesa. Logo, o
método mais efetivo para bloqueio de tela é a senha alfanumérica.
3.4.2 Criptografia de Dados
Caso as informações contidas no dispositivo sejam muito sensíveis é possível
criptografá-los. É possível criptografar contas de usuário, configurações, apps,
arquivos de media ou qualquer outro tipo de arquivo, uma vez que os dados
sejam criptografados não será possível acessá-los sem entrar com a chave de
criptografia, que é solicitada toda vez que o Android é ligado.
Figura 26 – Tela de opção para criptografar os dados do dispositivo
Fonte: (ghacks, 2012).
51
Um dos riscos envolvidos nesta operação é o fato dela ser irreversível, assim
se o processo for interrompido na metade ou por falta de bateria ou porque o
usuário mudou de ideia os dados serão perdidos.
Figura 27 – Criptografia dos dados: telas de aviso e confirmação respectivamente
Fonte: (ghacks, 2012).
Assim que o processo terminar, será solicitada a senha utilizada na operação.
3.5 SEGURANÇA NA TRANSMISSÃO DE INFORMAÇÕES
No item anterior foi abordada a segurança dos dados no próprio dispositivo,
neste tópico será discutida a segurança dos dados transmitidos pela rede para
outras partes como uma aplicação servidora com quem frequentemente um
app do Android interage. Os dois princípios básicos a considerar quando uma
informação é transmitida de um sistema a outro são: Autenticação e
Confidencialidade. A Autenticação serve para assegurar que a parte que irá
receber os dados é quem realmente diz ser. Já a confidencialidade trata de
prevenir que uma terceira entidade intercepte os dados transmitidos
(Applications Security for the Android Platform Processes, 2011).
52
O padrão utilizado pela indústria para o transporte de dados de maneira segura
pela Internet é o SSL (Secure Sockets Layer) e TLS (Transport Layer Secure).
Esses protocolos foram desenvolvidos para proteger os dados transportados e
permitir que o cliente autentique o servidor com quem ele conversa. A maioria
das aplicações exige que o login e senha do usuário sejam enviados a cada
requisição e, mesmo que seja por um canal criptografado, esta não é a melhor
solução. A classe AccountManager permite que a aplicação envie um token
junto com as requisições, este token muda periodicamente o que passa a ser
uma forma mais segura de autenticação (Applications Security for the Android
Platform Processes, 2012).
3.5.1 Autenticação no protocolo SSL/TLS
O objetivo do protocolo SSL é permitir que o cliente verifique a autenticidade do
servidor com o qual se comunica. Uma aplicação cliente não pode apenas
confiar no IP (hostname) que requisita e esperar que o servidor que atenda
seja verdadeiro pois existem técnicas para desviar uma chamada de um
hostname para outro. Para contornar essa situação, o SSL/TSL usa uma chave
de criptografia assimétrica para promover a autenticação. No primeiro passo, o
servidor envia o seu certificado digital ao cliente, neste certificado estão o nome
do servidor e da autoridade certificadora (CA). O cliente prossegue com a
validação do certificado e após esta é gerado pelo cliente um número aleatório
que é criptografado pelo cliente com a chave publica descrita no certificado
digital e enviada ao servidor durante o handshake. A partir deste momento a
comunicação entre as duas partes ocorre usando este número como chave
simétrica de criptografia para as informações transitadas. Para a validação dos
certificados o Android possui uma lista de autoridades certificadoras e iniciar
uma comunicação segura com uma delas exige muito pouca codificação
(Applications Security for the Android Platform Processes, 2012).
3.5.2 Transmissão dos Dados
O Android possui uma configuração para conexões SSL/TLS bastando fazer a
chamada openConnection() da classe HttpsUrlConnection como mostrado na
figura 28:
53
Figura 28 – Exemplo de configuração de conexão SSL/TLS Fonte (Applications Security for the Android Platform Processes, 2012).
Após obter a conexão segura com o servidor é possível examinar algumas
informações sobre ela através de alguns métodos uteis da classe
HttpsURLConnection como:
getCypherSuite() que retorna o algoritmo criptográfico utilizado na
conexão. Pode ser usado para medir a segurança da conexão.
getServerCertificates() que retorna um vetor com todos os certificados
fornecidos pelo servidor. Permite ao desenvolvedor checar a validade
destes junto a um CA (que o Android reconhece).
3.6 AMEAÇAS NA TRANSMISSÃO DE DADOS
Aplicações Web precisam de muito cuidado com os dados enviados a elas pois
aceitar dados que não fazem parte do conjunto esperado configura uma brecha
de segurança e pode trazer diversos danos à aplicação servidora, como SQL
injection, cross-site scripting attacks e exploração de buffer overflow, por
exemplo. Aplicações cliente como as do Android não suscetíveis a estas falhas
mas não estão imunes a elas. Assim, um dos princípios de um
desenvolvimento seguro é validar os dados fornecidos pela aplicação e
enviados a ela, pois um App que esta sujeito a receber informações de fontes
externas pode acabar sendo manipulado por um atacante (Applications
Security for the Android Platform Processes, 2012).
3.7 MALWARE
Os malwares que tem como alvo o SO Android são similares e ao mesmo
tempo muito diferentes dos malwares que atacam o Windows. Desde o seu
lançamento em 2008, o Android vem crescendo rapidamente como uma
plataforma open source para smartphones, com rápido aumento no poder de
processamento e memória além da adição de componentes como câmera,
URL url = new URL("https://clientaccess.example.com"); HttpsURLConnection urlConn = (HttpsURLConnection)url.openConnection();
ou
HttpsURLConnection urlConn = new HttpsURLConnection("https://clientaccess.example.com");
54
internet e GPS. Com isso, era apenas uma questão de tempo para que os
hackers dirigissem sua atenção para esses dispositivos(Android Malware
Exposed, 2012).
Outra razão para atacar smartphones Android é que o fato dos usuários terem
mais informações pessoais salvas nele do que em um PC. Quando um usuário
se autentica no serviço de e-mail ou no Facebook através do smartphone ele
não precisará mais repetir o processo porque sua senha está salva no
dispositivo. Essa funcionalidade é conveniente não apenas para os usuários
mas também para os hackers que estarão atrás desta informação (Android
Malware Exposed, 2012).
O primeiro malware para Android foi descoberto em 2010, desde então a
empresa de segurança Webroot já identificou mais de 13000 exemplos de
malware para o Android. Sendo o Android desenvolvido sobre o kernel do
Linux, ele cria um usuário e grupo Linux para cada aplicação, como já
explicado, a fim de impedir o acesso dos dados de uma aplicação por outra.
Sendo assim, a forma de uma aplicação ter acesso às informações de login do
usuário no Facebook ou ao serviço de SMS do dispositivo é se o usuário
permitir no momento da instalação, e é nesse iteração com o usuário que a
maior parte dos malwares ataca (Android Malware Exposed, 2012).
55
CAPÍTULO 4. FORENSE DIGITAL NO ANDROID
4.1 INTRODUÇÃO
A plataforma móvel Android cresceu rapidamente desde o lançamento, em
Outubro de 2008, até torna-se o sistema operacional móvel mais popular no
inicio de 2011. Contudo, os analistas forenses e engenheiros de segurança têm
lutado contra a falta de ferramentas e técnicas para investigar os dispositivos
com esse sistema (Android Forensics, 2011). Existem técnicas e abordagens
muito bem documentadas e difundidas para telefones celulares e desktops,
mas essas técnicas não se aplicam em sua totalidade quando associadas a
exames de smatphones, uma vez que nesses dispositivos, as soluções de
hardware e software são minimalistas e o sistema operacional possui suporte à
utilização de memórias internas cuja remoção ou espelhamento são
procedimentos considerados invasivos e com maior grau de complexidade,
devido às dificuldades de acesso direto ao hardware. Além disso, os
dispositivos possuem características específicas para cada versão e fabricante
do hardware (Aquisição de Evidências Digitais em Smatphones Android, 2011).
Conforme a capacidade de armazenamento de dados dos dispositivos
aumentou, a quantidade de informações salvas neles também aumentou e,
muito dessa informação interessa a organizações criminais que promovem
ataques a plataforma com o intuito de obter as informações pessoais de seus
usuários e empresas. Solucionar este impasse requer um profundo
entendimento da plataforma, não só dos desenvolvedores do sistema ou dos
fabricantes mas, também, dos desenvolvedores de apps e das agências de
segurança. Apps mais seguros junto com politicas de segurança mais fortes
irão prevenir a perda ou roubo de dados sensíveis de seus usuários (Android
Forensics, 2011).
Isso mostra a necessidade da forense no Android. A maioria das pessoas está
sempre muito próxima de sues smatphones, mesmo quando estão dormindo. O
dispositivo armazena tanto informações pessoais como corporativas salvas na
forma de mensagens de texto, e-mails, localização de GPS, imagens, vídeos e
outros. E há uma tendência das pessoas serem mais honestas com o próprio
56
dispositivo do que com outras pessoas. Simplesmente por acreditarem que ele
é seguro (Android Forensics, 2011).
Mesmo o Android sendo lembrado pelos smartphones e tablets, atualmente
existem vários dispositivos que rodam o sistema ou irão fazê-lo em um futuro
próximo. E tanto a forense de dispositivos móveis como do próprio Android tem
diversos desafios: na forense digital um princípio fundamental é prevenir
qualquer modificação no dispositivo pelo examinador. Isso é simples em discos
rígidos que podem ser desligados, conectados a outro equipamento e então
fazer uma imagem do mesmo. Mas no caso dos smartphones qualquer iteração
com o dispositivo irá alterá-lo de alguma forma e, nesse caso, os examinadores
deverão explicar como ele foi modificado e por que. Este capítulo apresenta
técnicas forenses para aquisição de dados de dispositivos com Android.
4.2 TIPOS DE INVESTIGAÇÃO
A primeira situação é a julgada num tribunal criminal. Nesta situação existem
algumas considerações:
Cadeia de custodia
Detalhamento e relatório final
Possível validação dos resultados usando ferramentas diferentes
Fato ou opinião baseada em testemunha
Outra situação é a das investigações corporativas. Elas também podem acabar
sendo julgadas em um tribunal mas frequentemente são utilizadas para
determinar a causa raiz de um problema (como um sistema, ataque externo ou
empregado interno - o que pode resultar em uma ação contra o empregado).
As áreas mais comuns nas investigações internas corporativas são:
Propriedade intelectual e roubo de dados
Uso inadequado dos recursos da empresa
Ataque ou tentativa bem sucedida contra os sistemas da empresa
Investigações sobre um empregado, incluindo a discriminação, assédio
sexual, etc.
Auditoria de segurança
Existe a situação envolvendo relações familiares:
57
Divorcio
Custódia de crianças
Disputa de propriedades
A ultima situação se refere a segurança governamental, onde a pericia forense
pode exercer um papel chave. Governos são os maiores empregadores nos
países, chegando a vários milhões em países como o Brasil.
Além das questões relacionadas aos empregados, governos são alvos de
ataques e roubo de dados por criminosos e governos estrangeiros. A perícia
forense pode ajudar na investigação dos ataques bem sucedidos e na
prestação de informações valiosas para a frustação de futuros ataques
(tradução nossa).
4.3 AMBIENTE DE TESTES
Os experimentos desta pesquisa utilizam ferramenta e scripts do mundo Unix,
assim, será utilizando a distribuição Linux Ubuntu 13.04 64 bit para Desktop.
Como já mencionado nesta pesquisa, para a análise forense, é necessário que
as configurações do dispositivo móvel que será analisado sejam mantidas
intactas, ou na pior hipótese, sejam modificadas ao mínimo possível e que essa
modificação seja devidamente justificada. Com base nisso, é importante que o
SO utilizado tenha a função automount desabilitada. No Ubuntu esta opção é
feita por usuário e pode ser modificada através do gconf com o comando
gconf-editor executado no terminal. Navegando até a opção
apps>nautilus>preference e desmarcando as opções “media_automount” e
“media_automount_open”.
O principio básico da investigação forense é evitar qualquer modificação do
dispositivo alvo. Em muitos casos isso é inviável. Nos caso de um computador
Desktop que está desligado, o perito vai simplesmente documentar o
computador, remover o disco rígido, conectá-lo a um write blocker e obterá
uma imagem bit-a-bit do disco. Nessa investigação o dispositivo original
permanece intacto. Continuando nos computadores Desktops, no caso do
equipamento estar ligado a situação começa a complicar: qualquer iteração
como desliga-lo irá modificar o dispositivo de alguma forma. Simplesmente
58
desligar o computador modifica o conteúdo de sua memória RAM, conexões de
rede abertas e outras informações serão perdidas.
No caso de dispositivos móveis é impossível realizar uma análise forense sem
modifica-lo. Ao contrário de desktops e notebooks, dispositivos Android
possuem partes de armazenamento que não podem ser facilmente removidas.
E iterações simples como ligar, desligar e recolocar a bateria modificam o
dispositivo.
Na primeira vez que os celulares apareceram nas investigações, havia uma
pequena quantidade de dados armazenada que podia ser extraída deles.
Muitos investigadores usavam técnicas tradicionais como uma permissão para
obter os dados de chamadas telefônicas na operadora de celular. Era possível
também remover o subscriber identity module (SIM) card de telefones GSM e
extrair algumas informações dele. Conforme os celulares foram evoluindo,
chegando ao categoria de smartphones, e consequentemente sua capacidade
de armazenamento, houve uma divisão entre os peritos sobre quais técnicas
utilizar durante a analise: os que defendiam a continuidade do uso da técnicas
tradicionais (com pequeno impacto no dispositivo e consequente menor
aquisição de informação) e os que defendiam uma analise mais completa mas
que ocasiona mudanças no dispositivo (Android Forensics, 2011).
A Association of Chief Police Officers (ACPO) do Reino Unido estabelece um
guia (Good Pratice for Computer-Based-Eletronic Evidence) com quatro
princípios que São listado abaixo(ACPO, 2013, tradução nossa):
1. Nenhuma ação realizada por policiais ou seus agentes deve modificar os
dados em um computador ou media de armazenamento que podem,
posteriormente, serem pedidos em um tribunal.
2. No caso em que um examinador julga necessário acessar os dados
originais de um computador ou media de armazenamento, esse
examinador deve ser competente para fazê-lo e capaz de explicar a
relevância e implicações de suas ações.
3. Um rastreamento da auditoria ou outra forma de registro de todos os
processos de análise aplicados a um computador para obter evidência
deve ser criado e preservado. Uma terceira parte independente deve ser
59
capaz de examinar os processos e arquivos e chegar a mesma
conclusão.
4. A pessoa encarregada da investigação tem a responsabilidade de
garantir que a lei e esses princípios serão respeitados.
4.4 PRESERVANDO O ESTADO DO DISPOSITIVEL MÓVEL
No caso de dispositivos móveis, que são relativamente novos, não existe ainda
um protocolo de ações que devem ser tomadas para preservar o estado
original do aparelho, uma das premissas da perícia forense. O que existe hoje
é uma tendência a partir diretamente para a análise dos dados, o que
frequentemente resulta em alteração das informações e potencial risco de
perdê-las. O que segue são alguns procedimentos para garantir a segurança
das informações contidas no dispositivo móvel (Android Forensics, 2011).
4.4.1 Passando pelo Bloqueio de Tela
Bloqueio de tela é um recurso de segurança muito popular no Android graças a
uma conscientização sobre a importância da segurança das informações,
especialmente nas empresas. Porém, nos casos em que o dispositivo móvel é
obtido ligado, alguns procedimentos devem ser tomados antes que a tela seja
bloqueada e um eventual pass code precise ser reinserido.
1. Aumentar o tempo de espera da tela, para o máximo possível, para
evitar o bloqueio da mesma. O modo de acessar a opção pode variar
conforme a versão do Android. Na versão 4 do Android ela é acessada
através das opções Lock Screen Setting -> Lock Timer.
2. Habilitar a depuração por USB e a opção “Stay Awake”. Estas podem
ser encontradas em Settings -> Developer Options. Depuração USB é
para possibilitar a extração de dados e a opção Stay Awake para evitar
que a tela seja bloqueada enquanto o dispositivo é recarregado.
Lembrando que estas são alterações da configuração original do aparelho e
que, por isso, devem ser devidamente documentadas e explicadas.
60
No caso dos dispositivos que são obtidos desligados ou com a tela bloqueada
é necessário passar pelo modo de proteção que esteja ativado, a seguir são
listadas as principais técnicas para desbloqueio da tela do Android.
Smudge Attack
No capítulo 4, Segurança no Sistema Operacional Android, foram apresentadas
algumas formas de bloqueio de tela para dispositivos móveis Android. Uma
delas era o desenho de um padrão (Draw pattern). Uma forma de passar por
este bloqueio é conhecido como Smudge Attack, um estudo realizado pelo
Departamento de Computação e Ciência da Informação da Universidade da
Pensilvânia, que consiste em fotografar a tela do dispositivo touch screen
(Smudge Attacks on Smartphone Touch Screens, 2011).
Figura 29 – Foto mostrando a marca do pattern desenhado. Fonte (Smudge Attacks on Smartphone Touch Screens, 2011)
O estudo diz que a superfície de tela touch screen limpa do dispositivo não é
totalmente reflexiva, e que uma manchada (pelo uso) não é totalmente difusa.
Essa mancha muitas vezes corresponde ao pattern desenhado pelo usuário
61
para desbloquear o aparelho. Assim, no experimento, algumas fotos foram
tiradas da tela do dispositivo quando uma fonte de luz era posicionada em um
ângulo não exatamente complementar e o resultado foi a visualização da
mancha que corresponde ao padrão desenhado para o desbloqueio da tela
(Android Forensics, 2011).
Modo de Recuperação
O modo de recuperação é comumente utilizado por usuário que instalam ROMs
customizadas (versões do sistema Android diferentes da originalmente
instalada no aparelho) que habilitam o root por meio da instalação de uma
partição modificada de recuperação. Esse modo faz com que o bloqueio de tela
seja desabilitado e permite montar suas partições em modo somente leitura.
Iniciar o Android em modo de recuperação varia conforme o fabricante do
hardware do dispositivo, no LG P970, por exemplo, isso é feito pressionando o
botão de volume para cima e pressionando o botão para liga-lo. Caso a
conexão via ADB e o smudge attack falhem, se o dispositivo executa uma ROM
modificada do Android, o modo de recuperação deve ser considerado, e este
só funciona se for um modo modificado por uma ROM customizada instalada
(Android Forensics, 2011).
Gravar Uma Nova Partição de Recuperação
Ferramentas como a Fastboot permitem gravar uma partição modificada de
modo de recuperação, e o não precisam que o modo de depuração USB esteja
habilitado para isso. Uma vez instalada esta partição modificada, é possível ter
acesso aos dados do usuário. A restrição fica por conta da proteção sobre o
modo bootloader (necessário para instalar a partição modificada) que alguns
fabricantes mantem habilitada. Como no modo de recuperação, o iniciar o
dispositivo em bootloader varia conforme o fabricante. Este é uma ferramenta
extremamente útil mas que modifica o estado do aparelho. Este tipo de
intervenção deve devidamente justificada e ser executada por uma pessoa que
saiba o que está fazendo, pois há risco de perda de informações (Android
Forensics, 2011).
62
Desabilitar o Bloqueio por Meio do Google Play
Se a senha e o login da conta Google do usuário do dispositivo móvel forem
conhecidas, é possível instalar um App no aparelho e através dele desabilitar o
bloqueio de tela. No artigo Android Lock Screen Bypass, de Thomas Canon,
essa técnica é descrita através da possibilidade de instalar App no Android pelo
Google Play. A técnica consiste em instalar dois APPs no dispositivo, o
segundo vai servir para dispara uma trigger que iniciará o primeiro, este,
através da chamada disableKeyguard() da API do Android fará o desbloqueio
da tela (Android Lock Screen ByPass, 2011).
Login da Conta Google
Se o analista estiver em posse do usuário e senha da conta Google vinculada
ao dispositivo Android é possível desbloquear a tela, pois após certo número
de tentativas mal sucedidas, o sistema oferece a opção de desbloqueio pelo
login da conta Google do usuário. Caso o analista não tenha esse login mas
tenha um mandato judicial para obtê-lo, é possível fazer uma requisição ao
Google e apagar a senha da conta. O risco desta operação fica por conta da
necessidade do dispositivo se conectar a rede para atualiza a senha e acabar
exposto a um ataque de rede, onde é possível executar ações no dispositivo
bastando o envio de uma mensagem.
4.4.2 Isolando o Dispositivo Móvel da Rede
Se o dispositivo não estiver com bloqueio de tela ou após este ser desabilitado,
a primeira ação a ser tomada é isolar o dispositivo da rede, caso contrário um
ataque aos dados do aparelho pode ser iniciado por uma simples mensagem
SMS do atacante. O modo mais simples de isolar o equipamento da rede é
coloca-lo no Modo Avião (Airplane mode). Isso pode ser feito pressionado o
botão de ligar e selecionado a opção modo avião (Android Forensics, 2011):
Caso não seja possível ativar o modo avião por caso do bloqueio do aparelho,
por exemplo, e caso esse seja um telefone GSM, é possível remover o chip do
aparelho se isso também não for possível, suspender a conta (número
63
telefone) diretamente na operadora também é uma opção. A ultima alternativa
é colocar o dispositivo móvel dentro de uma Gaiola de Faradey, mas nesse
caso existem várias implicações como o rápido consumo de bateria, já que o
dispositivo tentará insistentemente reestabelecer suas conexões. A tabela 9
mostra as vantagens e desvantagens de cada método (Android Forensics,
2011):
Tabela 9 – Técnicas para isolar um dispositivo móvel da rede
Método Vantagens Desvantagens
Colocar o dispositivo móvel em modo avião.
O dispositivo continua executando e mantem intactas as informações na memória volátil. Desabilita as conexões do dispositivo móvel como wi-fi, 3G, bluetooth.
Modifica as configurações do aparelho. Funciona apenas se o analista tiver acesso total ao dispositivo.
Remover o cartão SIM. Fácil de remover. Efetivo em desabilitar transmissões de voz, SMS e dados.
Não desabilita wi-fi, bluetooth e outras redes. Funciona apenas com telefones GSM.
Suspender a conta com a operadora.
Efetivo em desabilitar transmissões de voz, SMS e dados.
Requer tempo (mandato judicial). Não desabilita wi-fi, bluetooth e outras redes.
Colocar o dispositivo dentro de uma gaiola de faraday.
Interrompe todas as conexões de rede.
Rápido consumo da bateria em função das retentativas de restabelecer as conexões, por parte do aparelho. Não é possível inserir um cabo de energia na bolsa.
Desligar o dispositivo Interrompe todas as conexões de rede.
Modifica a memória volátil do dispositivo. Pode habilitar o bloqueio de tela na reinicialização.
Fonte (Android Forensics, 2011).
No caso da Gaiola de Faraday, o ideal seria uma sala com o mesmo tipo de
proteção contra redes externas onde haveria como fornecer cabo alimentação
ao dispositivo, mas os custos para construir e manter uma sala dessas são
muito altos (Android Forensics, 2011).
64
Por ultimo, se o dispositivo for encontrado desligado, convém inicia-lo no modo
de recuperação para ver as suas conexões, se o modo de depuração está
ativado e verificar se possui acesso de root (Android Forensics, 2011).
4.4.3 Conhecendo o Dispositivo
Como ultimo cuidado para preservar o estado do aparelho durante os
processos de dumping de memória e análise, é fundamental saber com o que
se está trabalhando. A iteração com o sistema Android varia conforme o
fabricante do hardware do aparelho, assim, um comando bastante útil neste
sentido é o lsusb, que listará as informações referentes ao software instalado e
fabricante do hardware. A figura 30 apresenta a saída do comando (Android
Forensics, 2011):
Figura 30 – Saída do comando lsub Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
4.5 EXTRAINDO INFORMAÇÕES DO DISPOSITIVO
Extração de dados é o primeiro procedimento a ser feito pelos analistas
forenses, depois dos cuidados para preservar o estado original do dispositivo.
4.5.1 Extração Via Software
Essa é geralmente a primeira técnica utilizada pelos analistas forenses, porque
além de simples, na maioria dos casos fornece informação suficiente para
encerrar uma acusação. O único requisito é que o modo de depuração USB
esteja habilitado. Não é necessário acesso de root, embora algumas partes da
memória interna necessitem desse tipo de permissão para serem acessíveis.
luffy@ubuntu:~$ sudo lsusb -v Bus 002 Device 004: ID 1004:61a6 LG Electronics, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1004 LG Electronics, Inc. idProduct 0x61a6 bcdDevice 2.16 iManufacturer 2 LGE iProduct 3 LG Android iSerial 4 7DF600229FFC0000016395910A01600F bNumConfigurations 1
65
ADB Pull
O comando adb pull copia recursivamente uma parte desejada do sistemas de
arquivos. Porém, como já dito, as partes mais importantes do sistema de
arquivo são visíveis apenas ao root. Mas, mesmo sem acesso de super usuário
é possível extrair informações relevantes da memória interna e do SDCard. A
figura 31 mostra um exemplo de tentativa de obter o conteúdo do diretório
/data, que está visível apenas acesso root, com um shell de usuário comum
(Android Forensics, 2011):
Figura 31 – Extração de dados via adb pull sem acesso de root Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
Como não há permissão suficiente o comando simplesmente não copia os
arquivos.
Para executar o comando com acesso de root é necessário reiniciar o ADB em
modo root com o comando adb root. Agora uma tentativa de extrair em um
dispositivo com root resulta na saída:
Figura 32 – Extração de dados via adb pull como root Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
No caso de um dispositivo Android com root mas que mantem a ROM do
fabricante, o analista receberá a mensagem “adbd cannot run as root in
production builds”. Neste caso é preciso seguir os seguintes passos para
obter os dados de diretórios protegidos:
1) Obter uma shell pelo comando abd shell.
2) Obter acesso de root com o comando su.
luffy@ubuntu:~$ adb pull /data data/ pull: building file list... 0 files pulled. 0 files skipped
luffy@ubuntu:~$ adb pull data/ data/ // varios outros arquivos pull: data/backup/processed -> data/backup/processed pull: data/backup/ancestral -> data/backup/ancestral pull: data/LostFound/Vesta -> data/LostFound/Vesta pull: data/LostFound/Interamnia -> data/LostFound/Interamnia pull: data/LostFound/Hygiea -> data/LostFound/Hygiea pull: data/LostFound/Europa -> data/LostFound/Europa pull: data/LostFound/Davida -> data/LostFound/Davida pull: data/LostFound/Ceres -> data/LostFound/Ceres 1463 files pulled. 0 files skipped. 2050 KB/s (521045345 bytes in 248.121s)
66
3) Mudar a permissão de acesso do diretório e subdiretórios visados
recursivamente com o comando chmod –R 777 <diretório raiz>.
4) Sair do modo adb shell e executar o comando adb pull [origem]
[destino].
4.5.2 Extração Via Hardware
Técnicas de extração de dados via hardware sempre obtém mais informações
do dispositivo, conseguem passar por eventuais bloqueios de software e
recuperar informações já removidas. No sistema YAFFS2 do Android, por
exemplo, quando dados são atualizados as versões anteriores não são
imediatamente apagadas, apenas não são listadas. Removê-las
definitivamente é tarefa do coletor de lixo, então, enquanto este não executar,
há dados “apagados” que podem ser recuperados. Considerando o alto custo
dos equipamentos para realizar uma extração física dos dados e que este
método geralmente não é a primeira escolha do analistas forenses, este
assunto não parte desta pesquisa (Android Forensics, 2011).
4.6 ANÁLISE DAS INFORMAÇÕES OBTIDAS
Após extrair os dados do dispositivo vem a parte de análise já que informação
sem contexto não prova nada. No capítulo 2, sobre o Android, foram exibidos
alguns mecanismos para visualização dos logs do sistema e sua análise. Neste
capítulo são mostradas mais algumas técnicas de análise (não todas). Ao
contrário do processo de extração de dados, várias técnicas tradicionais de
análise podem ser aplicadas aos dispositivos com Android (Android Forensics,
2011).
4.6.1 Ferramentas e Técnicas de Análise de Dados
Time Line
Saber quando determinado evento ocorreu é muito importante numa
investigação, porém criar uma linha do tempo a partir das informações
extraídas manualmente é um trabalho cansativo. Existem vários softwares que
podem realizar esta tarefa, esta sessão se concentra nos aplicativos
67
opensource para criação de time line como os do Sleuth Kit e log2timeline
(Android Forensics, 2011).
Sistemas de Arquivos
Alguns diretórios e arquivos que merecem maior atenção do examinador já
foram apresentados durante o capítulo 2, o comando adb mount apresenta
mais alguns desses diretórios:
Figura 33 – Saída do comando mount Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
Algumas das principais partições foram listadas em negrito. A tabela 10 mostra
uma descrição dos dados de cada partição.
Tabela 10 – Partições e sistemas de arquivos
Local de Montagem Sistema de Arquivos Relevância
/proc proc metadados e estatísticas do sistema de arquivos
/data/data YAFFS2 Contem os dados de todas as aplicações
/cache YAFFS2 Arquivos de cache do sistema
/app-cache tmpfs Sistema de arquivos de cache.
/mnt/sdcard vfat Sistema de arquivos do cartão removível
/mnt/emmc vfat Memória interna dedicada ao usuário
/data/local YAFFS2 Permite leitura e escrita para usuários não root num shell adb
/data/misc YAFFS2 Dados de bluetooth, dhcp, wi-fi, vpn e outros.
Fonte: (Android Forensics, 2011).
luffy@ubuntu:~$ adb shell mount rootfs / rootfs ro,relatime 0 0 tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 tmpfs /mnt/extobb tmpfs rw,relatime,mode=755,gid=1000 0 0 none /acct cgroup rw,relatime,cpuacct 0 0 tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0 tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0 /dev/block/mmcblk0p5 /drm/widevine ext4 rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered 0 0 /dev/block/mmcblk0p9 /data ext4 /dev/block/mmcblk0p10 /cache ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=1,nomblk_io_submit,data=ordered 0 0 /sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0 /dev/block/vold/179:49 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 /dev/block/vold/179:49 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_ut
68
Mesmo que não existam ferramentas que lidem diretamente com o sistema de
arquivos YAFFS2, através do adb tools, as informações da memória interna do
dispositivo podem ser copiadas para uma estação de trabalho com sistema de
arquivo suportado e, depois, analisadas diretamente (Android Forensics, 2011).
Strings
Um comando bastante útil, do mundo Linux, é o strings. Ele faz com que o
conteúdo de um arquivo seja apresentado, por padrão ASCII, como strings. A
figura 34 mostra o comando strings utilizado sobre a base SQLite do dropbox:
Figura 34 – Saída do comando strings sobre uma base SQLite Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
Como visto, esse comando ajuda a extrair informações mesmo de arquivos
aparentemente ininteligíveis em um editor de texto comum.
Editor Hexa
Em geral, uma cópia dos arquivos da memória interna do Android fornecerá as
informações necessárias para a investigação, porém, nos casos em que é
necessário uma análise mais profunda de arquivos apagados ou
desconhecidos em partições YAFFS2, que as ferramentas de análise não
suportam. Por essa razão saber utilizar um editor hexadecimal é de
fundamental importância.
luffy@ubuntu:~/data/data/com.dropbox.android$ strings databases/prefs.db SQLite format 3 tableDropboxPersistentPrefsDropboxPersistentPrefs CREATE TABLE DropboxPersistentPrefs (_id INTEGER PRIMARY KEY AUTOINCREMENT, pref_name TEXT NOT NULL UNIQUE, pref_value TEXT)K indexsqlite_autoindex_DropboxPersistentPrefs_1DropboxPersistentPrefs Ytablesqlite_sequencesqlite_sequence CREATE TABLE sqlite_sequence(name,seq) tableDropboxAccountPrefsDropboxAccountPrefs CREATE TABLE DropboxAccountPrefs (_id INTEGER PRIMARY KEY AUTOINCREMENT, pref_name TEXT NOT NULL UNIQUE, pref_value TEXT)E indexsqlite_autoindex_DropboxAccountPrefs_1DropboxAccountPrefs ctableandroid_metadataandroid_metadata CREATE TABLE android_metadata (locale TEXT) fr_CA 37=NOTIFICATIONS_TO_M NOTIFICATIONS_TO_MUTEB
69
Figura 35 – Visualização de uma base SQLite no hexeditor Fonte: (Android Forensics, 2011).
Na figura 35, a saída do editor hexadecimal executado sobre uma base SQLite
de um App Android.
SQLite3
Uma vez que os APPs Android armazenam suas informações em bases
SQLite, é conveniente ter instalado a ferramenta sqlite3 no ubuntu.
Figura 36 – Visualização das tabelas de uma base SQLite Fonte: (Android Forensics, 2011).
Na figura 36, a listagem das tabelas de uma base com a ferramenta sqlite3.
4.6.2 Análise Forense das Partições SDCard e eMMC
Arquivos multimídia, fotos, dados de aplicativos, músicas, backup de arquivos
são todos exemplos de informações recuperáveis a partir do cartão de
memória. E não apenas arquivos encontráveis mas também informações
apagadas, cache de aplicações apk baixados. Além disso, o SDCard pode ser
montado como dispositivo de armazenamento externo a um PC e qualquer tipo
de arquivo pode ser transferido à ele (Android Forensics, 2011).
ahoog@ubuntu:~$ hexeditor mmssms.db File: mmssms.db ASCII Offset: 0x00000000 / 0x00077FFF (%00) 00000000 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 SQLite format 3. 00000010 04 00 01 01 00 40 20 20 00 00 24 4A 00 00 00 00 .....@ ..$J.... 00000020 00 00 00 00 00 00 00 00 00 00 00 3C 00 00 00 01 ...........<.... 00000030 00 00 00 00 00 00 00 18 00 00 00 01 00 00 00 3C ...............< 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060 00 00 00 00 05 00 00 00 17 03 8D 00 00 00 00 45 ...............E 00000070 03 FB 03 F6 03 F1 03 EC 03 E7 03 E2 03 DD 03 D8 ................ 00000080 03 D3 03 CE 03 C9 03 C4 03 BF 03 BA 03 B5 03 B0 ................ 00000090 03 AB 03 A6 03 A1 03 9C 03 97 03 92 03 8D 00 00 ................ 000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 04 81 0C ................ 000000C0 03 07 17 15 15 01 81 7B 74 61 62 6C 65 61 64 64 .......{tableadd 000000D0 72 61 64 64 72 05 43 52 45 41 54 45 20 54 41 42 raddr.CREATE TAB
ahoog@ubuntu:~$ sqlite3 mmssms.db SQLite version 3.6.22 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .tables addr incoming_msg sms android_metadata incoming_msg_v2 sr_pending attachments part threads canonical_addresses pdu threads_list cbch pending_msgs words drm qtext words_content htcmsgs rate words_segdir htcthreads raw words_ segments
70
Apps no SDCard
Com o objetivo de liberar espaço na memória interna do dispositivo, é possível
mover um aplicativo para o SDCard (o app deve ter suporte para esta ação).
Como já dito, o diretório dos aplicativos é o /data/data, onde os dados do
usuário estão salvos. Como na imagem abaixo, desde que a aplicação suporte
esta operação, basta clicar sobre o botão “Move to SD card” para mover um
aplicativo para a partição do usuário.
Figura 37 – Opção Mover para o cartão de memória Fonte: (Android Forensics, 2011).
Para o usuário de um dispositivo Android com pouca memória interna esta
opção é bastante conveniente, mas do ponto de vista da análise forense
existem algumas considerações:
1. O arquivo .apk é movido de “/data/<app-name>” para partição
criptografada “/mnt/secure/asec/” acessível apenas pelo root.
2. Uma nova partição é montada (no modo somente leitura) e o aplicativo
da “/mnt/secure/asec” é decriptografado e acessível ao sistema em
“/mnt/asec/<app-name>”, pois o sistema precisa ter acesso ao apk
decriptografado para executá-lo.
71
3. O diretório de dados do usuário referente ao aplicativo permanece sendo
o “/data/data/<app-name>”
4. Se o SDCard ficar inacessível, o aplicativo não é mais acessível ao
sistema, razão pela qual os apps básicos não podem ser movido para o
SDCard.
Como já mencionado, o .apk é criptografado de modo a impedir que outros
apps não o corrompam ou façam alguma modificação maliciosa. O
desenvolvedor também não deve confiar somente nesta criptografia uma vez
que basta copia-lo da partição decriptografada “/mnt/asec/<app-name>”. Logo,
se o analista precisa do .apk para a investigação (de um malware, por
exemplo) então ele deve copiar a partição “/mnt/asec” e seus subdiretórios
durante a fase de extração de informações. Esta cópia, deve ser feita com o
dispositivo ligado e ativo e não montada na estação de trabalho do analista.
Abaixo, a listagem da partição “/mnt” e as permissões relacionadas a cada
subdiretório, incluindo, como exemplo, o aplicativo movido:
Figura 38 – Listagem do diretório /mnt Fonte (Android Forensics, 2011).
nonmedia
Nonmedia é um arquivo que instrui o scanner de media do Android a pular o
diretório atual. Assim, se um diretório não tem este arquivo, é possível que
contenha arquivos do tipo thumbnails de imagens já apagadas. O arquivo
nonmedia é encontrado nas partições do sdcard e eMMC (Android Forensics,
2011).
Timeline
Para análise do tipo linha do tempo a ferramenta utilizada será a log2timeline.
Porém, após copiar os dados do dispositivo e antes de iniciar a análise,
ahoog@ubuntu:~/sd-emmc$ adb shell ls -l /mnt d---rwxr-x system sdcard_rw 1969-12-31 18:00 emmc drwxr-xr-x root system 2011-02-15 05:17 asec drwx------ root root 2011-02-14 07:59 secure d---rwxr-x system sdcard_rw 1969-12-31 18:00 sdcard ahoog@ubuntu:~/sd-emmc$ adb shell ls -l /mnt/asec dr-xr-xr-x system root 1969-12-31 18:00 com.rovio.angrybirds-1 ahoog@ubuntu:~/sd-emmc$ adb shell ls -l /mnt/asec/com.rovio.angrybirds-1 -r-xr-xr-x system root 17235931 2011-02-15 05:17 pkg.apk # ls -l /mnt/secure/asec ----rwxr-x system sdcard_rw 19192832 2011-02-15 05:17 com.rovio.angrybirds-1. asec # ls -l /data/data/com.rovio.angrybirds drwxrwx--x app_106 app_106 2011-02-15 05:14 cache drwxrwx--x app_106 app_106 2011-02-15 05:15 files drwxr-xr-x system system 2011-02-15 05:14 lib
72
convém usar uma criptografia de hash (md5sum ou sha256sum) tanto no
SDCard quanto na imagem, a fim de validar a última.
4.6.3 Análise Forense no Sistema de Arquivos YAFFS2
Como já mencionado, o sistemas de arquivos YAFFS2 é opensource,
desenvolvido especialmente para memórias do tipo flash NAND e inclui
algoritmos para correção de erros. Seu modelo arquitetural permite que dados
apagados e/ou atualizados sejam recuperados mas por ser um sistema de
arquivos recente, ainda não existem ferramentais (nem opensource nem,
comerciais) que o suportem. Sendo assim, a extração e analise dos arquivos
desta partição é feita via Android ADB Tools (Android Forensics, 2011).
73
CAPÍTULO 5. ESTUDO DE CASO
5.1 INTRODUÇÃO
A fim de demonstrar o uso das técnicas e ferramentas de extração e análise de
dados apresentadas ao longo deste trabalho, foi proposta a utilização destas
em uma situação encontrada pelos analistas forenses.
Um smartphone LG Optimus Black (P970) foi propositalmente infectado com o
malware Zitmo Trojan para identificação e análise do mesmo utilizando as
técnicas e ferramentas apresentadas no capítulo anterior. A análise do
malware, após sua extração, foi realizada em desktop com a versão 13.04 do
Linux Ubuntu.
5.2 METODOLOGIA DE ANÁLISE PROPOSTA
A metodologia de apreensão e extração de dados do dispositivo Android é uma
versão adaptada e simplificada da tese de mestrado de André Morum (Método
para Análise Pericial em Smartphone com Sistema Operacional Android, 2011).
A esta versão, acrescenta-se a fase de análise dos dados obtidos através das
técnicas e ferramentas apresentadas durante este trabalho. O diagrama a
seguir exemplifica o método proposto para este estudo de caso.
Na figura são apresentados dois cenários: telefone com o sistema Android com
e sem root e os respectivos procedimentos a serem adotados pelo analista em
cada caso. A partir deste método, é possível obter o máximo de informações do
dispositivo móvel, de maneira a documentar, resguardar e processar a
evidência da forma mais segura e menos intrusiva possível (Aquisição de
Evidências Digitais em Smartphones Android, 2011).
Para análise dos fatos que identificam a existência do malware foi utilizada
como base o artigo da Kindsight Security Labs cujo tema á análise do trojam
Zitmo para o AndroidOS.
74
Obter relatos do usuário sobre
comportamento suspeito
Telefone ligado?É possível extrair
dados do cartão?
não
Isolar rede
sim
Extrair dados do cartão de memória e substituir o cartão
sim
não
Ligar telefone não Ligar telefonesim
É possível isolar fisicamente a
rede?
Telefone bloqueado?
Obter senha com o usuário
sim
Extrair dados do cartão de memória
e avaliar sua substituição
Shell via ADB com super usuário?
nãoAtivar o modo de
depuraçãoEspelhar partições
do sistemasim
Extrair informações do sistema
acessíveis (dmesg, dumpsys, logcat)
Listar aplicativos instalados
Verificar apps com acesso a rede (3g,
wi-fi)
Simular o envio de informações por
SMS e outras conexões
Informações pessoais
interceptadas?
Listar o app e analisar o IP de
destino
Aplicativo suspeito
identificado?
sim
Coverter o classes.dex em jar com a ferramenta
dex2jar
Descompilar o jar e suas classes com JD-
GUI
sim
Analisar o código fonte e arquivos
XML do APP
Malware encontrado?
Concluirsim
não
Desempacotar com o APKTools
não
Extrair o arquivo APK e instalar numa
AVD (sandbox)
não
não
Figura 39 – Diagrama de identificação e análise de malware Fonte: O Autor (Adaptado de Aquisição de Evidências Digitais em Smatphones Android, 2011).
75
5.2.1 O Malware Zitmo
O trojan Zitmo é a versão Android do malware Zeus que trabalha em conjunto
com o Zeus Banking Trojam para roubar informações da conta bancária do
usuário. Com o advento dos malwares para desktops, as instituições
financeiras passaram a enviar um número de autorização para transações
bancária (TAN) para o celular do usuário, numa tentativa de adicionar mais um
etapa de segurança, o Zitmo foi criado para anular essa etapa (Malware
Analysis Report, 2011).
Por ser um trojan, Zitmo pode ser parte de qualquer outro aplicativo. A infecção
começa com um ataque de phishing que pede ao usuário para fazer o
download de um aplicativo para PC que por sua vez direciona o usuário para o
download do app Android Trustter Rapport, infectado com o trojan. A vitima
acreditando se tratar de uma aplicação de segurança acaba com o dispositivo
infectado (Malware Analisis Report, 2011).
5.2.2 Identificação do Malware
Seguindo o diagrama para análise da existência de malware, o primeiro passo
é obter o relato do usuário do dispositivo Android suspeito de infecção pelo
malware. No caso, existe a suspeita de que as mensagens SMS recebidas pelo
dispositivo Android estão sendo enviadas para um servidor remoto. Uma
análise dos últimos aplicativos instalados leva a um provável candidato: o app
de segurança Trustter Rapport. A fim de reproduzir o mesmo cenário do
usuário, o APP foi baixado usando a mesma mensagem de phishing enviada
ao usuário e instalado em uma AVD (Malware Analisis Report, 2011).
76
Figura 40 – Instalação do APP Trusteer Rapport Fonte (O Autor, utilizando o AVD).
Como pode ser visto na figura 40, uma das permissões requisitadas pelo
aplicativo é o acesso as mensagens SMS. Comparando os processos em
execução depois da instalação é notado o novo processo em execução:
Figura 41 – Visualização dos processos em execução Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
Com a análise dos logs e com os relatos de comportamento suspeito informado
pelo usuário, é possível traçar a estratégia de análise para este app. Como a
extração do arquivo apk do aplicativo suspeito e sua instalação numa Android
Virtual Device (AVD), é criada uma sandbox para a analise isolado do app.
USER PID PPID VSIZE RSS WCHAN PC NAME root 1 0 816 464 ffffffff 00000000 S /init app_9 2473 10636 288576 29148 ffffffff 00000000 S com.android.mms app_120 3634 10636 326220 71196 ffffffff 00000000 S com.lge.launcher2 app_25 8426 10636 311072 51588 ffffffff 00000000 S com.nullsoft.winamp app_0 9134 10636 312908 38748 ffffffff 00000000 S com.whatsapp app_1 9186 10636 318672 37576 ffffffff 00000000 S com.google.process.location app_1 9198 10636 309268 33436 ffffffff 00000000 S com.google.android.gms app_37 9315 10636 293616 31792 ffffffff 00000000 S com.systemsecurity6.gms
77
Como já mencionado neste trabalho, o arquivo “.apk” dos aplicativos instalados
no Android fica no diretório “/data/app” (é necessário privilégio de root para
acessar), assim, se já foi feito root no dispositivo basta copiar o “apk” do
aplicativo suspeito para análise posterior em um desktop Ubuntu.
Figura 42 – Extração do arquivo apk do app suspeito Fonte: O Autor (utilizando o Android ADB Tools para Linux Ubuntu).
Antes da instalação do app na AVD, foi configurado o software Wireshark para
monitorar o tráfego de rede do emulador. Como apenas uma aplicação com
acesso ao serviço de mensagens continua em execução, caso haja o envio de
uma requisição pelo dispositivo Android a um host desconhecido, ela será uma
forte candidata a ser analisada.
Figura 43 – Analise do tráfego de rede do AVD pelo software Wireshark Fonte (Malware Analisis Report, 2011).
Pela figura 43, após o envio de uma mensagem SMS ao AVD, através de uma
conexão telnet, houve o envio de uma requisição a um servidor desconhecido,
portanto, o aplicativo é suspeito e deve ser analisado.
5.2.3 Engenharia Reversa e Análise do Arquivo APK
Figura 44 – Visualização do conteúdo do apk do app Zitmo Fonte: O Autor.
luffy@ubuntu:~$ adb pull /data/app/ Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D.apk
luffy@ubuntu:~/Downloads/Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D$ ll total 56 drwxrwxr-x 4 luffy luffy 4096 Nov 3 20:07 ./ drwxr-xr-x 6 luffy luffy 4096 Nov 3 20:08 ../ -rw-rw-r-- 1 luffy luffy 2736 Mai 29 2011 AndroidManifest.xml -rw-rw-r-- 1 luffy luffy 7660 Mai 29 2011 classes.dex drwx------ 2 luffy luffy 4096 Nov 3 20:07 META-INF/ drwx------ 6 luffy luffy 4096 Nov 3 20:07 res/ -rw-rw-r-- 1 luffy luffy 1800 Mai 29 2011 resources.arsc
78
O arquivo APK é um zip, de modo que após ser descompactado é possível ver
o seu conteúdo na figura 44:
Pasta META-INF – contém informações para verificar a segurança e
validade da aplicação apk.
Pasta res – recursos da aplicação como imagens, arquivos de layout,
sons, etc.
Arquivo AndroidManifest.xml – contém informações como as permissões
requeridas pela aplicação, nome do pacote, versão, etc.
Arquivo resources.arsc – arquivo binário obtido após a compilação.
Arquivo classes.dex – contém todas as classes Java da aplicação
compiladas para o conjunto de bytecodes interpretados pela Dalvik VM.
No caso dos arquivos XML, não é possível ver o seu conteúdo apenas
descompactando o APK, pois eles foram criptografados durante o
empacotamento. Nesse caso é utilizada a ferramenta APKTOOLS para o
desempacotamento do app. A execução e saída do uso da ferramenta seguem
na figura 45:
Figura 45 – Execução da ferramenta APKTools Fonte: O Autor (utilizando o APKTools em Linux Ubuntu).
O resultado é uma pasta com o mesmo nome do arquivo apk com a mesma
estrutura apresenta na descompactação. Agora é possível visualizar e analisar
os arquivos XML, mas para ver o código propriamente dito do aplicativo, é
preciso outra ferramenta, a dex2jar, para converter o arquivo “classes.dex” em
um jar, como na figura 46:
luffy@ubuntu:~/Downloads$ apktool d Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D.apk zitmo I: Baksmaling... I: Loading resource table... I: Loaded. I: Decoding AndroidManifest.xml with resources... I: Loading resource table from file: /home/luffy/apktool/framework/1.apk I: Loaded. I: Regular manifest package... I: Decoding file-resources... I: Decoding values */* XMLs... I: Done. I: Copying assets and libs...
79
Figura 46 – Execução da ferramenta dex2jar Fonte: O Autor (utilizando o dex2jar em Linux Ubuntu).
Após a execução da ferramenta é criado o arquivo “classes_dex2jar.jar” no
mesmo diretório do App descompactado e este, por sua vez, agora pode ter
seu código fonte analisado através de uma ferramenta de descompilação de
código Java, com o JD-GUI:
Figura 47 – Visualização do código do Zitmo no JD-GUI Fonte: O Autor (Utilizando o software JD-Gui).
Na figura 47 é mostrado o código fonte da classe MainService após a
descompilação. Nela, dois trechos chamam a atenção: a inicialização da thread
da classe interna SMSBlockerThread, que tem a função de interceptar
mensagens SMS recebidas e o trecho para extração da mensagem nessa
classe. Como já mencionado, o objetivo do trojan Zitmo é obter o código TAN
das mensagem SMS enviadas pelas instituições financeiras a seus clientes
como um passo adicional de segurança a transação bancária. Em outro trecho
luffy@ubuntu:~/Downloads$ dex2jar-0.0.9.15/dex2jar.sh Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D/classes.dex this cmd is deprecated, use the d2j-dex2jar if possible dex2jar version: translator-0.0.9.15 dex2jar Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D/classes.dex -> Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D/classes_dex2jar.jar Done.
80
do código fonte do APP a mensagem SMS é empacotada como um objeto
JSON e enviado via requisição POST a um servidor remoto, cuja URL está na
classe ServerSession (Malware Analisis Report, 2011).
5.3 CONCLUSÃO
O malware analisado se destaca pela combinação de spyware (envio de
informações do usuário para um servidor remoto) e falso aplicativo de
segurança. A identificação foi possível graças aos relatos do usuário e da
natureza spyware do malware, assim, a verificação dos aplicativos em
execução no Android, mais a listagem dos que possuem acesso ao serviço de
SMS e um monitoramento da rede, permitiram constatar a existência de um
malware suspeito, sua extração e posterior análise do código para conclusão
do caso.
Este estudo de caso mostrou como é possível não apenas extrair dados do
Android, mas também, com base no conhecimento do funcionamento do
sistema operacional, de quais são as informações relevantes e onde elas
estão, é possível identificar até mesmo a presença de um spyware no sistema.
Com a transição cada vez mais acentuada do desktop para os dispositivos
móveis, fica claro que os sistemas embarcados nestes dispositivos serão o
principal alvo de ataques de espionagem e, tão importante quanto a proteção é
a sua identificação.
81
CAPÍTULO 6. CONCLUSÃO
Neste trabalho foram apresentadas técnicas e ferramentas opensource para a
extração e análise dos dados de dispositivos com o sistema operacional
Android. Pelo fato dos dispositivos móveis ainda não serem a principal fonte
dos crimes virtuais, a análise forense neste meio ainda carece tanto de
técnicas quanto de ferramentas para sua execução. No entanto, mesmo com
estas dificuldades, foi possível apresentar as principais ferramentas para a
análise forense e suas aplicações práticas.
A análise forense quase sempre associada apenas a extração de informações
recebeu, durante o estudo de caso, um carácter investigativo durante a análise
de infecção de um dispositivo Android por um spyware. Este não foi apenas um
caso escolhido aleatoriamente, com a quantidade de malwares criados para o
Android aumentando a cada dia, as ferramentas de proteção podem não ser
capazes de detectar todas as pragas e, nesses casos, uma análise a fim de
detectar e isolar o equipamento infectado é de grande importância para a
segurança de todos.
Complementando o que foi publicado na tese de mestrado de André Motum de
Lima Simão, Proposta de Método para Análise Pericial em Smatphone com
Sistema Operacional Android, foi adicionada a fase de análise das informações
obtidas pelas técnicas de forense digital. Foi modo de apresentar uma
utilização diferente para o conhecimento adquirido sobre o sistema Android e
ao mesmo tempo não apenas repetir o que já foi feito em outro trabalho.
A maior dificuldade durante a pesquisa foi a total ausência de uma ferramenta
(comercial ou opensource) para análise de informações em partições YAFFS2.
O princípio básico da forense digital é mantar os dados inalterados e, num
processo judicial o analista forense pode encontrar dificuldades em explicar
porque o estado de um dispositivo foi alterado e de que forma.
6.1 TRABALHOS FUTUROS
Outro ponto que chamou a atenção neste trabalho, baseado nas técnicas de
análise e extração de dados apresentadas, é a falta de uma ferramenta de
análise com suporte ao sistema de arquivos YAFFS2 (Yet Another File
82
System), projetado especificamente para mídias de armazenamento do tipo
Flash NAND e largamente utilizado em dispositivos Android. O
desenvolvimento de uma ferramenta capaz de lidar com partições neste
formato facilitará muito o trabalho dos analistas forenses, além de tornar a
análise e extração de dados menos sujeita a erros e mais segura.
O estudo de caso deste trabalho sugere também uma nova e mais detalhada
pesquisa focada no método de análise de malware. Provavelmente com a
participação de entidades que são referência na área de segurança contra
malwares.
83
REFERENCIAS
A Castilho, Carlos. Android Malware Past, Present, and Future. Mobile Security
Working Group McAfee. Disponível em: <
http://www.mcafee.com/us/resources/white-papers/wp-android-malware-past-
present-future.pdf >. Acesso em: 26 de Outubro de 2013.
ACPO Good Pratice for Computer-Based Eletronic Evidence. 7Safe Information
Security. Acesso em 15 de Outubro de 2010. Disponível em: <
http://www.7safe.com/electronic_evidence/ACPO_guidelines_computer_eviden
ce.pdf>.
Adam J. Aviv, Katherine Gibson, Evan Mossop, Matt Blaze, and Jonathan M.
Smith. Smudge Attacks on Smartphone Touch Screens. 21 de Fevereiro de
2011. Disponível em: <
https://www.usenix.org/legacy/event/woot10/tech/full_papers/Aviv.pdf>.
Bornstein, D. Dalvik VM Internals. 2008 Google I/O Session 2008. Disponível
em: <https://sites.google.com/site/io/dalvik-vm-internals>. Acesso em: 31 de
março de 2013.
Business Week, Bloomberg. 2005. Disponível em <
http://www.businessweek.com/stories/2005-08-16/google-buys-android-for-its-
mobile-arsenal>. Acesso em 27 de Março de 2013.
Cannon, T. (n.d.). Android lock screen bypass.. Acessado em 15 de outubro de
2013. Disponível em: < http://www.mcafee.com/us/resources/white-papers/wp-
android-malware-past-present-future.pdf >.
Desai, Dhawal. Malware Analisis Report. Kindsight Security Labs. Setembro de
2011. Disponível em: <https://www.kindsight.net/sites/default/files/Android-
Trojan-Zitmo-final.pdf>. Acesso em 26 de Outubro de 2013.
Distefano, Alessandro; Mea, Gianluigi; Pace, Francesco. Android anti-forensics
through a local paradigma. Digital Investigation. 2010.
Ehringer, D. The Dalvik Virtual Machine Architeture. David Ehringer, março
2008. Disponível em:
84
<http://davidehringer.com/software/android/The_Dalvik_Virtual_Machine.pdf>.
Acesso em 31 de março de 2013.
Gadhavi, B. Analysis of the Emerging Android Market. The Faculty of the
Department of General Engineering, Sam Jose State University.
Gargenta, Marko. Learning Android. First Edition. Sebastopol, CA: O’Reilly
Media Inc, 2011.
Gartner, Inc. Gartner Says Smartphone Sales Grew 46.5 Percent in Second
Quarter of 2013 and Exceeded Feature Phone Sales for First Time. Disponível
em: <http://www.gartner.com/newsroom/id/2573415>. Acessado em: 13 de
Outubro de 2013.
Google Inc. Android Fundamentals. Android Developers, 2013. Disponível em:
<http://developer.android.com/guide/topics/connectivity/index.html>. Acesso
em: 26 março 2013.
Google Inc. Android Fundamentals. Android Developers, 2013. Disponível em:
< http://developer.android.com/about/dashboards/index.html>. Acesso em: 26
março 2013.
Hashimi, S.; Komatineni, S.; Maclean, D. Pro Android 2. 1ª edição. Ed; [S.1.]:
Apress, 2010. ISBN 978-1-4302-2659-8.
Hoog, Andrew. Android Forensics. First Edition. Waltham, MA. Elsevier Inc,
2011.
Lessard, Jeff; Kessler, Gary. Android Forensics: Simplifying Cell Phone
Examinations. Edith Cowan University. 2010.
Milbourne, Grayson; Orozco, Armando. Android Malware Exposed. Agosto de
2012. Webroot. Disponível em: <http://www.webroot.com/shared/pdf/Android-
Malware-Exposed.pdf>. Acesso em: 28 de Outubro de 2013.
Morum de Lima Simão, André. Proposta de Método para Análise Pericial em
Smatphone com Sistema Operacional Android. 2011. Tese de Mestrado.
Universidade de Brasília, Brasília.
85
Morum de L Simão, André; Sícoli, Fábio Caús; Peotta de Melo, Laerte; Deus,
Flávio Elias de; Sousa Júnior, Rafael Timóteo. Aquisição de Evidências Digitais
em Smatphones Android. Universidade de Brasília, Brasília, pp 92-99, Outubro
de 2011.
SQLite Documentation. SQLite, 2013. Disponível em:
<http://www.sqlite.org/docs.html>. Acesso em: 30 de abril de 2013.
W. Frank Ableson; Sen, Robi; King, Chris; Ortiz, C. Enrique . Android in Action.
Third Edition. Shelter Island, NY: Manning Publications Co, 2012