[Texto] FORENSE DIGITAL EM DISPOSITIVOS MÓVEIS COM SISTEMA OPERACIONAL ANDROID

1.982 visualizações

Publicada em

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.

Publicada em: Celular

[Texto] FORENSE DIGITAL EM DISPOSITIVOS MÓVEIS COM SISTEMA OPERACIONAL ANDROID

  1. 1. 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
  2. 2. 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.
  3. 3. 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.
  4. 4. “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
  5. 5. 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.
  6. 6. 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.
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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úmero de Assinantes Ano Assinantes de telefonia celular Assinantes
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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.
  18. 18. 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).
  19. 19. 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.
  20. 20. 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
  21. 21. 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).
  22. 22. 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).
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. 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>.androidavdandroid422.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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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)
  31. 31. 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):
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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:
  37. 37. 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):
  38. 38. 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 {name=valdemirvjr@gmail.com, type=com.facebook.auth.login} Account {name=valdemirvjr@gmail.com, type=com.dropbox.android.account} Account {name=valdemirvjr@gmail.com, 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
  39. 39. 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) ------
  40. 40. 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: book@viaforensics.com 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
  41. 41. 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
  42. 42. 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).
  43. 43. 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>
  44. 44. 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:
  45. 45. 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>
  46. 46. 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
  47. 47. 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.
  48. 48. 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
  49. 49. 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).
  50. 50. 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).
  51. 51. 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:
  52. 52. 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");
  53. 53. 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).
  54. 54. 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
  55. 55. 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:
  56. 56. 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
  57. 57. 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
  58. 58. 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.
  59. 59. 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
  60. 60. 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).
  61. 61. 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
  62. 62. 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).

×