Pró-Reitoria de Pós-Graduação e Pesquisa Lato Sensu em Perícia Digital Trabalho de Conclusão de Curso

Transcrição

1 Pró-Reitoria de Pós-Graduação e Pesquisa Lato Sensu em Perícia Digital Trabalho de Conclusão de Curso ASPECTOS DE SEGURANÇA DA PLATAFORMA ANDROID NA CONDUÇÃO DE PERÍCIAS FORENSES EM DISPOSITIVOS MÓVEIS CLAUDIO ROSA DE CAMARGO JUNIOR Autor: Claudio Rosa de Camargo Junior Orientador: Profº Esp. João Eriberto Mota Filho PERÍCIA FORENSE EM DISPOSITIVOS MÓVEIS COM SISTEMA OPERACIONAL ANDROID Brasília - DF 2014

2 ASPECTOS DE SEGURANÇA DA PLATAFORMA ANDROID NA CONDUÇÃO DE PERÍCIAS FORENSES EM DISPOSITIVOS MÓVEIS CLAUDIO ROSA DE CAMARGO JUNIOR Artigo apresentado ao curso de especialização em Perícia Digital da Universidade Católica de Brasília, como requisito parcial para obtenção do Título de Especialista em Perícia Digital. Orientador: Prof. Esp. João Eriberto Mota Filho Brasília 2014

3 2 Artigo de autoria de Claudio Rosa de Camargo Junior, intitulado ASPECTOS DE SEGURANÇA DA PLATAFORMA ANDROID NA CONDUÇÃO DE PERÍCIAS FORENSES EM DISPOSITIVOS MÓVEIS apresentado como requisito parcial para obtenção do grau de Especialista em Perícia Digital da Universidade Católica de Brasília, em 30 de maio de 2014, defendido e aprovado pela banca examinadora abaixo assinada: Prof. Esp. João Eriberto Mota Filho Orientador Perícia Digital - UCB Prof. Msc. Paulo Roberto Corrêa Leão Perícia Digital - UCB Brasília 2014

4 3 ASPECTOS DE SEGURANÇA DA PLATAFORMA ANDROID NA CONDUÇÃO DE PERÍCIAS FORENSES EM DISPOSITIVOS MÓVEIS CLAUDIO ROSA DE CAMARGO JUNIOR RESUMO A análise pericial de dispositivos Android tende a ser um das atividades mais realizadas por peritos forenses devido à quantidade de usuários e de dispositivos móveis existentes em funcionamento, que podem conter informações vitais na condução de perícias forenses. Existem publicados vários artigos sobre procedimentos de exames em aparelhos celulares e computadores bem difundidos, porém não abordam com profundidade as barreiras e fatores dificultadores que podem impedir o prosseguimento da análise pericial, face à enorme quantidade de dispositivos. Diante de um cenário, este artigo tem como objetivo explicitar sobre os métodos de segurança da plataforma Android e como o perito pode circundá-los para que a perícia possa ser realizada, sem a ajuda de aplicativos proprietários e demonstrar os limites do alcance das técnicas empregadas nas diversas versões da plataforma Android. O artigo também demonstra, através de pesquisa bibliográfica e estudo de caso que um conhecimento técnico aprofundado do perito sobre o sistema operacional Android pode significar a diferença entre a realização ou não de uma perícia. Palavras-chave: Perícia forense. Dispositivos móveis. Bloqueio de tela. Criptografia. Android 1. INTRODUÇÃO O advento da expansão de utilização dos dispositivos móveis, com especial atenção aos smartphones e tablets mudou radicalmente o panorama da perícia forense computacional nos últimos anos, já que os dados estatísticos apontam para a aquisição de sete bilhões de smartphones até 2017, o mesmo número de seres humanos no planeta. De todos os dispositivos eletrônicos atualmente existentes, o smartphone é o mais próximo do usuário, contendo lista de contatos, mensagens, aplicativos, histórico de pesquisas e dados sobre o proprietário que tornam este dispositivo, seguido do tablet, como essenciais em investigações criminais. Atualmente não existem soluções livres que realizem os procedimentos de perícia forense de forma específica em dispositivos móveis, portanto, faz-se necessário que o perito conheça determinadas técnicas e como empregá-las apropriadamente. Para tanto, o artigo teve como objetivo explorar as principais características de segurança da plataforma Android, a mais utilizada em todo o mundo em dispositivos móveis, e suas implicações na condução de perícias, assim como demonstrar técnicas e ferramentas que possibilitem o perito ultrapassar as barreiras de segurança do citado sistema operacional, dentre os quais a criptografia dos dados do dispositivo e os bloqueios de tela, focando em soluções livres existentes. Além disso, o artigo também teve a finalidade de explicitar quais

5 4 tipos de conhecimento são necessários para que o perito realize perícias sem a utilização de ferramentas licenciadas. Atualmente no mercado existem várias ferramentas para realização de perícias em dispositivos móveis, tais como EnCase, Oxygen Forensic Suit e Paraben Device Seizure. Todas essas possuem métodos programáticos baseados em falhas da arquitetura Android em suas versões, assim como em técnicas fundamentadas na arquitetura de hardware de cada aparelho, porém, possuem um custo elevado de aquisição e manutenção de licença. Além deste fator, não existem garantias que as mesmas possuam total compatibilidade na combinação de dispositivo e sistema operacional, por vezes necessitando que o perito realize procedimentos para a realização de perícias. Os procedimentos mostrados neste artigo por vezes necessitam que o perito possua acesso root ao dispositivo, portanto, salienta-se que este artigo não tem como objetivo explicar como rootear um dispositivo Android. 2. METODOLOGIA Foram utilizadas neste artigo a metodologia de pesquisa bibliográfica, com o objetivo de pesquisar os processos atualmente utilizados no contorno dos métodos de segurança do sistema operacional Android, além da pesquisa experimental em vários dispositivos físicos (Smartphones) e virtualizados para comprovar a eficácia e a eficiência dos métodos pesquisados. A realização do estudo de caso em engenharia reversa com o programa de mensageria Whatsapp foi realizada com o objetivo de explicitar técnicas que podem ser utilizadas para aquisição lógica de dados quando os mesmos são protegidos por criptografia embutidas nos softwares proprietários MATERIAIS Para fim de experimentação na condução de perícias em dispositivos Android, foram utilizados alguns dispositivos físicos tais como o Motorola Razr XT910 (Android 3.0), Sony Xperia Z1 (Android 4.3) e Motorola Defy (Android 2.1), além de virtualizações nas demais versões do Android através do AVD Manager listadas na Quadro 1. Quadro 1 Lista de virtualizações utilizadas Versão Dispositivo físico baseado para virtualização Motorola Defy 3.0 Motorola Razr XT Sony Xperia Z Sony Xperia Z Sony Xperia Z1 4.3 Sony Xperia Z1 4.4 Sony Xperia Z FERRAMENTAS UTILIZADAS Conforme recomendado pelo SWGDE (2013), para a realização de perícia em dispositivos móveis são necessários equipamentos e ferramentas, algumas das quais diferem ligeiramente dos equipamentos utilizados em perícias de computadores, tais como: a) Estação de trabalho forense;

6 5 b) Software de análise forense; c) Blindagem de rádio frequência (Eletromagnetic Shielding); d) Dispositivos de extração de hardware (JTAG Joint Test Action Group); e) Hardware / software bloqueadores de gravação (Write Blockers); f) Leitor de cartão SIM; g) Cabos de carregamento adequados e kit de carregamento da bateria universal; h) Cabos ou suportes de dados; i) Software do fabricante e de terceiros; j) Mídias em branco e/ou estéreis (HD / CD / DVD ou outros dispositivos removíveis); k) Câmera digital e filmadora. Caso o perito não possua acesso a determinados equipamentos recomendados acima, é possível preparar uma estação de trabalho forense, no caso, um computador, para realizar a perícia, evitando contaminação do dispositivo, porém, é necessário que sejam observadas boas práticas na instalação do sistema operacional do computador e a instalação de software específico para cada sistema operacional de dispositivo móvel. Os procedimentos de análise forense para este artigo foram realizados utilizando uma estação de trabalho Linux, com a distribuição Ubuntu versão LTS (64-bits). Segundo o Android (2014) as distribuições Android são compiladas utilizando este sistema operacional e é altamente recomendado utilizar esta versão, que permite montar ambientes de desenvolvimento com a SDK Android e realizar pesquisas mais aprofundadas nos aspectos das mais variadas versões do sistema operacional. Além dos procedimentos acima adotados, o sistema operacional foi configurado para que não monte automaticamente os dispositivos USB conectados ao computador, impedindo que ocorra contaminação dos dados no dispositivo. Outra distribuição Linux de extrema importância para o perito é a Santoku 0.4, versão mais atual da distribuição, que têm como objetivo a realização de perícias em dispositivos móveis. Esta versão do Android foi incluída em uma máquina virtual (VirtualBox) na instalação do Ubuntu. Nos estudos de caso realizados para este artigo somente não foram utilizados os seguintes dispositivos: JTAG, bloqueadores de gravação e blindagem de rádio frequência. 3. CENÁRIOS POSSIVEIS EM DISPOSITIVOS MÓVEIS De acordo com Hogg (2012), a principal atividade realizada na prática forense em dispositivos Android é a aquisição de dados armazenados no dispositivo, porém, existem diversos cenários que podem ser encontrados pelo perito que podem facilitar ou dificultar a aquisição de dados. Barreiras de proteção, como criptografia da unidade de armazenamento do dispositivo, bloqueadores de tela (screen locks) e suporte ao desenvolvedor ativado (modo debug USB) são peças chaves para determinar o grau de dificuldade na aquisição de dados. Poucas obras literárias abordam com profundidade cada um dos aspectos de segurança e tampouco quais são as melhores práticas a serem abordadas pelo perito digital para realizar o processo de aquisição de dados e responder aos quesitos de uma investigação. Os fatores abordados como dificultadores na aquisição de dados no processo de perícia foram: - Dispositivo ligado ou desligado; - Dispositivo com unidade de armazenamento interno encriptado ou aberto; - Dispositivo com um usuário root ativado ou desativado; - Dispositivo que possua ou não bloqueio de tela;

7 6 - Dispositivo estiver habilitado ou não o modo de debug (modo de desenvolvimento). Baseados nestas características classifica-se, de modo geral, as dificuldades de aquisição de dados em baixa, média e alta complexidade: a) baixa complexidade: Os cenários de baixa complexidade para aquisição de dados e informações de dispositivos têm uma característica em comum: nenhum possui qualquer mecanismo de bloqueio que impeça a operacionalização do dispositivo. De acordo com Hogg (2012), dispositivos que não possuem mecanismos de segurança ativos são periciados utilizando os métodos comumente utilizados na perícia forense computacional tradicional, porém, determinados aspectos que se aplicam somente a dispositivos móveis devem ser observados; b) média complexidade: são os que apresentam somente o bloqueio de tela, em qualquer um dos seus tipos, dentre os quais são: desbloqueio por reconhecimento facial, desbloqueio padrão, PIN (senha numérica) e senha alfanumérica. O dispositivo estar ligado pode ser decisivo no momento da apreensão do dispositivo, pois existe a possibilidade de que o mesmo não esteja bloqueado por nenhum método no momento da apreensão. Quando o dispositivo está desligado e constata-se o bloqueio do mesmo por quaisquer métodos já citados, faz-se necessária a intervenção do perito para circundar o método de bloqueio. c) alta complexidade: Os dispositivos enquadrados neste cenário apresentam as características que podem impedir a aquisição de dados do dispositivo, dentre as quais os bloqueios de tela e a criptografia do dispositivo ativada. Como aplicado nos cenários de média complexidade, o dispositivo pode não estar bloqueado por nenhum método no momento da apreensão. 4. PROCEDIMENTOS PARA TRATAMENTO DE DISPOSITIVOS ANDROID De acordo com Hogg (2012), um dos grandes desafios para os analistas forenses é a elaboração de protocolos para lidar com o dispositivo antes do perito tomar custódia direta. É observado que muitas vezes os dispositivos não são adequadamente tratados pelos responsáveis pelo primeiro contato com o mesmo, levando a uma tendência de examinar imediatamente o dispositivo, o que acarreta quase que inevitavelmente a alteração de dados e potencial perda de acesso ao dispositivo. Diferentemente do que ocorre quando há apreensão de dispositivos informáticos, como um computador pessoal ou laptop, é necessária especial atenção quanto a algumas características inerentes a dispositivos como smartphones e tablets ISOLANDO O DISPOSITIVO DE CONEXÕES DE REDE De acordo com Simão (2011), quando da apreensão do dispositivo é necessário verificar se existem conexões de rede ativas no dispositivo, tendo em vista a possibilidade de usuários autorizados no dispositivo executarem remotamente comandos através de aplicativos que podem apagar completamente dados do usuário, transferir informação sensível para a investigação para computadores ou servidores remotos.

8 7 O processo que apaga os dados remotamente em um dispositivo Android realiza a operação de wipe, gravando bit 0 em todas as áreas de montagem do filesystem com dados do usuário. De acordo com Hogg (2012), algumas ações podem ser tomadas para evitar o problema descrito e preservar o estado do dispositivo para posterior análise conforme Quadro 2. Quadro 2 - Procedimentos para isolamento de dispositivos de conexões de rede Versão do Android Técnica Vantagem Desvantagem 3.0 ou inferior Colocar o dispositivo em Modo Avião (Airplane mode). Requer acesso completo ao dispositivo. Os processos do dispositivo continuam a rodar e dados temporais permanecem intactos. Desabilita conexões Wi-fi Modificação de configuração do dispositivo. 3.0 ou superior Colocar o dispositivo em Modo Avião (Airplane mode). Não requer acesso especial Não requer acesso aos menus internos do sistema operacional. Os processos do dispositivo continuam a rodar e dados temporais permanecem intactos. Desabilita conexões Wi-fi Modificação de configuração do dispositivo. Qualquer versão Qualquer versão Qualquer versão Remoção do cartão SIM em caso de dispositivos GSM Suspender a conta de celular na operadora Inserir o dispositivo em um invólucro de isolamento, como uma sacola, caixa ou sala Faraday. Fácil de remover, efetivo em desabilitar as conexões de voz, SMS e transmissão de dados Efetivo em desabilitar toda transmissão de voz, SMS e transmissões de dados de qualquer telefone Previne vários tipos de transmissão de redes Qualquer versão Desligar o dispositivo Totalmente efetivo em prevenir toda forma de comunicação em rede Fonte: Hogg (2012) Não desabilita conexões Wi-fi, Bluetooth e outros tipos de conexões. Pode não funcionar em dispositivos que não sejam GSM, incluindo dispositivos CDMA e IDEN O processo demanda tempo e depende de uma ordem judicial para ser executada pela operadora. Não desabilita conexões Wi-fi e bluetooth Ao impedir que os sinais de transmissão cheguem ao dispositivo, o mesmo continuará a procurar redes disponíveis, o que consome consideravelmente a bateria do dispositivo. O estado do dispositivo é alterado e dados temporais (voláteis) são perdidos. Possibilidade de travamento do dispositivo através de mecanismo de criptografia e/ou bloqueio de tela

9 8 5. MÉTODOS DE BLOQUEIO DE TELA Os métodos de bloqueio de tela são formas de bloqueio do dispositivo Android a fim de aumentar a segurança dos dados e a privacidade dos seus proprietários. Segundo Hogg (2012), nem sempre é possível contornar este método de segurança da plataforma Android. Recomenda-se aos agentes que realizam a apreensão do dispositivo que desabilite ou contorne o método de bloqueio de tela, caso o dispositivo apresente condições para tal ação. Ainda segundo Hogg (2012), caso o dispositivo Android encontre-se com a tela desbloqueada, será necessário modificar as configurações do aparelho, tais como: - Modificando o parâmetro de tempo do bloqueio automático do dispositivo. No Android é possível encontrar esta opção acessando o aplicativo de configuração e, em seguida, adentrar na opção Segurança, bastando localizar a opção Bloquear automaticamente e escolher o tempo máximo permitido (30 minutos). O tempo máximo de espera para bloqueio automático do dispositivo poderá variar de acordo com a versão do Android. - Habilitando o modo debug, também conhecido como modo desenvolvedor, que possibilita ao perito conectar-se via ADB Shell (Android Debug Bridge) e realizar ações para extração lógica ou física de dados do dispositivo. Após a versão 3.0 do Android, o modo de desenvolvedor por padrão é oculto ao usuário, devendo realizar um procedimento nas configurações do dispositivo para torná-lo visível. No Android bastará acessar o aplicativo de configuração e, em seguida, adentrar na opção Sobre o telefone. Localizar o campo Número da versão e tocar neste campo de 6 a 7 vezes, sendo que será exibida uma mensagem informando a quantidade de vezes restantes que ainda são necessários toques neste item para habilitar o modo de desenvolvedor. Retornando ao menu do aplicativo de configuração, localizar a opção Opções do desenvolvedor e, por fim, habilitar a opção Depuração USB". - Também ativando a opção Permanecer ativo, pois esta opção previne que o dispositivo seja bloqueado por inatividade enquanto estiver sendo carregado através do carregador ou conectado via USB em uma estação de trabalho forense BLOQUEIO DE TELA PADRÃO O padrão de bloqueio de tela do Android, ver Figura 1, consiste em uma tela onde é possível gravar um padrão, ligando-se pontos na tela a fim de que somente o usuário conhecedor de tal padrão possa desbloqueá-lo. Nas versões Android anteriores a a quantidade mínima exigida para criação de um padrão de bloqueio era três posições. Desde o Android versão o mínimo de pontos a serem ligados são quatro, onde pode-se deduzir, através de análise combinatória, a quantidade de possíveis combinações, dependendo da quantidade de pontos utilizados pelo usuário, variando entre 1624 combinações com 4 pontos até no máximo de combinações utilizando-se 9 pontos. Figura 1 Bloqueio de tela padrão do Android

10 CIRCUNDANDO O BLOQUEIO DE TELA PADRÃO Segundo Spreitzenbarth (2012), o bloqueio de tela são pontos de uma matriz, tendo como ponto inicial o primeiro ponto do canto superior esquerdo (posição 0) terminando na posição 8, no canto inferior direito. Quando gravado pelo usuário, o padrão de bloqueio é armazenado em um arquivo especial denominado gesture.key no diretório /data/system, sendo que a informação é armazenada como um hash SHA-1 do padrão gravado pelo usuário. Ainda de acordo com Spreitzenbarth (2012), existem duas formas de contornar o bloqueio de tela padrão: possuindo acesso root ao smartphone ou com a ajuda de uma interface JTAG. De acordo com o autor, caso o perito possua acesso root ao smartphone e pela quantidade relativamente pequena de combinações, é possível realizar colisões de hash SHA-1 de acordo com o armazenamento da informação no arquivo gesture.key, pelo qual armazena o bloqueio de tela como células de uma matriz (array). Para gerar uma lista de colisões, Spreitzenbarth (2012) sugere que se utilize um algoritmo que utilize a biblioteca LockPatternView do Android para gerar todas as possíveis combinações e, consequentemente os hashes de comparação. Caso o dispositivo não possua um usuário root para realizar os procedimentos citados, é necessário utilizar uma interface JTAG para executar a captura de dados. Foi constatado que desde a versão 2.3 o método de armazenamento do padrão de bloqueio de tela não sofreu alterações, permitindo que o método apresentado por Spreitzenbarth (2012) fosse realizado com sucesso em qualquer dispositivo com usuário root. De acordo com Hogg (2012), caso o dispositivo apresente o bloqueio de tela é altamente recomendável que o agente apreendedor não toque na tela, pois será possível utilizar uma técnica denominada Smudge Attack (ataque de mancha), conforme Figura 2. Esta técnica demonstrada por Aviv et al (2014) tem como principal característica o emprego de uma câmera, conforme os autores: Nossos experimentos fotográficos sugerem que a superfície limpa de uma tela touch screen é principalmente, mas não exclusivamente, reflexiva, enquanto uma mancha é principalmente, mas não exclusivamente difusa. Nós descobrimos que praticamente qualquer fonte de iluminação direcional que não está posicionado exatamente em um ângulo complementar para a câmera irá processar uma imagem recuperável da mancha. É necessário muito pouco ajuste na foto para ver o padrão, mas as imagens geralmente são melhores quando a captura de foto foi superexposta por 2-3 f-stops (4-8 tempos de exposição correta ) (AVIV et al, 2014). Figura 2 Visualização das manchas na tela do dispositivo

11 BLOQUEIO DE TELA POR PIN E SENHA ALFANUMÉRICA Os bloqueios de tela por PIN e senha alfanumérica, veja Figura 3, são senhas em que o usuário realiza a inserção de uma senha do tipo numérica (no caso do PIN) ou alfanumérica para proteção do dispositivo. De maneira semelhante ao bloqueio de tela padrão, segundo Spreitzenbarth (pag. 3, 2012), caso o perito esteja lidando com um dispositivo rooteado e o modo debug via USB estiver habilitado, basta realizar o dump do arquivo password.key localizado no diretório /data/system. O sal 1 utilizado no armazenamento criptografado da senha é encontrado em um banco de dados SQLite denominado settings.db, localizado no diretório /data/data/com.android.providers.settings/databases. O sal é armazenado utilizando hash SHA1 e a senha alfanumérica ou PIN armazenada utilizando hash MD5. Um ataque de força bruta pode ser realizado utilizando como base o método passwordtohash(string password), possuindo o sal utilizado no hash do PIN ou senha. Segundo Sprintzenbarth (pag.3, 2012), outra forma de realizar tal procedimento é através de interface JTAG. Figura 3 Bloqueio de tela por PIN e senha 5.3. BLOQUEIO DE TELA POR RECONHECIMENTO FACIAL O bloqueio de tela por reconhecimento facial está presente desde a versão 4.0 do Android e, segundo Spreitzenbarth (2012), esta proteção não possui efetivamente um reconhecimento facial dotado de alta precisão, tendo em vista a quantidade de vídeos disponibilizados no YouTube em que usuários desbloquearam dispositivos smartphone somente com o emprego de uma fotografia do dono do dispositivo. Tal artifício pode ser utilizado por peritos em dispositivos bloqueados por reconhecimento facial. Testes foram realizados desde a versão 4.0 até a versão 4.4 (KitKat) e foi possível realizar o desbloqueio do dispositivo sem quaisquer dificuldades. Figura 4 Tela de bloqueio por reconhecimento facial 1 Sal ou Salt, é uma sequência aleatória de dados utilizados para modificar um hash de senha e pode ser adicionado ao hash para evitar ataques por dicionário (baseado em colisão), fazendo com que uma determinada senha utilizada duas vezes não possua o mesmo hash ao ser armazenada (PATEL et al, 2014).

12 MÉTODOS ALTERNATIVOS DE CIRCUNDAR BLOQUEIOS Segundo Hogg (2012), existem métodos alternativos que podem ser utilizados para circundar os bloqueios de tela, caso os métodos descritos anteriormente falhem, sendo considerados métodos secundários a serem utilizados pelo perito forense Modo de Recuperação De acordo com Hogg (2012, pág. 335), uma técnica para contornar os métodos de bloqueio de tela apresentados anteriormente é a utilização do modo de recuperação presente nos dispositivos Android. O modo de recuperação geralmente é encontrado em ROM modificadas por usuários, que ao instalarem a ROM modificada no dispositivo permite que o mesmo execute operações como usuário root de forma simplificada. Cada dispositivo possui distintamente procedimentos e combinação de botões para que entre no modo de recuperação. Os métodos de bloqueio são contornados porque o dispositivo não é iniciado em modo normal, sendo possível montar as partições de dados somente como leitura. É recomendado que os analistas forenses tentem inicializar o dispositivo em modo de recuperação quando o mesmo é apreendido desligado. Caso o dispositivo esteja ligado e possua bloqueio de tela, é necessário verificar se o modo de desenvolvedor está ativado via ADB Shell e considerar a utilização de um smudge attack Usando usuário e senha do Google Como alternativa para contornar os métodos de bloqueio de tela dos dispositivos Android, segundo Hogg (2012, pág. 340) é possível utilizar o usuário e senha da conta do Google registrada no dispositivo para redefinir a senha ou padrão de proteção do Android. Após certa quantidade de tentativas mal sucedidas na inserção de senha ou padrão de bloqueio de tela é exibida a opção para que o usuário redefina a senha confirmando sua conta e senha do Google. Caso o perito não possua tais dados, mas a autoridade investigadora julgue prudente a quebra ou ainda reiniciar a senha da conta do Google através de mandado judicial, é possível redefinir a senha de proteção e ter acesso ao dispositivo Utilizando o aplicativo Screen Lock Bypass Pro Este método proposto por Cannon (2013) consiste na instalação do aplicativo Screen Lock Bypass Pro no dispositivo a ser periciado, sendo que o seu funcionamento é baseado na própria arquitetura de aplicativos Android, em que o sistema determina uma série de mensagens de broadcast que um aplicativo pode receber, como SMS recebidos ou desconectado do Wi-fi. A aplicação registra a necessidade de receber mensagens de broadcast na declaração de permissões necessárias da aplicação pelo desenvolvedor, sendo que tais mensagens podem ser recebidas em tempo de execução da aplicação e, para certos tipos de mensagens, no momento da instalação da aplicação. Quando uma mensagem é recebida no dispositivo móvel, a mesma é enviada para o aplicativo que, se não estiver em execução, é iniciado imediatamente. O aplicativo de Cannon utiliza a declaração de notificações broadcast do tipo

13 12 android.intent.action.package_added, ou seja, quando um novo pacote/aplicação é instalado o aplicativo é notificado, fazendo com que o mesmo seja executado. O aplicativo ao inicializar faz chamada ao método disablekeyguard() do pacote KeyguardManager, que desabilita o bloqueio de tela enquanto o aplicativo estiver em execução, permitindo a mudança do padrão de bloqueio. Segundo o autor, é necessário realizar a instalação do aplicativo através do site do Google Play e em seguida adicionar qualquer outro aplicativo para que o Screen Lock Bypass Pro seja executado. Em testes realizados nos dispositivos físicos e virtuais foi possível circundar os bloqueios de tela, porém o aplicativo não funciona em dispositivos com o Android versão 4.0 ou superior, assim como informado pelo próprio autor do aplicativo na documentação oficial da solução. 6. CRIPTOGRAFIA DE DISPOSITIVOS ANDROID De acordo com Google (2014), a criptografia Android é suportada desde a versão 3.0, baseada no dm-crypt, que é um subsistema de encriptação de disco presente no kernel Linux desde a versão 2.6. A criptografia de dispositivo Android permite que somente o detentor da senha alfanumérica possa descriptografar o dispositivo ao ligar, portanto, conseguindo com que os dados não estejam cifrados no momento da execução do sistema operacional Android. Nos cenários de alta complexidade, caso o dispositivo esteja desligado no momento da apreensão e for detectada a presença de senha de proteção criptográfica, é necessário que o perito realize as seguintes verificações: a. Se o dispositivo possui acesso via ADB para verificar se o bootloader e/ou o fastboot estão ativados no dispositivo através do comando adb bootloader e adb fastboot. b. Caso o dispositivo possua o bootloader ativado é possível utilizar o Linux Santoku 0.4 para realizar um ataque de força bruta para descobrir a senha de criptografia através da ferramenta Android Brute Force Encryption tool. c. Caso o dispositivo não possua o bootloader ativado não é possível realizar um ataque de força bruta, devendo o perito optar por técnicas diferentes, tais como técnicas de engenharia social, utilização de ferramentas forenses que possuam nível de acesso baseada em trava de software ou o uso de interface JTAG para realizar a aquisição física de dados, replicando-os em uma maquina virtual Android. 7. ARMAZENAMENTO DE DADOS DE APLICATIVOS De acordo com Hogg (2012), todos os aplicativos possuem uma estrutura de diretórios semelhantes, onde os dados gerados pela aplicação são armazenados no diretório /data/data de cada aplicação. Os dados da aplicação podem ser armazenados em arquivos do tipo.db, que são base de dados SQLite ou quaisquer outro tipo de arquivo que podem armazenar informações (CSV, XML e etc). Por vezes os dados são armazenados sem qualquer meio de proteção, tais como criptografia simétrica ou cifra dos dados armazenados. Durante o estudo de caso de engenharia reversa demontrado neste artigo, foi verificado que aplicações instaladas no dispositivo, como o programa de mensageria

14 13 Whatsapp, armazenam informações geradas pelo usuário em sua totalidade na memória interna do dispositivo, enquanto é realizado um backup parcial na memória externa. A diferença entre ambas é o método utilizado para criptografar o conteúdo do banco de dados. Demais softwares de mensageria, como o Facebook, Skype e entre outros armazenam informações de maneira semelhante, porém, necessitam de análise individual para verificar as regras de armazenamento de dados. O método utilizado para extrair informações relevantes para quebrar a criptografia de arquivos armazenados por aplicativos foi proposto por MISRA e DUBEY (2013, pag. 170), que é o processo de engenharia reversa em aplicações Android. Os autores apresentam este método como principal forma de identificar supostos malware em dispositivos, mas também como uma forma de descobrir potenciais problemas de segurança. Para realizar tal análise foram necessárias as seguintes ferramentas: - jd-gui, um decompilador Java; - dex2jar, um conjunto de componentes que auxiliam a extração de informações importantes de um APK, além de fornecer suporte a reverter ofuscação de código-fonte. 8. ESTUDO DE CASO DE ENGENHARIA REVERSA O arquivo de instalação do WhatsApp pode ser facilmente encontrado no site do fabricante ( De acordo com o Blum (2013), um arquivo APK nada mais é do que um arquivo compactado que contém todos demais necessários para a distribuição de um aplicativo e possibilitar sua instalação. Bastará descompactar o arquivo APK e será possível verificar toda a estrutura de pastas e arquivos, dentre as quais encontramos o diretório META-INF, que possui arquivos de meta informações, tais como o arquivo MANIFEST.MF, o arquivo WHATSAPP.DSA que é a chave de assinatura da aplicação e o arquivo WHATSAPP.SF, que é a lista de recursos (arquivos) utilizados na aplicação com seus respectivos hashes SHA-1. O diretório LIB contém códigos compilados específicos para determinada arquitetura de processador, tais como processadores baseados na arquitetura ARM, ARMv7, x86 e entre outros, podendo possuir mais diretórios do que os listados acima. O diretório RES contém recursos não compilados no arquivo resources.arsc, sendo que arquivos de imagem, som, XML, layouts de telas do aplicativo e demais recursos que não são passíveis de compilação podem ser encontrados neste diretório. O arquivo classes.dex é o arquivo chave onde será realizada toda a engenharia reversa no código fonte para análise. Um arquivo.dex nada mais é do que as classes convertidas do bytecode Java para o bytecode da máquina virtual Dalvik. Para tanto é necessário executar o comando abaixo para converter o.dex e um arquivo.jar, conforme demonstrado no Quadro 3. Quadro 3 Comando para conversão de arquivo.dex para um arquivo.jar root@winterfell-virtualbox:/home/claudio/downloads# sh /home/claudio/downloads/dex2jar /d2jdex2jar.sh /home/claudio/downloads/whatsapp.apk dex2jar /home/claudio/downloads/whatsapp.apk -> WhatsApp-dex2jar.jar Após a geração do arquivo.jar, realizamos a leitura do mesmo utilizando o aplicativo JD-GUI, onde é possível verificar todo o código fonte da solução. Atualmente o código fonte gerado passa por um processo de ofuscação de código, que, segundo o Google (2013), está integrado ao processo de build do Android, sendo esta solução denominada

15 14 ProGuard. Segundo Misra e Dubey (2013, pag. 70) o ProGuard diminui e ofusca arquivos de classe Java, removendo e detectando classes não utilizadas, campos, métodos e demais elementos do código-fonte. As variáveis podem ser renomeadas para nomes mais curtos e por vezes sem sentido, exigindo que um examinador ou atacante do código demore muito mais tempo para realizar tal intento. Seu uso não é obrigatório, porém é altamente recomendado aos desenvolvedores para aumentar a segurança das suas aplicações e dificultar o processo de engenharia reversa. Para realizar o processo reverso da ofuscação é necessário converter as cadeias de bytecode Dalvik de acordo com a documentação oficial disponibilizada no endereço Após converter as cadeias de bytecode Dalvik é necessário realizar um processo para aplicar os padrões de substituição encontrados no tratamento do bytecode para depois transformá-lo em bytecode Java e, por fim, realizar a visualização das classes e métodos com as informações através do aplicativo JD-Gui. Desta maneira pode-se encontrar as informações relevantes para quebrar a criptografia dos arquivos SQLite onde as mensagens e demais informações são armazenadas. A criptografia utilizada no WhatsApp no armazenamento interno do dispositivo Android é a AES-192-BCE, tendo como chave simétrica 346a23652a46392b4d73257c67317e352e c e, para realizar a descriptografia do arquivos.crypt, faz-se necessária a cópia dos mesmos via adb pull, preferencialmente para a estação forense do perito, como evidenciado no Quadro 4. Quadro 4 Resultado da cópia dos arquivos via adb pull para a estação forense root@winterfell-virtualbox:/home/claudio/documents/whatsapp# ls -la total 5380 drwxrwxr-x 2 root root 4096 Feb 22 02:06. drwxr-xr-x 4 claudio claudio Feb 18 00:48.. -rw root root 0 Jan 31 20:50 -column -rw-r--r-- 1 root root Jan 31 21:12 mensagens1.csv -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore db.crypt -rw-r--r-- 1 root root Jan 31 20:27 msgstore.db.crypt root@winterfell-virtualbox:/home/claudio/documents/whatsapp# Por fim, é necessário executar o comando openssl para descriptografar os arquivos.crypt de acordo com o Quadro 5. Quadro 5 Comando para descriptografar arquivos.crypt root@winterfell-virtualbox:/home/claudio/documents/whatsapp# openssl enc -d -aes-192-ecb -in msgstore db.crypt -out msgstore db.sqlite -K 346a23652a46392b4d73257c67317e352e c O Whatsapp ainda grava arquivos de banco de dados sqlite na memória externa dos dispositivos. Os arquivos gerados na memória externa são gravados com extensão crypt5,

16 15 sendo que são arquivos criptografados de forma diferente dos arquivos armazenados no armazenamento interno. Os arquivos são localizados no caminho /sdcard/whatsapp/databases/. Segundo Ibrahim (2014), os seguintes passos devem ser realizados para a descriptografia dos arquivos crypt5: a) Realizar a descriptografia dos arquivos crypt5 é determinar o da conta do Google utilizada no dispositivo, necessitando gerar o hash MD5 do , conforme demonstrado no Quadro 6. Quadro 6 Comando para gerar hash MD5 do e -mail root@winterfell-virtualbox:/home/claudio/downloads/whatsapp-lulinha# echo -n claudio@gmail.com md5sum 48e953921a6d7e53e3abbcfb a - b) Em seguida é necessário converter a cadeia de 32 digitos hexadecimais em uma cadeia de 48 dígitos hexadecimais, concatenando os primeiros 16 dígitos ao final do hash original. Neste caso, 48e953921a6d7e53e3abbcfb a48e953921a6d7e53. c) Faz-se necessária a realização de uma operação XOR entre os 48 dígitos hexadecimais do passo b com uma chave de 48 dígitos encontrada no método de criptografia do arquivo crypt5 no código fonte do Whatsapp: 8d4b155cc9ff81e5cbf6fa a3ec621a656416cd793. Esta operação fornecerá a chave de descriptografia. d) É necessário ressaltar que o processo de descriptografia do arquivo crypt5 necessita de um vetor de inicialização, que é uma chave de 32 dígitos e também está presente no método de criptografia de forma estática: 1e39f369e90db33aa73b442bbbb6b0b9. e) Com a chave de descriptografia e o vetor de inicialização utiliza-se o comando openssl com a seguinte sintaxe: openssl enc -aes-192-cbc -d -nosalt -in msgstore.db.crypt5 -out msgstore.db -K [key] -iv [iv] Após esse processo é possível visualizar os arquivos de banco de dados SQLite através do sqlite3 via shell na estação de trabalho forense. 9. ROOTEANDO UM DISPOSITIVO ANDROID Segundo a BullGuard (2013), o processo de rootear um dispositivo Android é modificar o esquema de permissões padrão do Android, possibilitando que o usuário do aparelho possua privilégios de super usuário (root). Este nível de privilégio possibilita ao usuário alterar o código de software do aparelho, acessar diretórios antes somente acessíveis pelo super usuário Android e instalar quaisquer outros softwares que normalmente os fabricantes não permitem. Por razões de segurança os fabricantes por padrão não permitem que os usuários façam modificações para os telefones que possam resultar em acidentes, impossibilitando reparação dos dispositivos.

17 16 Usuários mais experientes já desenvolveram métodos de rooting, que variam dependendo do dispositivo, estando disponível na Web em sites especializados e fóruns de referência como o XDA-Developers ( Android Central ( e entre outros. Os métodos empregados para rootear um dispositivo devem ser previamente testados pelos peritos forenses em virtualizações ou ainda em dispositivos semelhantes ao alvo para certificar que o método, mesmo que considerado invasivo, não altere de forma significante as informações armazenadas, comprometendo provas essenciais de uma investigação. Em praticamente todos os procedimentos para circundar métodos de bloqueio de telas, utilizar força bruta na criptografia Android e demais métodos demonstrados no artigo necessitam de acesso root ao dispositivo. Conforme corroborado por Hogg (2012, pág. 346), a aquisição de partições do sistema operacional necessita que o perito possua acesso root habilitado no dispositivo, caso contrário a aquisição de dados será parcial. Durante a pesquisa foram testados vários métodos de rooting adequados para cada versão do sistema operacional Android, conforme Quadro 7. Quadro 7 Apuração de efetividade de métodos de rooting por versão do SO Android Versão Dispositivo físico Quantidade de métodos Métodos bem sucedidos do SO testados Motorola Defy Motorola Razr XT Sony Xperia Z Sony Xperia Z Sony Xperia Z Sony Xperia Z Sony Xperia Z USO DE FASTBOOT E BOOTLOADER NO PROCESSO DE ROOTING De acordo com Kondrat (2013), o fastboot é uma ferramenta imprescindível para usuários avançados que necessitam modificar o sistema operacional instalado no dispositivo, sendo que esta ferramenta acompanha o Android SDK, ou seja, é uma ferramenta utilizada para um fim específico: o seu uso principal ocorre quando não existe acesso via ADB ao dispositivo, porém, o dispositivo está com o bootloader ativado. Segundo a Motorola (2013), o bootloader é responsável pela inicialização de hardware básico do dispositivo, verificar a integridade do sistema operacional, iniciar o sistema operacional e fornecer um método de atualização do software do dispositivo. O Google fornece uma versão base do bootloader como parte do sistema operacional Android, porém, os fabricantes otimizam esta versão para seus dispositivos específicos. O desbloqueio do bootloader possibilita ao usuário realizar a instalação de uma distribuição Android com privilégios administrativos (root) ao usuário através do uso da ferramenta fastboot. Conforme explicado pela Motorola (2013), mas também reafirmado por outros fornecedores de dispositivos Android, tais como a Sony (2013) e constatado nos testes com as máquinas virtuais Android conforme Quadro 8. Quadro 8 Apuração de desbloqueio do bootloader Versão do SO Dispositivo físico Perda de dados do usuário Motorola Defy Não 3.0 Motorola Razr XT910 Sim Sony Xperia Z1 Sim Sony Xperia Z1 Sim Sony Xperia Z1 Sim

18 Sony Xperia Z1 Sim 4.4 Sony Xperia Z1 Sim O único dispositivo a não apresentar perda de dados do usuário foi o Motorola Defy com a versão do sistema operacional Android, pelo simples fato de que o bootloader já estava desbloqueado para uso. Em situações em que o perito forense se depara com um dispositivo com o bootloader desbloqueado indica uma grande possibilidade do sistema operacional presente no dispositivo ser uma distribuição modificada e com possível acesso root. Para verificar tal informação basta executar o comando adb reboot-bootloader, onde o dispositivo será reiniciado e direcionado para a tela do bootloader. 10. CONCLUSÃO Dentro dos tópicos apresentados anteriormente, algumas conclusões podem ser obtidas no processo de perícia em dispositivos Android no que tange os aspectos de segurança e suas implicações. O processo de apreensão do dispositivo móvel, pelo qual o agente que realiza o primeiro contato com o dispositivo móvel é vital e determinante para o trabalho do perito, sendo que aspectos de segurança como o bloqueio de tela podem ser evitados enquanto o dispositivo estiver ligado. Diferente do panorama da perícia em computadores pessoais e laptops, determinados métodos de contornar bloqueios de segurança nem sempre funcionam nas mais variadas versões do sistema operacional Android, não havendo um padrão a ser seguido quanto da utilização de ferramentas, scripts ou de procedimentos no dispositivo periciado. Portanto é necessário um trabalho mais aprofundado do perito quanto a conhecer o sistema operacional em suas variadas versões e, possuindo o conhecimento necessário, criar métodos que possibilitem a realização da perícia, já que existe a possibilidade de que métodos já criados e divulgados em fóruns especializados não surtam o efeito desejado. Durante a condução de perícias nos dispositivos alvos para este artigo, foi possível verificar que procedimentos de rooting quando não corretamente executados podem comprometer todos os dados armazenados no dispositivo ou ainda fazer com que o mesmo pare de funcionar. De todas as versões do Android somente a versão 4.4 (KitKat) não foi possível realizar o processo de rooting com sucesso através de métodos já divulgados na Internet e nos fóruns especializados. Diante desta constatação e de que é realmente necessário o acesso com usuário root para vários métodos de circundar, portanto, o perito deve estar preparado para realizar procedimento de rooting, caso seja necessário na condução da perícia. O perito forense, com o conhecimento sobre o sistema operacional Android e habilidade em programação pode criar seus próprios métodos de rooting ou modificar procedimentos já existentes, elevando o nível de controle de modificações nos arquivos do sistema operacional. É recomendado que o perito organize uma biblioteca de soluções de rooting devidamente testadas para uso. Foi possível constatar que os procedimentos de destravamento do bootloader e do uso do fastboot nas versões 3.0 ou superior mostraram-se infrutíferas para o processo de rooting, pois o processo automaticamente executa uma formatação wipe da partição de dados do usuário, comprometendo definitivamente a aquisição lógica ou física de informações da memória de armazenamento interno e, em alguns casos, também de informações presentes no armazenamento externo (cartão SD). O caso de engenharia reversa com o WhatsApp, demonstrado no artigo deixa claro que é possível utilizar esta técnica para realizar a extração lógica de dados de mensageria, assim como também aplicá-la em qualquer outro aplicativo para Android para uma análise mais

19 18 aprofundada, mesmo que o código compilado esteja ofuscado. O processo de ofuscação de código utilizado por desenvolvedores de aplicativos Android é um recurso que aumenta a dificuldade do processo de engenharia reversa, mas não impede que um perito com conhecimento técnico suficiente realize tal intento. Esta técnica é particularmente útil quando ferramentas de extração lógica de dados, como o AFLogical, da fabricante Via Forensics, não possuírem privilégios suficientes para extrair dados de determinada aplicação instalada no dispositivo periciado. A disponibilidade de ferramentas forenses proprietárias facilitaria muito o trabalho do perito, porém, seu alto custo pode inviabilizar que peritos ad-hoc cíveis manterem tais ferramentas para viabilizar seus trabalhos junto a autoridade judiciária. Outro ponto crucial que corrobora para que o perito tenha uma visão mais técnica e aprofundada da plataforma Android é que não existe garantia que o software proprietário possibilite a realização da perícia no dispositivo, sendo que fatores como a versão do sistema operacional, tipo de aparelho e problemas de ordem de hardware, concomitantes ou não, possam impedir a aquisição de dados TRABALHOS FUTUROS Uma sugestão para trabalhos futuros na linha da perícia forense em dispositivos móveis é o uso de interface JTAG para aquisição física e lógica de dados, assim como sua utilização para circundar os métodos de bloqueio e de criptografia de dispositivos Android. 11. RESUMO EM LÍNGUA ESTRANGEIRA ABSTRACT SAFETY ASPECTS OF THE ANDROID PLATFORM ON DRIVING SKILLS IN FORENSIC MOBILE DEVICES The forensic analysis of Android devices tends to be more of the activities carried out by forensic experts due to the quantity of users and existing mobile devices in operation, which may contain vital information on conducting forensic expertise. There are several published articles on procedures and tests on mobile devices and pervasive computers, but do not address in depth the barriers and limiting factors that can prevent further expert analysis, given the slew of devices. Given a scenario, this article aims to explain about the security methods of the Android platform and how the expert can go around them so that the skill can be performed without the help of proprietary applications and demonstrate the limits of the range of techniques employed the various versions of the Android platform. The article also demonstrates that a thorough technical knowledge of the expert on the Android operating system can mean the difference between achieving or not a skill. Keywords: forensics; mobile devices; screen lock; encryption; Android

20 REFERÊNCIAS BIBLIOGRÁFICAS ANDROID. Initializing a Build Environment. Disponível em: < Acesso em 04 mai AVIV, Adam J.; GIBSON, Katherine; MOSSOP, Evan; BLAZE, Matt; SMITH, Jonathan M. Smudge Attack on Smartphone Touch Screens. Recuperado em 18 de abril de 2014, de BLUM, Steven. Android for Beginners: What is an APK File?. Disponível em: < Acesso em 04 mai BULLGUARD. Android rooting risks. Disponível em: < Acesso em 24 abr CANNON, Thomas. Android Lock Screen Bypass. Disponível em: < Acesso em 05 mai GOOGLE. Encryption. Disponível em: < Acesso em 21 abr HOOG, Andrew. Android Forensics: Investigation, Analysis and Mobile Security for Google Android. 1 ed. Editora Elsevier IBRAHIM, Mohamed. How to Decrypt WhatsApp crypt5 database. Disponível em: < Acesso em 24 abr MISRA, Anmol; DUBEY, Abhishek. Android Security: Attacks and Defenses. 1 ed. Editora CRC Press MOTOROLA. What is a bootloader, can I unlock it and what are the risks?. Disponível em: < Acesso em 24 abr PATEL, Pritesh N.;PATEL, Jigisha K.; VISPARIA, Paresh V. A Cryptography Application using Salt Hash Technique. Recuperado em 04 de junho de 2014, de SONY. Unlocking the boot loader. Disponível em: < Acesso em 24 abr SPREITZENBARTH, Michael. Forensic blog: mobile phone forensics and mobile malware. Disponível em: < Acesso em 01 mar