2012 Sbseg mc2

Minicursos do XII Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais SBSeg 2012
Captulo
2
Introduo Segurana de Dispositivos Mveis Modernos Um Estudo de Caso em Android
Alexandre Melo Braga, Erick Nogueira do Nascimento, Lucas Rodrigues da Palma e Rafael Pereira Rosa
Abstract Mobile devices, especially smartphones and tablets, are the protagonists of a silent revolution, characterized by the use of devices with high processing power and connectivity in public and private networks. The aggregation of such characteristics to the wide pervasiveness of these devices brought a whole new set of threats, bringing the need of a study of new security techniques and tools. This course aims to clarify these issues, covering the security aspects related to modern mobile devices, showing threats and vulnerabilities on this field, especially over the Android platform. Resumo Os dispositivos mveis, em particular os smartphones e os tablets, so os protagonistas de uma revoluo silenciosa, caracterizada pelo uso de dispositivos com grande poder de processamento e conectividade em ambientes pblicos e privados. A agregao de tais caractersticas ampla difuso de dispositivos mveis trouxe uma srie de ameaas, tornando necessrio um estudo de novas tcnicas e ferramentas de segurana. Este curso tem a finalidade de esclarecer estes assuntos, abordando os aspectos de segurana da informao relacionados aos dispositivos mveis modernos, exibindo ameaas e vulnerabilidades nesta temtica, em particular na plataforma Android.
2.1.
Introduo
Os dispositivos mveis, em particular os smartphones e os tablets, so os protagonistas da atual onda de mudana no mundo das TICs (Tecnologias da Informao e da Comunicao) de uso pessoal e profissional. Esta mudana caracterizada pelo uso de dispositivos com grande poder de processamento e conectividade em ambientes pblicos e privados.
52
c 2012 SBC Soc. Bras. de Computao
O aumento do poder de computao, a grande conectividade e o grande aumento recente da variedade de servios e aplicativos disponveis nos dispositivos mveis pem os smartphones e os tablets em evidncia como alvos de ataques de risco elevado. Em vista disto, a segurana da informao, outrora centralizada e com permetro bem definido, tende a se tornar descentralizada e individualizada. Este minicurso aborda os aspectos de segurana relacionados aos dispositivos mveis de acordo com trs aspectos inter-relacionados. O primeiro a constatao no segundo semestre de 2011 que os dispositivos mveis representaro a prxima fronteira de proliferao de software malicioso. Este fato foi evidenciado pelo grande aumento no ltimo quarto de 2011 da quantidade de artefatos maliciosos voltados plataforma Android, da Google, o qual foi motivado em parte pelo aumento da fatia de mercado desta plataforma em relao s outras plataformas de dispositivos mveis, tais como o iOS, da Apple, e o RIM, da BlackBerry, assim como pela abertura da plataforma Android. O segundo o fenmeno chamado consumerizao, no qual novas tecnologias passaro a surgir primeiramente voltadas para usurios finais e, somente depois, para o segmento corporativo, ao contrrio do que ocorreu, por exemplo, com tecnologias como os computadores de grande porte e os aparelhos de fax. Deste modo, indivduos que trocam frequentemente seus dispositivos, passam a utiliz-los de modo intenso no apenas em atividades pessoais, mas tambm profissionalmente, em um fenmeno comportamental conhecido como BYOD (Bring Your Own Device). Com este comportamento, estes indivduos influenciam as organizaes a que pertencem e que por sua vez so levadas adaptao forada s novas tecnologias e ao tratamento da segurana dos dispositivos mveis de forma descentralizada, pois se perde o controle de ativos inseridos no ambiente de rede e a noo de permetro de segurana. O terceiro aspecto um desdobramento dos anteriores, em que em um ambiente de TIC, caracterizado pelos fenmenos da consumerizao e do BYOD, muitos dos controles de segurana tradicionais, comumente aplicados sobre desktops e outros ativos da infraestrutura, tornam-se ineficazes. Um exemplo da situao descrita acima o caso de software malicioso voltado para plataformas mveis. Uma vez que sua proliferao no se d por transferncias diretas entre dispositivos, como normalmente ocorria nos computadores portteis e de mesa, mas usualmente por meio das lojas de aplicativos ou de sites de terceiros potencialmente no confiveis. Por exemplo, ao permitir que um tablet pessoal seja infectado por um aplicativo malicioso, vindo de um mercado aberto de aplicativos, surge uma oportunidade nova para o comprometimento da infraestrutura corporativa. Alm disso, outro exemplo a utilizao de botnets (grupos de dispositivos controlados remotamente por um atacante) de smartphones para realizao de ataques macios sincronizados e outras fraudes coordenadas, incluindo ataques potenciais rede de telecomunicaes. 2.1.1. Evoluo dos Ambientes Mveis Esta subseo oferece uma viso panormica sobre a evoluo tecnolgica dos ambientes mveis. Os pargrafos a seguir fazem uma reviso bibliogrfica breve dos conceitos e vises que levaram ao contexto atual de ambientes mveis.
53
O sonho da informao na ponta dos dedos em qualquer lugar e a qualquer momento" e a viso ldica e at certo ponto ficcional de dcadas passadas foram capazes de antecipar muitos dos desafios que se apresentam hoje aos dispositivos mveis. As plataformas mveis de hoje so resultado de diversas inovaes conceituais e de modelos de computao vislumbrados no final do sculo passado e cujas primeiras implementaes remontam ao final do milnio passado. Dentre as inovaes mais importantes podem ser citadas as seguintes: a computao pervasiva, a computao autonmica, a computao senciente e sensvel ao contexto, as redes de comunicao sem fio de curto alcance, a eficincia energtica e o software adaptvel. Neste momento, fazem-se necessrios conceitos relevantes. Computao pervasiva ou computao ubqua um termo que foi publicado pela primeira vez em 1991 por Mark Weiser [Weiser 1991], o qual previu a onipresena da informtica no cotidiano das pessoas. A computao pervasiva ou ubqua tem como objetivo tornar a interao pessoa-mquina invisvel (ou imperceptvel), ou seja, integrar a informtica com as aes e comportamentos naturais das pessoas. Computao autonmica uma rea da computao cujo objetivo o desenvolvimento de sistemas computacionais capazes de autogerenciamento e de adaptao a mudanas imprevisveis, permitindo a expanso de sistemas computacionais complexos e uma melhor utilizao dos recursos computacionais. Um sistema autnomo toma decises utilizando instrues de alto nvel, que iro verificar constantemente os procedimentos realizados e aperfeioa-los, adaptando-se s novas condies. A computao senciente se refere possibilidade de interconexo de computadores e objetos atravs de sensores que passam a se reconhecer de maneira autnoma e a trocar informaes. Segundo Satyanarayanan [Satyanarayanan 2010], o e-mail e o acesso web onipresentes j so realidades para milhes de usurios em todo o mundo atravs de seus dispositivos mveis. Mantendo esta linha de atuao, os servios da web mvel e as oportunidades de publicidade sensvel ao contexto comearam a aparecer como atividades comerciais no apenas viveis tecnicamente mas tambm economicamente. No final do sculo passado, o conceito de computao pervasiva (ou ubqua) despontava como uma das vises mais promissoras de computao mvel. Em 1991, Mark Weiser [Weiser 1991] previu muitos dos dispositivos mveis utilizados atualmente. Tais dispositivos seriam amplamente utilizados pelas pessoas na realizao das mais diversas atividades da vida cotidiana e estariam intrinsecamente agregados rotina humana. Alm disto, Weiser [Weiser 1991] tambm pregou que o PC (Personal Computer) tradicional em formato desktop seria inadequado para integrar verdadeiramente a computao s prticas de trabalho do sculo XXI. Ele argumentou que a presena de um computador bem projetado seria quase imperceptvel, e efetivamente invisvel, ao realizar as tarefas dirias. Ainda em 2000, surge formalmente o conceito de computao senciente [Hopper 2000], no qual os aplicativos podem se tornar mais sensveis e teis ao observar e reagir ao mundo fsico. Este conceito pode ser facilmente adaptado ao mundo de usurios
54
mveis, onde cada indivduo carrega consigo o seu prprio conjunto de computadores mveis sensveis ao contexto que os rodeiam. J em 2001 foram identificadas por Satyanarayanan [Satyanarayanan 2001] vrias caractersticas que precisariam ser asseguradas pelos sistemas mveis: adaptabilidade infraestrutura ciberntica subjacente, eficincia energtica, sensibilidade ao contexto, equilbrio entre o comportamento proativo e a participao do usurio e segurana (privacidade e confiana). Em 2003, Kephart e Chase [Kephart e Chase 2003] vislumbraram que o sistema formado por todos os dispositivos mveis e os aplicativos neles residentes uma estrutura to gigantesca que somente poderia ser entendida como um sistema de computao autonmica ou autogerenciado. Este sistema seria capaz de integrar novos componentes automaticamente em uma grande base sistmica existente e gerenciar as operaes dirias a partir de objetivos gerais definidos por um administrador impessoal e distante dos detalhes operacionais. Atualmente, sabe-se que a complexidade dos sistemas, que so compostos por dezenas de milhes de linhas de cdigo, cada vez maior e est sendo amplificada em vrias ordens de magnitude pela tendncia de computao pervasiva, que tem como uma de suas caractersticas, a autogesto de sistemas adaptativos. Apenas recentemente, aspectos de computao sensvel ao contexto comearam a ser integrados aos dispositivos mveis, realizando operaes de monitoramento sensvel ao contexto com base nos mltiplos sensores e aplicativos disponveis nos smartphones [Kang et al. 2008]. Por exemplo, h um estudo recente [Reddy et al. 2008] mostrando que um telefone celular moderno, com GPS e acelermetro integrados, pode ser usado para discernir se um indivduo est parado, caminhando, correndo, andando de bicicleta ou em um transporte motorizado. O conceito de computao sensvel ao contexto anterior ao ano 2000 [Chen e Kotz 2000] e estabelece que um sistema de computao seja capaz de modificar seu comportamento com base em seu contexto local, utilizando localizao geogrfica, hora do dia, quem est por perto e estado de movimento. Como resultado, as aplicaes sensveis ao contexto podem fornecer uma experincia aprimorada, personalizando o seu comportamento para melhor apoiar as tarefas do usurio. Este tipo de adaptao particularmente til ao projetar aplicaes mveis que sero colocadas em contextos mutveis. H dois componentes principais necessrios para a criao de sensibilidade ao contexto: em primeiro lugar, a capacidade de capturar uma grande variedade de dados de sensores e, segundo, a capacidade de inferir atividades com base nesses dados. 2.1.2. Avanos Recentes na Proteo das Plataformas Mveis Um artigo recente [Oberheide e Jahanian 2010] apresenta uma comparao preliminar e qualitativa das cinco principais plataformas modernas de smartphones em relao aos trs modelos atuais de segurana para plataformas mveis: Entrega segura de aplicaes: refere-se ao nvel de garantia de segurana da aplicao, desde o desenvolvimento e disponibilizao da aplicao, at o processo de implantao no aparelho, e est relacionada capacidade de uma plataforma mvel verificar a integridade e a autenticidade de origem de uma aplicao a ser instalada no dispositivo.
55
Nveis de confiana: refere-se granulao do controle de acesso aos recursos do aparelho e determina os graus de confiana e privilgios a serem implementados por mecanismos de controle de acesso. Isolamento de aplicaes e do SO (Sistema Operacional): refere-se capacidade de uma plataforma mvel em isolar ou conter uma aplicao em particular, como uma estratgia de preveno contra o comprometimento de outras aplicaes, resultando no grau de conteno do dano causado por aplicaes comprometidas sobre outras aplicaes e o resto do sistema.
O artigo sugere que a plataforma Android da Google apresenta o modelo de segurana mais consistente e seguro sendo que o Symbian OS viria em seguida e por fim o Windows Mobile. Porm esta viso estava equivocada. Em 2011, houve uma grande proliferao de softwares maliciosos nas diversas plataformas mveis, em particular na plataforma Android, a qual no obteve uma resposta rpida dos fornecedores de produtos de segurana da informao. A falta de respostas no foi motivada pela falta de interesse comercial, mas sim pela ausncia de tecnologias robustas para a soluo destas questes [Enck et al. 2011].
2.2.
Arquitetura de Segurana da Plataforma Android
So vrios os aspectos envolvendo segurana na plataforma Android cuja compreenso primordial para o entendimento dos riscos e ameaas associados a essa plataforma. Essa compreenso tambm necessria quando se trata de anlise de artefatos maliciosos, desenvolvimento de aplicativos e avaliao de segurana. Portanto esta seo discute tais aspectos. 2.2.1. Plataforma Android O Android uma plataforma open source para dispositivos mveis composta por sistema operacional, middleware, frameworks de aplicao e algumas aplicaes essenciais para provimento das funcionalidades bsicas dos dispositivos. O esforo inicial em sua concepo foi da Google, que, posteriormente, o passou para a Open Handset Alliance, grupo composto por operadoras, fabricantes de dispositivos e de componentes e fabricantes de software. A seguir, segue uma explicao em camadas da plataforma, conforme visto na Figura 1. Na camada superior residem as aplicaes essenciais para o provimento das funes bsicas do dispositivo. Estas aplicaes vm pr-instaladas e, cita-se como exemplo: servio de voz, servio de SMS/MMS, email, calendrio, navegador web e agenda. Ademais, os OEMs (Original Equipment Manufacturer) podem inserir seus prprios aplicativos no dispositivo por motivos diversos. Um exemplo de um aplicativo desse tipo o Samsumg Kies que vem junto ao Galaxy SII. Aplicaes de terceiros tambm fazem parte dessa camada, contudo as mesmas devem ser instaladas pelo usurio por meio da loja virtual, pela interface de depurao, ADB (Android Debug Bridge), ou por meio da execuo de um APK (Android Application Package) armazenado na memria interna ou em um carto SD. Essas duas ltimas opes devem ser ativadas nas configuraes do aparelho. As aplicaes dessa camada so compostas por componentes que so responsveis pelo provimento das mais diversas funcionalidades suportadas pela API do Android. So eles: Activities, Broadcast Receivers, Services e Content Providers.
56
J o framework de aplicao composto por cdigo compilado para a mquina virtual Dalvik - que foi desenvolvida para rodar de modo eficiente nas plataformas utilizadas por dispositivos mveis - e prov os mais diversos servios para os aplicativos desenvolvidos para esta plataforma. Nessa camada encontram-se mdulos como o provedor de servios de localizao, de gerenciamento de Activities e de Content Providers.
Figura 1: Pilha de software do Android. Fonte: [Android Open Source Project 2012a].
A camada de middleware implementa servios que so disponibilizados para o framework de aplicao e para as aplicaes. composta por diversas bibliotecas nativas que so devidamente compiladas para cada dispositivo e provm as mais diversas funcionalidades, dentre elas: acesso grfico tela, engine de renderizao web, acesso base de dados relacional e estabelecimento de canal SSL/TLS. De acordo com [Six 2012], essas bibliotecas rodam como processos no sistema a fim de proverem seus respectivos servios. As aplicaes construdas para executar na mquina virtual Dalvik tambm possuem, cada uma, sua prpria instncia da mquina virtual, ou seja, cada aplicao possui um processo associado quando em execuo, e esse processo nada mais do que a mquina virtual interpretando o cdigo da aplicao, que se utiliza das bibliotecas do Android, visando prover as funcionalidades pretendidas pela aplicao. O sistema operacional traz em seu ncleo o kernel do Linux, que responsvel pela abstrao do hardware e pelo provimento das interfaces para manipulao deste hardware por meio dos drivers de dispositivo. Nessa camada so aplicados alguns controles de segurana referentes ao confinamento de aplicaes, afora alguns outros que fazem desta uma das camadas mais importantes no que diz respeito segurana.
57
Conforme [Android Open Source Project 2012a], a plataforma Android foi concebida de modo que sua segurana no ficasse to dependente dos desenvolvedores. Sua arquitetura de segurana permite que controles sejam aplicados de forma transparente para o desenvolvedor, ou seja, existe um grande nvel de abstrao neste processo. Isso alcanado por meio do confinamento de aplicaes, pelo esquema de permisses - tanto do sistema de arquivos como de chamadas de API, que preza a segurana por default - e pelo mecanismo de IPC (Inter-Process Communication), que tambm aplica tais permisses para conceder acesso ou no entre os diferentes componentes. Tal plataforma alicerada em torno de algumas caractersticas, conforme visto a seguir: Dispositivos de hardware - assim como o prprio Linux, diversas configuraes de hardware so suportadas pelo Android, entre elas: smartphones, tablets, settop-boxes e e-readers. Cada um desses dispositivos possui controles de segurana implementados em hardware - como por exemplo o ARM (Advanced RISC Machine) TrustZone e o ARM XN (execute never) - e o sistema capaz de se utilizar de tais capacidades; Sistema operacional - baseado no kernel do Linux, o ncleo do Android prov a interface para a utilizao do dispositivo. O acesso a todos os recursos mediado pelo sistema operacional e fica restrito aos controles de segurana implementados por este; Ambiente de execuo de aplicaes (Android Application Runtime) - A maioria dos aplicativos para Android so desenvolvidos em Java e rodam na mquina virtual Dalvik, embora seja possvel criar aplicaes que executam cdigo nativo na plataforma do dispositivo. Ainda assim, essas aplicaes, juntamente com os outros servios providos pela plataforma e pelas bibliotecas, que rodam cdigo nativo, executam em um ambiente confinado denominado sandbox de aplicao. Este confinamento restringe as permisses de acesso da aplicao, em seu ambiente de execuo, ao sistema, a recursos do sistema, a dados de outras aplicaes e a outras aplicaes em execuo.
A segurana da arquitetura baseia-se fortemente nos mecanismos de segurana aplicados pelo kernel do Linux e na disponibilizao de uma comunicao interprocesso segura. Todo cdigo de aplicao, incluindo as que executam cdigo nativo, ficam restritas pelo sandbox de aplicao, que implementado por meio de um modelo de isolamento de processos baseado em usurios, que aplicado pelo kernel. 2.2.2. Processo de Inicializao (Boot) O processo de boot tem pouco a ver com a plataforma Android e muito mais com o hardware em questo, ficando sob responsabilidade do fabricante do dispositivo. A seguir, est descrito um resumo desse processo de acordo com o detalhado em [Bjrnheden 2009]. Inicialmente, um cdigo carregado da ROM (Read Only Memory) executado a fim de detectar algum cdigo de boot (bootloader) em alguma das mdias de armazenamento disponveis, para, em seguida, carreg-lo e transferir a execuo para o mesmo. O cdigo da ROM verifica a assinatura do cdigo de boot e, somente se a mesma for vlida, a inicializao prossegue. O cdigo de boot citado dividido em dois estgios.
58
O primeiro responsvel por configurar a memria RAM (Random Access Memory) externa, visto que tudo at ento vinha sendo carregado na memria RAM interna. Esse estgio geralmente d a opo de carregar imagens de recuperao, alm de possibilitar a execuo de funes de desenvolvimento tais como: realizar flashing e baixar e executar outras verses do sistema. Embora tais opes sejam disponibilizadas, a funo usual desse primeiro estgio o carregamento do segundo estgio do cdigo de boot na RAM externa. O cdigo do segundo estgio responsvel pela configurao dos firmwares e pelo carregamento do kernel na memria. Nessa etapa existe a possibilidade de verificar a assinatura do kernel antes de passar o controle da CPU (Central Processing Unit) a ele, contudo, os fabricantes normalmente no aplicam a checagem em questo. O processo de inicializao a partir desse momento prossegue como em qualquer Linux, com o grande diferencial de que, ao final da inicializao, o processo Zygote ser iniciado e ficar responsvel por iniciar uma mquina virtual Dalvik com o objetivo de executar cada aplicativo que se fizer necessrio. Em seguida, um servio chamado System Server ser iniciado visando ativar os servios essenciais do dispositivo. 2.2.3. Modo de Recuperao e Modo Bootloader O modo de recuperao, mantido em uma partio (/recovery) de inicializao que no a partio de boot tradicional (/boot), permite o fornecimento de uma imagem de recuperao objetivando retornar o dispositivo a seu estado de fbrica. Geralmente, verifica-se a assinatura dessa imagem de atualizao a fim de que no seja possvel injetar cdigo fornecido por outra entidade que no o fabricante. Esse modo permite ainda a formatao do dispositivo. Normalmente, quando se obtm acesso administrativo ao dispositivo, altera-se a imagem de recuperao com uma imagem maliciosa. Esse modo de recuperao modificado permite a atualizao do sistema com imagens no assinadas pelo fabricante, o que permite que seja fornecida uma imagem que prov acesso administrativo ao sistema, ainda que esteja definida uma senha ou PIN para controle de acesso. J no modo bootloader, possvel fazer flashing na ROM do dispositivo, sendo possvel modificar as parties de boot, de recuperao e de sistema. Normalmente, essa tcnica aplicada para obter aceso mais privilegiado ao sistema, por meio do flashing de imagens que permitam aceso administrativo. Para tal, diversos protocolos podem ser utilizados - normalmente via USB - o que varia de acordo com o fabricante e at mesmo entre dispositivos do mesmo fabricante. necessrio tambm que o bootloader no esteja em modo protegido por hardware, o que impossibilitaria o flashing. A proteo supracitada trata-se da secure flag, que permite apenas o flashing de imagens assinadas pelo fabricante. possvel desativar essa flag, todavia todas as informaes no dispositivo so descartadas e o mesmo volta para o estado de fbrica.
59
2.2.4. Depurao via USB Existe um servio de depurao em todo sistema Android que pode ser ativado em suas configuraes. Feito isso, um daemon ser iniciado, o adbd (Android Debug Bridge Daemon), com as permisses do usurio shell. Esse depurador possibilita a instalao e desinstalao de aplicativos, o gerenciamento de logs, a execuo de comandos de shell, a cpia de arquivos de e para o dispositivo, a gerao e restaurao de backups, entre outros. Essa interface de acesso utilizada para copiar exploits para o dispositivo e execut-los a fim de ganhar acesso privilegiado ao sistema. A exposio se torna ainda maior pelo fato desse servio de depurao ser iniciado por default caso o sistema tenha sido iniciado em modo de recuperao. 2.2.5. Bloqueio de Tela e Encriptao da Partio de Dados No Android possvel definir um controle de acesso ao sistema, para isso so definidos 4 modos com diferentes nveis de segurana. Abaixo uma descrio de cada um em ordem crescente de segurana: Reconhecimento Facial: o modo mais inseguro. J houveram ataques em que essa controle foi quebrado com simplesmente uma foto sendo apresentada ao sensor [Callaham 2011]. Hoje em dia, uma foto pode ser facilmente obtida atravs de outro dispositivos com cmera ou ento atravs das redes sociais. Alguns avanos tm sido obtidos com pesquisas recentes, a exemplo de [Schwartz et al. 2011] e [Pinto et al. 2012], que talvez resulte em mecanismos mais robustos contra ataques de spoofing. Padro de desenho: neste modo, desenha-se um padro na tela ligando pontos em um campo. Considerando um campo 3x3, e que cada um pode ser representado, este modo nada mais que uma senha de nove nmeros, os quais no podem ser repetidos, algo que facilmente quebrado em um ataque de fora bruta. Alm disso, possvel observar o borro que o dedo deixa na tela do dispositivo, obtendo assim o rastro deixado no momento de desenhar o padro [Aviv et al 2010]. PIN: o desbloqueio atravs de uma senha numrica. Por mais forte que seja a senha, o fato de ser composta apenas por caracteres numricos limita sua segurana. Senha: a senha que possibilita o uso de letras, nmeros e smbolos. Devido ao domnio mais extenso de possibilidades, tal escolha a mais segura das 4.
Quando esse controle est ativo, o sistema iniciado como usualmente, todavia, to logo a imagem do sistema seja carregada, uma tela requisitando as credenciais de acesso apresentada, e, s aps a apresentao de tais credenciais, que o acesso liberado. Expirado um tempo de inatividade, o acesso ao sistema bloqueado e a tela requisitando a credencial de acesso apresentada novamente. Esse um mtodo que visa garantir que apenas o legtimo dono do dispositivo consiga utiliz-lo. No caso de vrias tentativas errneas de acesso ao sistema ocorrerem, um mecanismo de bloqueio de tentativas baseado em backlog exponencial aplicado. Neste caso, dada a opo de recuperao do acesso ao dispositivo, considerando que a credencial de acesso foi perdida. possvel ento obter acesso ao sistema fornecendo
60
uma conta Gmail previamente associada ao sistema operacional, juntamente com sua respectiva senha de acesso. Uma funcionalidade que passou a ser implementada a partir da verso 3.0 do Android a encriptao de disco / da partio de dados . Essa necessidade advm do fato de os controles de segurana aplicados pelo SO no serem suficientes para a proteo dos dados, pois um atacante com acesso fsico ao aparelho poderia obter todas as informaes nele armazenadas. Essa funcionalidade, que pode ser habilitada nas configuraes do sistema, busca assegurar que o extravio do dispositivo no resulte no comprometimento da informao, ainda que o bootloader ou o sistema sejam modificados pelo atacante por meio de flashing. Ainda que a memria permanente do dispositivo seja dividida em diversas parties, dentre elas: boot, recuperao, sistema e dados, a encriptao ocorre apenas na partio de dados, que onde os dados pessoais do usurio, suas configuraes, aplicativos e logs ficam armazenados. O processo de encriptao dos dados da partio ocorre da seguinte maneira [Android Open Source Project 2012c]: 1. Uma chave mestra de 128 bits gerada por meio de /dev/urandom a fim de ser utilizada para a encriptao da partio; 2. Utiliza-se ento essa chave mestra para encriptar a partio por meio do algoritmo AES (Advanced Encryption Standard) em modo de operao CBC (Cipher Block Chaining). A fim de gerar um vetor de inicializao nico para cada setor do disco, utiliza-se o mtodo ESSIV (Encrypted Salt-sector Initialization Vector) com SHA de 256 bits. A decriptao dos dados ocorre aps o usurio informar sua senha (ou PIN descritos logo acima), a qual utilizada para proteger a chave mestra de encriptao da partio. Essa proteo da chave a partir da senha ocorre como descrito a seguir: 1. A senha informada pelo usurio passada para a funo PBKDF2 (PasswordBased Key Derivation Function 2), juntamente com um salt gerado por meio de /dev/urandom. O salt adicionado visa dificultar ataques baseados em rainbow table, e, a fim de tornar ataques de fora bruta mais custosos, aplica-se a funo de derivao repetidamente por 2000 vezes, tcnica essa conhecida como key stretching. A sada dessa operao um valor de 256 bits; 2. Divide-se a sada de 256 bits do passo 1 em dois valores de 128 bits, a saber, chave e IV. Esses valores so ento utilizados para encriptar a chave mestra por meio do AES em modo de operao CBC, gerando uma cifra da chave mestra. 3. Essa cifra mantida no chamado crypto footer, que fica nos ltimos 16 kB da partio e serve para armazenar outras informaes sobre a encriptao, tais como: soluo criptogrfica utilizada, tamanho da chave e o salt adicionado senha. Recentemente mostrou-se [Cannon 2012] como obter o crypto footer a fim de realizar fora bruta da credencial de acesso com o objetivo de decriptar a partio e obter os dados do usurio. Os controles por PIN foram quebrados em questo de segundos e os autores ainda alertaram para o fato de que controles por senha geralmente resultam em senhas curtas e que seguem algum padro, justamente pelo fato de a mesma ser utilizada tambm para controlar o acesso ao dispositivo (bloqueio da tela). Fica claro que o cenrio ideal seria a existncia de duas senhas, uma a fim de proteger a
61
chave de encriptao do disco e outra para o bloqueio de tela. Na primeira poder-se-ia aplicar uma poltica de definio de senhas forte e requisit-la apenas quando o sistema estivesse sendo iniciado, enquanto que a segunda poderia ser uma senha mais fraca, que no afetasse a usabilidade do usurio. 2.2.6. Restries de Acesso Normalmente os aparelhos que rodam Android so configurados de modo que o usurio no possua total permisso sobre o sistema por meio de acesso administrativo (root). Essa deciso de projeto resulta em um maior nvel de segurana para a plataforma, semelhante ao que se preza em PCs, que o usurio deve usar o mnimo de permisses necessrios para a realizao de suas tarefas. Esse nvel de segurana elevado alcanado pelo fato de o sistema impossibilitar que o usurio instale aplicativos com permisses de superusurio, o que concederia tais permisses ao aplicativo em questo. Outro fator relevante o fato de se permitir a proteo de contedo digital includo nos aparelhos, tais como ringtones e wallpapers. E, por ltimo, pelo fato de impossibilitar que usurios quebrem o sistema de boqueio empregado pelas operadoras, como, por exemplo, impossibilitar que o dispositivo seja utilizado como um hotspot com o objetivo de compartilhar o pacote de dados contratado com terceiros. O grande problema com essa estratgia de restringir o acesso ao usurio o fato de que um usurio com acesso fsico a um dispositivo, normalmente, caso realmente motivado, pode conseguir contornar qualquer mecanismo de segurana aplicado. E, de acordo com [Dwivedi et al. 2010], isso no se limita somente a vulnerabilidades no Android, a subverso dos mecanismos de segurana tambm podem resultar de vulnerabilidades no bootloader, nos firmwares do dispositivo, no mecanismo de proteo de memria por hardware e em configuraes de barramento, tanto em hardware como em software. 2.2.7. Rooting Foi criado o termo rooting para se referir ao ganho de acesso irrestrito plataforma dos dispositivos rodando Android, algo equivalente ao processo de jailbreaking existente no iOS, da Apple, ou no PlayStation 3, da Sony. O processo de rooting muda significantemente de dispositivo para dispositivo, de acordo com diferenas de hardware existentes em cada um deles. Como o Android derivado do Linux, fazer o rooting equivale obter permisses de acesso administrativo no dispositivo, ou seja, as permisses da conta root. As motivaes para a habilitao de tal acesso so vrias, como por exemplo: Instalao de verses modificadas do Android (sendo a ClockWorkMod a mais famosa delas); Uso de temas personalizados; Executar modificaes no kernel; Backup de todos os dados, pois necessrio acesso administrativo para se obter tais dados; Ativar funcionalidades que foram bloqueadas por operadoras (como o NFC). Para se efetuar a ativao de tal acesso, existem quatro tcnicas diferentes, que sero explicadas a seguir. 1. Flash recovery: Os dispositivos Android possuem um modo chamado Flash recovery, por meio do qual possvel utilizar uma imagem de recuperao fornecida pelo fabricante. Caso haja uma vulnerabilidade nessa implementao, pode ser possvel fornecer uma imagem modificada, que conceda acesso
62
administrativo ao sistema, e restaurar o dispositivo a seu estado original de fbrica a partir desta. 2. Flash boot (Fastboot): Uma tcnica bastante utilizada para rooting o flashing de imagem modificada nas parties do sistema de modo que se possa obter acesso privilegiado. 3. Escalada local de privilgios: Um atacante que obtiver acesso a um shell no sistema (o qual limitado e com poucos privilgios) pode conseguir fazer uma escalada local de privilgios, atravs da explorao de uma vulnerabilidade, obtendo assim acesso de root. 4. Escalada de privilgios via ADB: O servio ADB possibilita acesso restrito ao sistema, contudo pode ser possvel se utilizar de tal via de acesso para explorar uma vulnerabilidade que permite escalada de privilgios. Existem algumas ferramentas que contm payloads malicosos que permitem a explorao de vulnerabilidades existentes no sistema visando obter acesso administrativo. Uma famosa opo a ferramenta SuperOneClick. Ela executada em ambiente Windows e tenta identificar a verso do dispositivo Android atualmente conectado, para, em seguida, aplicar um ou mais ataques afim de se obter o root no aparelho. Outra opo a z4root, a qual funciona em dispositivos com verso 2.3 ou inferior do Android. A ferramenta explora uma vulnerabilidade para executar uma escalada de privilgios local, e ento consegue acesso a permisses administrativas. Vale ressaltar que esta restrio de verso no chega a ser um problema na maioria dos casos pois, atualmente, 75% dos aparelhos que usam a plataforma da Google rodam a verso 2.3 ou alguma anterior [Android Developers Project 2012c]. Vale ressaltar que a Subseo 2.6.2 contm informaes sobre os riscos de segurana envolvidos na ativao do usurio root. 2.2.8. Modelo de Segurana do Linux e Confinamento de Aplicaes O modelo de confinamento do Android uma adaptao do modelo tradicional de permisses de usurio do Linux, em que cada usurio recebe um UID (user-id) e o acesso aos recursos dos sistema controlado por usurio. Os recursos do sistema, tais como interface de rede e cmera so mapeados para entradas do sistema de arquivos. Para cada entrada existem trs permisses, leitura, escrita e execuo, as quais so aplicadas a trs sujeitos, usurio e grupo que mantm posse sobre o arquivo, e outros usurios. Esse modelo permite que os privilgios aplicados ao dono do arquivo sejam isolados dos aplicados ao grupo ao qual esse usurio pertence e dos outros usurios do sistema. Embora simples, esse um modelo que j provou sua eficcia por ter sido o modelo adotado pelo Unix, e por vir sendo utilizado pelo Linux desde sua concepo inicial. A adaptao feita pelo Android trata cada aplicativo como um usurio, mapeando um UID exclusivo para o aplicativo em tempo de instalao. Para cada aplicativo instalado, cria-se um diretrio no sistema de arquivos onde todos os arquivos associados sero armazenados. Apenas o UID do aplicativo possui total acesso a esse diretrio, o grupo ao qual pertence e os outros no possuem qualquer permisso de acesso. Esse modelo funciona como se cada aplicativo fosse um usurio no modelo de permisses do Linux, dessa forma, cada aplicativo executado com suas prprias
63
permisses de acesso. Esse controle impossibilita o acesso por parte de aplicativos maliciosos a recursos protegidos do sistema ou de outros aplicativos, diferente do modelo tradicional, em que os aplicativos com os privilgios de um mesmo usurio compartilhavam permisses de acesso a todos os recursos do sistema. Uma grande caracterstica intrnseca a este modelo o fato de que, caso uma vulnerabilidade seja explorada em um aplicativo, o cdigo malicioso injetado permanecer restrito s permisses da aplicaes em questo, no sendo possvel o acesso a outros recursos. O kernel do Linux tambm prov uma forma de controle de acesso a regies de memria dos processos, assegurando que diferentes processos no interfiram ou acessem as regies de memria de outro. Esse conceito a base para o modelo de confinamento de aplicativos do Android [Six 2012]. Como pode-se notar, a segurana do sistema extremamente dependente desse mecanismo de controle de acesso aplicado pelo kernel do Linux, todavia existem ainda outros mecanismos de segurana relacionados a permisses de API que sero tratados mais adiante. 2.2.9. Protees Contra Explorao de Vulnerabilidades de Corrupo de Memria Diversas protees existem no Android com o objetivo de dificultar a explorao de vulnerabilidades de corrupo de memria e de tornar o processo de desenvolvimento de exploits complexo a fim de dificultar que exploits genricos sejam utilizados para ganhar acesso ao dispositivo. Devido ao fato de ser possvel encontrar todas as verses de Android no mercado, importante compreender as protees aplicadas em cada uma delas com o objetivo de entender os riscos associados a cada um das verses. A seguir um detalhamento das melhorias obtidas, em relao a contramedidas implementadas, ao longo das verses do sistema liberadas [Android Open Source Project 2012a]. Dentre as contramedidas aplicadas a partir da verso 1.5 encontram-se: ProPolice para proteger as variveis de pilha com stack canaries; biblioteca safe_iop a fim de garantir a utilizao de operaes seguras com inteiros; rotinas de gerenciamento de memria que aplicam protees contra vulnerabilidades de double free visando prevenir ataques de consolidao de chunks da heap. A partir da verso 2.3 adicionaram-se os seguintes controles: protees contra vulnerabilidades de format string; preveno de execuo de regies de dados por hardware; definio de endereo mnimo para mapeamento de memria visando impossibilitar exploraes baseadas em null pointer dereference. O lanamento da verso 4.0 marcou o incio do suporte ASLR (Address Space Layout Randomization), entretanto, apenas na verso 4.1, foi introduzido suporte PIE (Position Independent Executable) e RELRO (Relocation Read-Only). Visando evitar vazamento de endereamento do kernel, dmesg_restrict e kptr_restrict, passaram a ser suportados tambm nessa verso. Embora diversas tcnicas sejam aplicadas, as mesmas apenas dificultam a explorao dessas vulnerabilidades. Atualmente, com a utilizao de ROP (Return
64
Oriented Programming) e de uma vulnerabilidade que possibilite a obteno de informao sobre o mapeamento de memria da aplicao, possvel se utilizar de uma outra vulnerabilidade para ganhar o controle de execuo. Em [Serna 2012] mostrou-se como, a partir de uma vulnerabilidade, obter informaes sobre o processo em execuo. Um outro trabalho interessante [Ridley e Lawler 2012], apresentou tcnicas de explorao modernas em arquitetura ARM. Ainda que um mecanismo de aleatorizao seja aplicado, dois grandes problemas com o modelo da arquitetura do Android vm tona. O primeiro o fato de que, por questes de eficincia, as bibliotecas compartilhadas serem pr-ligadas [Bojinov et al. 2011]. O segundo advm do fato de, ao executar um aplicativo Android, o processo Zygote bifurcar (fork) a fim de invocar a mquina virtual Dalvik que ser responsvel por interpret-lo. Esse processo de bifurcao nada mais do que um clone do processo, seguido do carregamento de uma nova rea de cdigo (.text). Como resultado dessa operao, os parmetros de aleatorizao sero sempre os mesmos em toda mquina virtual Dalvik, ou seja, sero os mesmos em qualquer aplicativo Android. 2.2.10. Loja de Aplicativos A obteno de aplicativos no Android ocorre por meio das chamadas lojas virtuais que mantm um grande catlogo de aplicativos que podem ser selecionados pelo usurio para instalao. Estes aplicativos podem ser grtis ou pagos. A loja oficial disponibilizada para a plataforma o Google Play, e para submeter aplicativos para ela necessrio registrar-se como um desenvolvedor Android. Para tal, uma taxa cobrada e o pagamento deve ser feito por meio de carto de crdito, o que, de acordo com [Six 2012], uma medida que visa assegurar alguma rastreabilidade da pessoa registrada, caso seja necessrio. Feito isso, o desenvolvedor pode submeter seus aplicativos para a loja. Os aplicativos devem ser assinados digitalmente e o certificado deve ser empacotado juntamente com o aplicativo no APK. Ao ser instalada, o Package Manager verifica se o aplicativo foi de fato assinado com o certificado includo junto a ele. Um ponto muito criticado o fato de no ser necessrio um certificado gerado por um entidade confivel para assinar os aplicativos. A prtica a gerao de certificados auto-assinados para este fim. Desse modo qualquer sujeito pode gerar um certificado em nome de outra entidade e assinar aplicativos como se fosse esta. O que se conclui disso que o objetivo dessa assinatura no a rastreabilidade do desenvolvedor a fim de poder responsabiliz-lo no caso de serem identificadas funcionalidades maliciosas no aplicativo, mas sim associar um certificado/desenvolvedor com aplicativos anteriormente disponibilizados de modo que os usurios possam avali-lo, o que vai ditar se o mesmo confivel ou no. Ainda relacionado a essa temtica, est o fato de os aplicativos executarem com certas limitaes caso no tenham sido assinados. Isso, justamente pelo fato de o aplicativo no estar associado a nenhum certificado/desenvolvedor. Alm disso, a assinatura serve para agrupar aplicativos do mesmo autor de modo que os mesmos possam interagir entre si sem ficarem restritos pelo esquema de permisses que usualmente se aplica comunicao inter-processo. Essas aplicaes podem, inclusive, compartilhar um UID, bastando que isso seja explicitamente
65
configurado no AndroidManifest.xml de ambas. Por ltimo, a assinatura tambm permite associar uma aplicao com sua respectiva atualizao. Diferentemente da Apple Store que s disponibiliza os aplicativos para os usurios aps os mesmos terem sido manualmente avaliados por pessoal especializado, os aplicativos no Google Play no passavam por nenhum processo de avaliao, mesmo porque, o ecossistema Android permite a utilizao de outras lojas de aplicativos que no a oficial. Um ponto negativo que se pode levantar na estratgia empregada pela Apple o fato de que a reviso manual atrasa o lanamento de aplicativos, afora comprometer a eficincia da aplicao de atualizaes de segurana, aumentando ainda mais o tempo de exposio da aplicao vulnervel. A opo adotada pela loja da Google baseia-se na premissa de que, dado que impossvel ou invivel avaliar cada aplicao que submetida loja a fim de tentar identificar comportamento potencialmente malicioso, o melhor mecanismo de controle para a plataforma isolar cada aplicao juntamente com seus dados e restringir as chamadas de sistema permitidas para cada aplicao. De acordo com [Dwivedi et al. 2010], a aplicao s deve ter acesso s chamadas de sistema de forma controlada e conforme for requisitado no AndroidManifest.xml. No deve ter permisses de utilizar todas as chamadas por default. Todavia, no incio do ano, a Google apresentou uma soluo que seria empregada para avaliar as aplicaes e a intitulou de Bouncer. Descobriu-se posteriormente que era uma soluo automatizada que simula o ambiente de execuo do Android e executa o aplicativo a fim de monitorar seu comportamento e identificar funcionalidades potencialmente maliciosas. Recentemente, entretanto, em [Percoco e Schulte 2012] mostrou-se que o mecanismo pode ser facilmente contornado. Um fato que chama ateno o dado estatstico de que a maioria dos malwares para a plataforma Android foram encontrados em outras lojas que no a loja oficial [Six 2012]. Bouncer parte, a segurana nesse modelo de loja de aplicativos adotado pelo Android se alicera fortemente no usurio que est realizando a instalao de um aplicativo. Para tomar a deciso, o usurio pode se utilizar de trs fontes de informao: revises do aplicativo; reputao do desenvolvedor; e permisses requeridas [Dwivedi et al. 2010]. Um funcionalidade controversa que pode ser acionada pela Google a qualquer momento a remoo remota de aplicativos [Vidas et al. 2011]. Caso um aplicativo malicioso seja identificado e note-se que diversos usurios o instalaram, essa funo pode ser ativada a fim de que um comando seja enviado para os dispositivos em questo visando com que os mesmos removam tal aplicativo do sistema. Mas no para por a, existe uma funcionalidade que permite que a Google instale aplicativos nos dispositivos remotamente. 2.2.11. Atualizaes, Patches e Ciclo de Vida das Vulnerabilidades Como anteriormente discutido, o ncleo do sistema Android disponibilizado pela Google e em seguida os fabricantes de dispositivos os alteram ou adaptam para o seu hardware e suas necessidades a fim de criar um diferencial para o seu sistema em relao ao dos demais. Feito isso, a vez das operadoras fazerem suas prprias
66
modificaes e inclurem seus aplicativos proprietrios. S ento que o dispositivo fica pronto para ir para as lojas e chegar as mos dos usurios. Toda essa complexidade no processo resulta em um grande problema quando se trata do ciclo de vida das vulnerabilidades na plataforma. A janela de explorao nesse caso muito maior do que a vista normalmente em outros tipos de software. A seguir um breve descrio do ciclo [Vidas et al. 2011]: 1. Vulnerabilidade descoberta; 2. Vulnerabilidade reportada via NDA (Non-disclosure Agreement) ou lanada na comunidade; 3. Cdigo vulnervel pode ser de responsabilidade da equipe de desenvolvimento do Android, como pode ser de um parceiro, em um driver de dispositivo, por exemplo. a.Responsabilidade do fornecedor i.Fornecedor contatado; ii.Fornecedor libera a correo; iii.Equipe do Android libera verso contendo correo. b.Responsabilidade do Android i.Equipe do Android corrige e libera verso contendo correo. 4. Fabricantes de dispositivos adequam a verso corrigida a cada um dos diferentes aparelhos mantidos que utilizam a verso vulnervel. Isso, claro, se o dispositivo e a verso ainda estiverem sendo suportados ou se a correo no afetar nenhuma das funcionalidades sendo providas ou gerar uma incompatibilidade com outro componente; 5. Da mesma forma que os fabricantes, a operadora s adequa a correo disponibilizada pelos fabricantes a sua verso caso no afete funcionalidades ou cause incompatibilidades; 6. Ao fim de todo esse ciclo a verso corrigida disponibilizada para os usurios, seja pela operadora ou pelo prprio fabricante; 7. O usurio aplica o patch de segurana. Nota-se que o processo toda muito complexo, e que existem diversos pontos em que o sistema modificado, seja por fabricante ou por operadora. Dado que existem aproximadamente 50 fabricantes e algo em torno de 300 dispositivos [Hoog 2011], essa complexidade mostra-se ainda maior, isso sem levar em considerao a quantidade de operadoras. Toda essa complexidade na liberao de patches e na manuteno dos dispositivos com as verses mais atualizadas do sistema resulta em uma janela explorao muito grande. E, devido ao fato de serem lanadas verses corrigidas por alguns fabricantes e operadoras mais rapidamente do que as demais, os atacantes podem fazer engenharia reversa desses patches visando entender a vulnerabilidade corrigida de modo que se possa criar os exploits associados e obter acesso ao dispositivos cuja correo ainda no foi ou nunca ser liberada [Vidas et al. 2011].
2.3.
Segurana de Aplicaes
Com a crescente preocupao com segurana, os sistema operacionais esto sendo concebidos com segurana embutida no processo de desenvolvimento, prticas de desenvolvimento seguro vm sendo seguidas, afora serem criados/aplicados controles
67
de segurana a fim de dificultar ou impossibilitar exploraes ao sistema. Ademais, existe um quantidade muito maior de aplicativos difundidos no mercado do que sistemas operacionais, e a quantidade de desenvolvedores de SOs muito inferior a de desenvolvedores de aplicativos, alm de que os primeiros normalmente so muito mais experientes e possuem um conhecimento de computao muito mais consistente do que os ltimos. Disso resulta uma quantidade muito maior de aplicativos vulnerveis do que de SOs. Como mostrou-se em 2.2, o Android permite o confinamento de aplicaes por meio de uma modificao do sistema de permisses de usurio tradicional do Linux. Cada aplicao roda como se fosse um usurio, ou seja, possui um UID exclusivo e um diretrio para armazenamento de seus dados que restrito pelo esquema de permisses do sistema de arquivos apenas a ela. Esse modelo s pode ser "quebrado" por aplicaes assinadas com o mesmo certificado digital e que explicitamente requeiram o compartilhamento do UID via o arquivo Manifest [Six 2012]. Alm de impossibilitar o acesso entre aplicaes, um mecanismo de segurana eficaz deveria limitar o acesso das aplicaes a chamadas de API mais crticas, a fim de assegurar a aplicao do princpio do menor privilgio, de modo que aplicaes que provm diverso para o usurio no sejam capazes de acessar a rede Wi-Fi, Bluetooth, cmera, servios de localizao e funes de telefonia, de SMS/MMS e de dados da rede celular. Sendo assim, criou-se um esquema de permisses que limitam o acesso das aplicaes a chamadas da API. Esse esquema chamado de Manifest Permissions, isso pelo fato de as mesmas serem especificadas no arquivo AndroidManifest.xml distribudo juntamente com o aplicativo. Desse modo, caso haja uma vulnerabilidade na aplicao que permita uma explorao, o cdigo injetado ficar confinado no ambiente desta aplicao e ter apenas os privilgios que a mesma possua. Ou seja, a explorao de uma vulnerabilidade em um jogo, por exemplo, no permitiria que informaes de contatos fossem obtidas por meio de cdigo injetado, isso, claro, se as devidas permisses tiverem sido atribudas ao jogo em questo. O esquema funciona da seguinte maneira: 1. O desenvolvedor lista no AndroidManifest.xml todas as permisses necessrias para o funcionamento da aplicao; 2. Durante a instalao desta, o usurio alertado sobre as permisses sendo requisitadas, tendo a opo de aceit-las ou no; a.Modelo tudo ou nada. Ou o usurio aceita e utiliza a aplicao ou nega e a aplicao no instalada. 3. Aps a aceitao do usurio, a aplicao instalada e passa a desfrutar das permisses que lhe foram atribudas. O usurio no mais informado sobre as permisses sendo utilizadas; 4. possvel, por meio das configuraes do sistema, visualizar as permisses atribudas a cada aplicao instalada; 5. O usurio tambm pode desabilitar globalmente algumas funcionalidades, tais como: Wi-Fi, Bluetooth, servios de localizao, GPS e rede celular. A gerao de uma nova verso de uma aplicao pode resultar na alterao dos privilgios necessrios para o correto funcionamento da mesma. Nesse caso, a
68
atualizao no ocorrer de modo automtico, sendo necessria a interao do usurio para avaliar as novas permisses requeridas a fim de aceit-las ou no. Uma grande crtica a esse modelo de delegar a responsabilidade para o usurio o fato de que estes, normalmente, mal leem mensagens informativas, ainda mais se tratando de mensagens relacionadas segurana. A exemplo da aceitao de certificados invlidos nos navegadores, isso decorre do fato de os usurios considerarem tais mensagens como empecilhos para a usabilidade da aplicao ou do sistema. Adicionalmente, podem existir problemas com a implementao desse mecanismo de permisses que permitam o contorno das mesmas, como demonstrado por [Lineberry et al. 2010]. 2.3.1. Permisses de APIs (Manifest permissions) Existem duas faces quando se trata dessas permisses. A primeira quando se est utilizando APIs e servios disponibilizados pelo sistema. Neste caso necessrio levantar quais permisses so requeridas pelas funcionalidades sendo utilizadas a fim de inclu-las no Manifest do aplicativo. A segunda quando se est disponibilizando servios. Neste caso, necessrio assegurar que os componentes e aplicaes utilizando-os possuem as devidas permisses para realizar as operaes sendo fornecidas. A aplicao de algumas permisses so deixadas a cargo do kernel. Por exemplo, as permisses de acesso internet, escrita em dispositivos de armazenamento externo e ao Bluetooth so concebidas por meio da criao de grupos no sistema. Ao requisitar a permisso de acesso internet, por exemplo, o UID da aplicao adicionado ao grupo inet, desse modo, tornando possvel o acesso s chamadas de sistema associadas. Essa estratgia permite a manuteno do sistema de permisses, geralmente para acesso a sensores, ainda que haja um comprometimento na mquina virtual. As permisses default do Android so divididas em 4 categorias, chamadas nveis de proteo, a saber: 1. Normal - categoria de permisses, que so aceitas automaticamente durante a instalao pelo fato de no resultarem em violao de segurana. Exemplos de permisses incluem: SET_ALARM, SET_WALLPAPER, VIBRATE, FLASHLIGHT, KILL_BACKGROUND_PROCESSES e READ_SETTINGS; 2. Dangerous - permisses que realmente impactam na segurana do usurio e do dispositivo. Essas permisses so informadas ao usurio em tempo de instalao e s so delegadas caso este as aceite. Exemplos incluem: ACCESS_FINE_LOCATION, READ_CALL_LOG, CAMERA, INTERNET e WRITE_SETTINGS; 3. Signature - uma permisso nessa categoria automaticamente concedida a aplicaes assinadas como o mesmo certificado digital da aplicao que a criou, caso contrrio, ela negada. Esse nvel de proteo permite o compartilhamento de dados entre aplicaes do mesmo desenvolvedor, entretanto, a maior motivao para esse nvel o controle de permisses extremamente crticas. Como tais permisses so criadas por aplicaes pr-instaladas, as mesmas s podero ser acessadas por cdigo assinado pelo fabricante. Exemplos incluem: DEVICE_POWER, HARDWARE_TEST e INJECT_EVENTS;
69
4. SignatureOrSystem - similar ao nvel Signature, contudo, inclui tambm cdigo da imagem do sistema, ou seja, uma permisso nesse nvel concedida tanto se for requisitada por uma aplicao assinada com o mesmo certificado da aplicao que a criou, como se o for por cdigo que faz parte da imagem do sistema. Concebido visando permitir que os diversos provedores de aplicaes do sistema - OHA, fabricante e operadora - possam obter algumas permisses chave. Dentre as permisses nesse nvel encontram-se: ACCESS_CACHE_FILESYSTEM, ACCESS_DOWNLOAD_MANAGER, BACKUP, CALL_PRIVILEGED, DELETE_PACKAGES e SET_TIME. Alm dessas permisses default do sistema, os desenvolvedores podem criar suas prprias permisses objetivando criar controles de acesso a servios providos por suas aplicaes por meio de componentes como Activities, Services, Content Providers e Broadcast Receivers. O Quadro 1 ilustra justamente a criao de uma permisso, enquanto que o Quadro 2, a maneira de se especificar as permisses necessrias para o correto funcionamento de uma aplicao.
Quadro 1: Definio de uma permisso no arquivo AndroidManifest.xml.
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" > <permission android:name="com.me.app.myapp.permission.MY_ACTIVITY" android:label="@string/permlab_MyActivity" android:description="@string/permdesc_MyActivity" android:permissionGroup="android.permission-group.COST_MONEY" android:protectionLevel="dangerous" /> ... </manifest>
Quadro 2: Especificao no AndroidManifest.xml das permisses requisitadas pela aplicao.

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app.myapp" > <uses-permission android:name="android.permission.INTERNET" /> ... </manifest>
2.3.2. Componentes de Aplicao Uma aplicao Android possui quatro componentes principais, os quais so citados e melhores explicados abaixo: Activities: Podem ser vistas como a camada de apresentao das aplicaes. Cada tela de uma aplicao geralmente uma Activity. Services: Componente que permite a execuo de tarefas em background. So definidos, por exemplo, para checar atualizaes no Facebook - tais como novas requisies de amizade, novas mensagens ou notificaes - ou para tocar uma msica em background. No primeiro caso chamado de Bound Service, pois permite a interao com outros componentes via IPC, j no segundo, chamado de Started Service pois realiza sua funo sem qualquer tipo de interao com outros componentes. Content Provider: uma interface que permite a uma aplicao disponibilizar seus dados para acesso de leitura e escrita para outras aplicaes por meio de
70
URIs (Uniform Resource Identifier) do tipo: content://com.me.app. myapp.mailprovider/messages/inbox/16. Normalmente utilizada para disponibilizar acesso a uma base SQL. Broadcast Receivers: funcionam como manipuladores de eventos. Ficam em modo de escuta esperando por Intents que podem ser enviados diretamente ao componente ou o sistema pode designar determinado Broadcast Receiver para trat-lo de acordo com o IntentFilter definido.
Normalmente, esses componentes so executados no mesmo processo da aplicao, ou seja, diversos componentes compartilham um mesmo processo. Contudo, possvel, via arquivo Manifest, fazer com que um componente execute seu prprio processo. Ademais, segundo [Six 2012], possvel que dois componentes que fazem parte de aplicativos distintos, porm, escritos pelo mesmo desenvolvedor, possam compartilhar um mesmo processo. 2.3.2.1. Intent Os Intents so estruturas de dados que permitem a requisio de uma operao. So, de fato, a base do mecanismo de IPC do Android. De acordo com [Six 2012], Intents podem ser criados por uma aplicao e enviados para componentes especficos ou podem ser enviados para todos os componentes do sistema por meio de broadcasts. Normalmente, Intents so criados a fim de iniciar Activities ou Services, todavia, podem carregar dados para serem tratados por algum componente especificado ou enviar os dados e esperar que algum componente seja capaz de faz-lo. Um componente pode especificar, via sua definio no AndroidManifest.xml, IntentFilters visando demonstrar interesse em determinados Intents. Por exemplo, podese criar um Intent a fim de abrir uma URL. Nesse caso, o Activity Manager verificar qual Activity est esperando receber um Intent como esse e ento enviar, normalmente, para o navegador que tratar de processar tal requisio. O Quadro 3 ilustra a definio de uma Activity com um IntentFilter associado que demonstra interesse no recebimento Intents requisitando visualizao de contedo HTTP.
Quadro 3: Definio de uma Activity interessada em Intents requisitando a visualizao de contedo HTTP.
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" > <activity android:name="com.me.app.myapp.BrowserActivitiy" android:label="@string/actlab_MyBrowserActivity"> <intent-filter> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="http"/> </intent-filter> </activity> ... </manifest>
Um cenrio de explorao descrito em [Dwivedi et al. 2010], quando uma aplicao envia um Intent to logo invocada. Nesse caso, deve-se assegurar que todas as aplicaes que a invocarem tenham as devidas permisses para o envio desse Intent,
71
caso contrrio, as aplicaes chamadoras poderiam utilizar essa aplicao mal escrita a fim de disparar Intents que normalmente no poderiam. Esse ataque chamado de Intent reflection. A soluo para isso a utilizao da classe PedingIntent, que cuidar para que o Intent disparado pela aplicao sendo chamada seja associado ao identificador da aplicao chamadora. 2.3.2.2.Permisses Aplicadas a Componentes possvel que componentes de diferentes aplicaes interajam entre si (comunicao inter-processo), todavia, essa interao pode expor dados sensveis de uma aplicao para a outra. Ademais, a API permite um baixo acoplamento entre os componentes devido ao IPC baseado no envio de Intents, o que pode acarretar em componentes com permisses desnecessrias de acesso a outros. A fim de tornar esse processo seguro, criou-se um esquema de permisses que permite restringir a comunicao entre os componentes. Por exemplo, possvel exigir que um componente (de outra aplicao) possua determinada permisso para iniciar uma Activity ou um Service, para acessar informaes de um Content Provider, ou ainda para enviar broadcasts para Broadcast Receivers. Para ser acessado por componentes de outras aplicaes, necessrio que o mesmo seja exportado explicitamente ou que defina ao menos um IntentFilter, caso contrrio, o componente ser privado e s poder ser acessado por componentes da prpria aplicao ou por outras aplicaes que compartilham o mesmo UID. Sendo assim, deve-se tomar cuidado sempre que expor um componente e, principalmente, na interao entre os mesmos, pois h chances deles serem usados indevidamente. possvel at que outra aplicao faa uso dessa exposio, abusando de permisses que sua aplicao possui. 2.3.3. Acesso ao Sistema de Arquivos To logo uma aplicao instalada, um diretrio criado em /data/data/ com o nome do pacote em questo. Esse diretrio associado ao UID recm criado e o controle de acesso sobre o mesmo aplicado pelo kernel do Linux. Por default apenas o dono do diretrio possui acesso irrestrito ao diretrio. Grupos e outros no possuem nenhuma permisso. Alguns diretrios nessa estrutura incluem: files/ - todos os arquivos criados pela aplicao; shared_prefs/ - A API permite a definio de modo programtico de campos nome/valor em arquivos XML (Extensible Markup Language) que so mantidos neste diretrio; databases/ - bases de dados relacionais criadas por meio do SQLite, entretanto, possvel criar bases de dados desse tipo em qualquer diretrio; cache/ - Arquivos de cache mantidos pela aplicao. Ao criar um arquivo, pode-se configurar sua permisses, dentre elas: MODE_PRIVATE - concesso de acesso total para a aplicao dona do arquivo; MODE_WORLD_READABLE - disponibilizao de acesso de leitura para qualquer aplicao no dispositivo;
72
MODE_WORLD_WRITABLE - disponibilizao de acesso de escrita para qualquer aplicao do dispositivo.
Deve-se destacar o fato de que tais permisses tambm se aplicam a bases de dados criadas via SQLite, e de que se basear nesses controles no a melhor opo do ponto de vista de segurana. O ideal utilizar Content Providers e assegurar o acesso de outros componentes a essas informaes por meio de permisses aplicadas a componentes. 2.3.4. Programao Segura Nesta subseo, so listadas e explicadas tcnicas e medidas que devem ser tomadas para a programao segura em dispositivos mveis, de acordo com um estudo conjunto da agncia europeia de segurana da informao e redes (ENISA) [Bansal et al. 2011], com a equipe de colaboradores do OWASP [OWASP 2011]. Alm disso, so explicados conceitos que devem ser conhecidos pelo programador para que o mesmo seja capaz de escrever cdigo mais robusto contra ataques, seja ele voltado para Android ou no [Six 2011]. Foi elaborada uma lista com as boas prticas e medidas a serem tomadas pelo programador, a fim de auxiliar o processo de implementao e reviso do aplicativo: Identifique e proteja dados sensveis no dispositivo mvel: o Dispositivos mveis so, como o prprio nome diz, mveis. Por isso, possuem maior chance de perda ou roubo do que um computador pessoal; o Dados sensveis precisam ser protegidos (com criptografia, por exemplo), a fim de minimizar os riscos e o dano do roubo ou da perda de dados e do aparelho; o Outro meio de se proteger os dados o armazenamento no servidor ao invs de no prprio dispositivo. Criao de sites para smartphones e tablets: o Crie URLs seguras e intuitivas; o A falta de padro aumenta o potencial de phishing. Concesso de acesso a arquivos a outras aplicaes [Dwivedi et al. 2010]: o Cuidado ao armazenar contedo sensvel nestes arquivos; o Verifique se alteraes nesses dados poderiam causar danos ao negcio; o Teste se alteraes podem resultar em um vetor de injeo, caso a aplicao considere tais arquivos como fonte confivel de dados e no os valide antes de process-los; o Outras aplicaes no devem possuir permisso de escrita sobre cdigos executveis e arquivos de configurao; o Outras aplicaes, geralmente, no devem possuir permisso de leitura sobre arquivos de log e bases de dados. Armazene e transmita de forma segura as credenciais do usurio:
73
o Spywares e malwares esto cada dia mais comuns em dispositivos mveis, sobretudo em Android; o Uma credencial, se roubada, pode permitir o acesso no autorizado a funcionalidades e dados no s do prprio servio que usa tais credenciais como de outros servios do usurio. Caso seja uma autenticao compartilhada por outros servios (como a do Facebook), o risco ainda maior; o Permita ao usurio ter a opo de mudar sua senha e, sempre que for necessrio o armazenamento, utilize criptografia. Sempre proteja dados sensveis durante a transmisso: o Dispositivos mveis modernos podem se utilizar de vrias redes para comunicao (como Wi-Fi, GSM e Bluetooth). Durante a transmisso, dados podem ser capturados, se transmitidos atravs de canais inseguros; o Tente sempre usar encriptao ponto a ponto atravs de canais seguros, como o SSL/TLS. Faa uma integrao segura com servios e aplicaes de terceiros: o Usurios podem instalar aplicativos maliciosos, os quais vo se aproveitar da integrao para obter e transmitir dados sensveis; o Sempre faa a validao dos dados recebidos e enviados de outros aplicativos. Mantenha os servios externos sempre seguros: o Caso o servidor backend comunicante com o dispositivo mvel no esteja sempre atualizado e seguro, possvel um ataque no mesmo proveniente de um aparelho que foi comprometido. Implemente autenticao e gerenciamento de sesso corretamente: o O uso indevido da autenticao e do gerenciamento de sesso permite que um atacante faa um acesso indevido ao sistema, e que o mesmo reuse tokens ou cookies; o Utilize a classe AccountManager, disponvel no Android, para o uso de tokens na autenticao com servidores. O uso do AccountManager com o Authenticator o ideal para a autenticao dos usurios, ao invs de verificao de login e senha; o Pea ao usurio para que use senhas fortes e utilize protocolos seguros de comunicao. Preste ateno ao coletar e usar dados pessoais do usurio: o Crie uma poltica de privacidade e pea o consenso do usurio antes da coleta e uso dos dados do mesmo. Crie programas com provisionamento de segurana: o Os aplicativos devem permitir o uso de atualizaes de segurana para resolver possveis problemas futuros.
74
Implemente controles para prevenir o acesso no autorizado a recursos de pagamento: o Existem vrios meios de pagamento disponveis hoje em um aparelho com Android. Tome cuidado com as chamadas a APIs e o uso de tais servios, assim como tenha protees contra o acesso s mesmas.
Antes de publicar, lembre-se de ofuscar o cdigo: o Use uma ferramenta de ofuscao de cdigo para proteger o contedo do mesmo. O cdigo-fonte de um aplicativo Android facilmente revelado por meio de engenharia reversa, e a ofuscao uma boa ttica para dificultar este processo; o A Google disponibiliza uma ferramenta chamada ProGuard a qual diminui, otimiza e ofusca seu cdigo Android [Android Developers Project 2012d]. Ela pode ser baixada e usada gratuitamente [Lafortune 2012].
Cuidado ao utilizar o sistema de permisses: o Sempre especifique permisses estaticamente durante a definio dos componentes no arquivo Manifest, assegurando assim que todos os mtodos de um componente vo estar com as permisses adequadas; o Se houver a necessidade de gerenciar tais permisses programaticamente, deve-se aplicar checagens por meio de chamadas a checkCallingPermission sempre que operaes crticas ou sensveis estiverem para ser realizadas; o recomendado evitar a utilizao do mtodo checkCallingOrSelf Permission, o que pode permitir sequestro de permisses; o Se considerar necessrio, crie permisses especficas para seu aplicativo.
No abuse da geolocalizao: o Aplique o princpio do menor privilgio ao utilizar os servios de localizao. Se voc s precisar saber a cidade do usurio, por exemplo, s pea isso para a API; o Descarte os dados aps o uso; o Mantenha os dados annimos; o D a opo de o usurio digitar sua prpria localizao ao invs de ativar a geolocalizao.
Proteja seu Content Provider contra injeo de comandos: o Separe dados de comandos SQL por meio da utilizao de statements preparados, ao invs de concatenar os dados aos comandos SQL.
Preste ateno nas boas prticas de programao independentes de linguagem e plataforma: o Teste exaustivamente seu aplicativos; o Valide todas as entradas;
75
o Tente fazer um cdigo pequeno e sem muita complexidade; o Use analisadores de cdigo esttico e dinmico, para levantamento das vulnerabilidades grosseiras; o Use o mnimo de privilgios possvel, e tenha cuidado com os privilgios necessrios pelas APIs utilizadas; o No autorize nenhum cdigo a ser executado em nvel administrativo; o Tente no abrir nenhuma porta especfica para comunicao, e muito menos a deixe aberta em listening. Use sempre os mecanismos de comunicao j disponibilizados pelo prprio sistema operacional; o No deixe cdigos de teste na verso final da aplicao; o Crie logs para o aplicativo, porm com cuidado para que no haja vazamento de informaes sensveis.
2.4.
Anlise de Artefatos Maliciosos
Nesta seo so apresentados ataques via cdigo malicioso plataforma Android. So introduzidas tcnicas para (1) anlise esttica, (2) dinmica e (3) via depurador dos artefatos. A primeira envolve a inspeo do bytecode ou cdigo de mquina, com o auxlio de tcnicas e ferramentas para disassembly e descompilao. J a segunda envolve o monitoramento e a interao com o aplicativo em execuo. Por fim, a terceira combina as duas anteriores, e permite intercalar entre uma e outra, possibilitando enxergar a execuo sob a perspectiva mais adequada para o momento. Para tornar claro o tipo de aplicao maliciosa que ser tratada, so necessrias algumas definies [Felt et al. 2011]: Malware o software que rouba, modifica, ou apaga dados de aplicaes ou do sistema operacional do usurio sem o consentimento deste. Isto , no foi obtida autorizao prvia do usurio para a realizao destas atividades. Em outras palavras, o software foi desonesto com o usurio. Spyware definido como software que captura informaes pessoais privadas de um usurio. A diferena entre este tipo e o malware que na instalao do software houve consentimento do agente instalador (a pessoa que o instalou). Em outras palavras, o software foi honesto com o usurio que o instalou, apesar de que ele, o spyware, provavelmente causar algum tipo de dano ao usurio alvo (usurio que utilizar o dispositivo aps instalao). Nesta seo consideraremos somente ameaas do tipo malware. No entanto, as tcnicas e ferramentas apresentadas se aplicam a spywares, ou a qualquer outro tipo software malicioso ou benigno. Todas as ferramentas citadas nesta seo so gratuitas e de cdigo aberto, exceto onde for dito o contrrio. 2.4.1. Organizao do Cdigo de uma Aplicao definida nesta subseo conceitos importantes sobre a organizao do cdigo de aplicaes Android que sero utilizados em subsees subsequentes. As principais estruturas de cdigo de uma aplicao so:
76
Bytecodes Dalvik: instrues da mquina virtual Dalvik (DVM). So executadas por uma instncia da DVM, dentro do processo Linux desta instncia. Dex (Dex Executable): um formato de cdigo executvel para a DVM. Um arquivo .dex pode ser abstrado como uma coleo de arquivos compilados, cada um correspondendo a uma classe do cdigo fonte original. Os arquivos compilados so arquivos binrios contendo bytecodes Dalvik.
A Figura 2 ilustra o processo a partir do qual um ou mais arquivos de cdigo fonte na linguagem Java so transformados em um arquivo Dex. O programa javac o compilador Java distribudo pelo projeto Apache Harmony (e incorporado ao Android Software Development Kit, ou Android SDK), e transforma um cdigo fonte Java em arquivos .class, os quais contm bytecodes da JVM (Java Virtual Machine). Por sua vez, o programa dx distribudo no Android SDK, e transforma os bytecodes da JVM em bytecodes da DVM.
Figura 2: Transformao de cdigo fonte Java em Dex. Fonte: [Strazzere 2012].
Uma verso otimizado do arquivo .dex, chamada oDex (optimized Dex), criada aps a primeira execuo do aplicativo. Em execues posteriores do aplicativo, o contedo do arquivo .odex mapeado diretamente em memria. Referimos o leitor aos trabalhos [Android Open Source Project 2012c], [Strazzere 2012], [Bornstein 2008] e [Huang 2012] para mais detalhes sobre a estrutura, construo e execuo de aplicaes Android. 2.4.2. Ameaas de Cdigo Malicioso para Android O trabalho [Zhou e Jiang 2012] apresentou o resultado da anlise de 1260 amostras em 49 famlias, coletadas de Agosto de 2010 a Outubro de 2011, e constitui a anlise mais completa realizada at hoje sobre a caracterizao e evoluo de malwares para a plataforma Android. Os resultados mostram que 86% das amostras so trojans que reempacotam aplicaes legtimas com a adio de payload malicioso (daqui em diante chamados malwares de re-empacotamento). Em relao natureza do payload malicioso, 51% das amostras roubam informaes do usurio (credenciais em aplicaes e mensagens SMS). Segundo [Felt et al. 2011], os principais comportamentos dos malwares para dispositivos mveis so: (1) roubo de informaes sobre o usurio/dispositivo (exceto credenciais) (61%); (2) envio de mensagens de SMS para nmeros premium (52%); (3) outras ameaas (43%): SMS spam, roubo de credenciais, SEO (Search Engine Optimization) fraud e pagamento de resgate para recuperao dos dados (ransonware). Alm do tradicional re-empacotamento de aplicaes legtimas, destacam-se outros dois mecanimos utilizados pelos agentes de ameaa para infectar o dispositivo ou iniciar a execuo do payload: update attack e drive-by download attack.
77
2.4.2.1. Update Attack Alm da insero do payload inteiro na verso inicial do malware recebida pelo usurio, possivelmente do tipo re-empacotamento, muitas amostras utilizam o chamado update attack para dificultar a deteco. Este ataque constitui infectar o usurio com uma aplicao a princpio benigna (isoladamente), e ento em algum momento depois solicitar ao usurio a instalao de uma atualizao desta aplicao, esta ltima sim executa aes maliciosas. O arquivo APK com a nova verso da aplicao pode estar contido dentro do diretrio res da aplicao ou pode ser baixado da internet. Uma variante do update attack, empregada pelos malwares AnserverBot e Plankton, no instala uma aplicao inteira, mas sim carrega dinamicamente pacotes de classes (ou aplicaes inteiras) atravs dos mtodos da classe DexClassLoader. A vantagem desta variante sobre a tcnica original de que no solicitada a autorizao ao usurio. O caso de uso legtimo, devido ao qual esta tcnica de carga dinmica de classes foi introduzida no Android, foi permitir que jogos utilizassem contedo multimdia e cdigo alm do limite de 50 MB de um pacote APK. 2.4.2.2. Drive-by Download Attack Outra tcnica comumente utilizada o drive-by download, a qual empregada em campanhas de malware para desktops, mas l est usualmente associado explorao de vulnerabilidades no navegador web do usurio e consequente execuo de payloads maliciosos sem interao com o usurio (exceto o acesso deste ao website contendo o exploit). No contexto de dispositivos mveis, este termo denota a tcnica de convencimento do usurio para que ele instale a aplicao maliciosa, esta ltima ofertando uma facilidade para o usurio, ou se passando como obrigatria para que ele possa realizar certa tarefa. Um exemplo deste tipo de drive-by download so os cavalos-de-tria para fraude bancria Spitmo [Heyman 2011] e Zitmo [Maslennikov 2011], os quais atuam em conjunto com os seus primos para desktops, SpyEye e Zeus, para realizao de fraudes combinadas. Um usurio com o PC infectado com um destes malwares acessa o website do seu banco, e ento em um dado momento da navegao apresentado ao usurio uma pgina web pedindo que ele instale uma aplicao do banco para o seu celular, com um argumento do gnero: para melhor proteger a segurana de suas atividades com o internet banking. A aplicao neste caso um mobile malware que intercepta cdigos de autenticao de transaes mTAN (Mobile Transaction Authentication Number) enviados pelo banco para o dispositivo via SMS. A interceptao usada para ler o cdigo de autenticao da transao fraudulenta recebido via SMS (que o atacante iniciou atravs de um desktop, usando as credenciais roubadas do PC da vtima) e ento esconder ou apagar esta mensagem da lista de mensagens SMS visveis pelo usurio. Uma variante dessa tcnica, empregada pelo malware Android/NotCompatible [Li 2012], consiste no download da aplicao maliciosa sem a autorizao do usurio. O usurio acessa a pgina web com o cdigo web malicioso, o malware baixado no diretrio padro de downloads do navegador web, mas no executado automaticamente. Em algum momento no futuro o usurio ir se deparar com o arquivo APK do malware, seja na lista de downloads do seu navegador, ou, mais provavelmente, na lista de mensagens de notificao de aplicaes. Para atrair o usurio
78
a executar a aplicao, o atacante utiliza nomes como Update.apk, SystemUpdate.apk ou FacebookUpdate.apk. Para que a aplicao seja instalada necessrio que a opo Permitir a instalao de aplicativos de fontes desconhecidas esteja habilitada nas configuraes de sistema. Caso no esteja habilitada, o usurio ser alertado sobre os riscos da habilitao e instrudo sobre como efetu-la. 2.4.2.3. Anlise Esttica A anlise esttica de malware procura derivar o comportamento do malware extraindo caractersticas de seu cdigo sem execut-lo. Para tanto, so empregadas tcnicas como: identificao do(s) empacotador(es) utilizado(s) (se houver), desempacotamento esttico (se possvel), anlise das strings presentes no programa, deteco de cdigo/dado encriptado, dissassembling (desmontagem) e descompilao. 2.4.2.3.1.Processo de Anlise Esttica Passos para anlise de uma aplicao genrica, Exemplo: 1. Descomprima o arquivo Exemplo.apk (pacote da aplicao). O resultado o seguinte diretrio Exemplo.apk_FILES/ META-INF/ res/ AndroidManifest.xml classes.dex resources.asrc 1.1. O arquivo AndroidManifest.xml contm o arquivo de manifesto da aplicao, em formato binrio. Para convert-lo para um formato texto legvel, use o AXMLPrinter. 1.2. O diretrio res contm os recursos (no cdigo) da aplicao. 2. Identifique no AndroidManifest.xml as classes das Activities, os servios, as permisses, etc. 3. Execute o Dex2Jar sobre o arquivo Exemplo.apk, obtendo Exemplo_dex2jar.jar. 4. Abra o arquivo Exemplo_dex2jar.jar no descompilador JD. Um descompilador alternativo o DED. 5. Analise o cdigo Java da aplicao. 2.4.2.3.2. Ferramentas para Anlise Esttica Uma ferramenta alternativa ao par Dex2Jar/JD o APKInspector, que alm de ter a maioria dos recursos das duas ferramentas anteriores, ainda suporta a gerao e visualizao do CFG (Control Flow Graph). Se a aplicao Exemplo.apk contm biblioteca com cdigo nativo, ento havero subdiretrios adicionais abaixo da raiz, lib/armeabi/, onde armeabi conter arquivos lib*.so. Estas bibliotecas contm cdigo nativo para processadores ARM.
79
Para efetuar a engenharia reversa do cdigo destas podem ser utilizadas ferramentas de dissassembling (objdump) e descompilao (Hex-Rays ARM Decompiler, comercial) de cdigo ARM. Androguard um conjunto de ferramentas para anlise de cdigo de aplicaes Android, permitindo controle programtico sobre o processo de disassembly, descompilao, anlise e visualizao do grafo de chamadas de mtodos. Dentre os seus recursos esto a comparao por similaridade de duas aplicaes (androsym.py) ou a comparao exata (androdiff.py), possibilitando, por exemplo, a deteco de malware do tipo re-empacotamento, de plgio ou de diferenas entre uma aplicao e sua atualizao. 2.4.2.4. Anlise Dinmica A anlise dinmica consiste no monitoramento da execuo do malware (com ou sem a interao manual do analista), atravs do emprego de ferramentas para monitorao de processos do sistema operacional, incluindo a monitorao das atividades de E/S em memria no voltil, E/S de rede, chamadas a bibliotecas e chamadas ao sistema operacional. Neste tipo de anlise, o malware de fato executado, e portanto as atividades maliciosas por este executadas afetam o dispositivo (real ou emulado) onde este est sendo executado, e tambm podem afetar outros dispositivo com os quais este possa se comunicar (dispositivos acessveis pela LAN (Local Area Network), internet, redes de telefonia). Para tanto, necessrio prover um ambiente isolado para a sua execuo, de modo que no interfira com os dispositivos na LAN, ou at mesmo limitar (ou proibir) o acesso deste s redes, atravs de filtragem de trfego, por exemplo. Em geral, a anlise esttica pode ser realizada mais rapidamente do que a anlise dinmica, desde que: o malware a ser analisado no possua muitos fluxos de execuo dependentes de dados de entrada do usurio (ou do ambiente de execuo), se este puder ser desempacotado estaticamente, e se as strings/cdigo no tiverem sido encriptados ou ofuscados. Entretanto, praticamente todos os malwares modernos para sistemas operacionais de desktop e para o Android empregam pelo menos uma destas tcnicas, tornando a anlise esttica completa mais difcil e custosa. Para estes casos, a anlise dinmica e a anlise com depurador provm resultados eficazes muito mais rapidamente do que a anlise esttica, principalmente no incio da anlise, pois permitem determinar os trechos do cdigo da aplicao onde est a atividade maliciosa, de modo que o analista possa se concentrar somente em tais pontos. 2.4.2.4.1. DroidBox: Android Application Sandbox O DroidBox um programa projetado para oferecer anlise dinmica em aplicaes Android. Utiliza tcnicas que proporcionam uma perspectiva com relao ao comportamento de um APK, possibilitando detectar comportamentos maliciosos, que violem a privacidade do usurio, ou comportamentos indesejados de modo geral. Aps a anlise da aplicao so obtidas diversas informaes, tais como: hashes do pacote sob anlise, entrada e sada de dados pela rede, servios iniciados, classes carregadas dinamicamente via DexClassLoader, permisses contornadas, operaes
80
criptogrficas realizadas usando as APIs criptogrficas do Android e vazamento de informaes atravs da rede, arquivos e SMS. Para realizar este monitoramento, a ferramenta insere hooks (ganchos) em mtodos da API do Android, interceptando as chamadas que o APK faz a estes mtodos. Isto , o DroidBox obtm o valor dos parmetros de entrada e de sada em tais chamadas, podendo modific-los. Esta tcnica exige a modificao do cdigo de bibliotecas do sistema operacional Android, e a abordagem utilizada atualmente pelo Droidbox. Devido modificao feita no cdigo da plataforma, a ferramenta DroidBox suporta somente anlise em emulador. Devido rpida mudana no sistema operacional Android, os autores do DroidBox esto implementando uma abordagem diferente da atual (hooking de bibliotecas do Android), a qual permitir que o DroidBox funcione com as novas verses do Android sem grandes esforos de portabilidade. A implementao desta nova abordagem chama-se APIMonitor, est disponvel em verso beta, e consiste em inserir os hooks no cdigo da prpria aplicao, isto significa que ser gerado um novo APK baseado no original, o qual conter cdigo extra que far o monitoramento. Uma vantagem adicional desta abordagem que ela torna possvel a anlise de uma aplicao executando em um dispositivo real, e no somente em um dispositivo emulado. 2.4.2.4.2. DDMS: Dalvik Debug Monitor Server O DDMS [Android Developers Project 2012b] um programa disponvel no Android SDK, o qual permite o monitoramento de processos em execuo no sistema, captura de screenshots, coleta de informaes sobre threads e pilhas, iniciao de chamadas telefnicas de entrada (para o dispositivo), e envio de mensagens SMS de entrada. Dentre as suas funcionalidades encontra-se o tracing de chamadas de mtodos, a qual til para anlise dinmica de aplicaes. Este programa pode ser executado em dispositivos emulados e em dispositivos reais, lembrando que a depurao via USB deve estar habilitada. Para analisar uma aplicao usando o DDMS, pode-se proceder assim: (1) descompile o APK da amostra a ser analisada; (2) crie um projeto no Eclipse com o cdigo e recursos resultantes; (3) Abra o painel do DDMS e conecte-se ao dispositivo e; (4) inicie a execuo da aplicao no dispositivo; (4) no DDMS, inicie o method profiling; (4) interaja com a aplicao; (5) pare o method profiling; (6) O trace resultante pode ser visualizado no painel TraceView. A ferramenta dmtracedump, tambm disponvel no Android SDK, produz uma representao em imagem do grafo das chamadas de mtodos do arquivo gerado pelo DDMS, facilitando a sua visualizao. Para um controle mais fino sobre quais mtodos devem ser monitorados, podem ser inseridos os mtodos startMethodTracing e stopMethodTracing da classe Debug no cdigo da aplicao [Android Developers Project 2012e]. 2.4.2.4.3.Andrubis O Andrubis um ambiente, disponibilizado como um servio e de cdigo fechado, desenvolvido para analisar o comportamento e as propriedades de aplicativos Android, que possibilita uma viso ampla sobre diversos aspectos de uma aplicao. So empregadas abordagens de anlise esttica e dinmica utilizando quatro ferramentas
81
gratuitas e de cdigo aberto, alm do prprio Android SDK: DroidBox, TaintDroid, Apktool e Androguard. Na anlise dinmica os aplicativos Android so executados em um emulador, cujo resultado um relatrio informando os vazamentos de informaes privadas do usurio, operaes com arquivos, trfego de rede, operaes criptogrficas com a API criptogrfica do Android e carregamento dinmico de cdigo (mtodo DexClassLoader e biblioteca de cdigo nativo via JNI). Por sua vez, a anlise esttica exibe as permisses requisitadas pela aplicao e aquelas que de fato so utilizadas (e em quais mtodos). 2.4.2.5. Anlise com Depurador Nem sempre as abordagens de anlise anteriores so suficientes, s vezes necessrio combin-las, intercalando entre uma e outra adaptativamente, de modo a enxergar a execuo sob a perspectiva mais adequada para o momento. Nestas situaes, a anlise com depurador essencial. Uma primeira abordagem para depurao de uma amostra de malware usar o depurador para aplicaes Java (JDWP Debugger) que j vem integrado ao Eclipse, o qual implementa o protocolo JDWP (Java Debug Wire Protocol) suportado pela Dalvik VM (Figura 3). Para utilizar este mtodo necessrio o cdigo-fonte da aplicao. Portanto, necessrio primeiramente descompilar a aplicao, e ento criar um projeto no Eclipse com o cdigo e recursos resultantes. Algumas limitaes so: o fato de que os dissassemblers/descompiladores para bytecodes Dalvik atuais no so capazes de descompilar certos trechos de cdigo vlido; somente possvel depurar cdigo fonte Java; e nem todo cdigo descompilado ser compatvel com a API do Android.
Figura 3: Ferramentas para monitoramento e depurao no Android SDK (host) e SO Android (alvo). (Fonte: [Android Developers Project 2012a[)
O uso do depurador AndBug uma opo ao depurador JDWP, que no exige a descompilao e permite controle fino da depurao, mas tambm limitada a cdigo Java, alm de ainda estar em verso instvel. Para depurar aplicaes Android com bibliotecas de cdigo nativo, e quando no se possui o cdigo-fonte destas bibliotecas (o caso de uma amostra de malware),
82
necessrio o Android NDK, um dissassembler ARM (p. ex., o IDA Pro), e a reconstruo manual dos Makefiles da biblioteca. O processo para depurao usando estas ferramentas muito dependente do modo como a aplicao a ser analisada foi construda, e descrito com detalhes para uma aplicao de exemplo em [Jakev 2012a] e [Jakev 2012b]. 2.4.3. Tcnicas de Evaso Atualmente, os malwares para Android tm adotado tcnicas anti-deteco por antivrus, anti-anlise dinmica e anti-anlise esttica. Enumeramos abaixo algumas destas tcnicas. Delay. O malware atrasa a execuo das atividades maliciosas, realizando-as horas ou at dias aps a infeco. Agendamento. Comportamento dependente da data em que a amostra executada. O malware consulta data corrente atravs de chamada API do sistema operacional e/ou consulta a servidores de hora da internet, e somente executa as atividades maliciosas se a data correta (calculada pelo voto de maioria) satisfaz alguma condio pr-definida. Ofuscao (ou encriptao) de cdigo (ou dado). As ferramentas abaixo tm sido utilizadas por aplicaes benignas para proteo de propriedade intelectual, mas tambm tem sido cada vez mais utilizadas por malware para dificultar a deteco/anlise de suas atividades: Proguard uma ferramenta que permite otimizar (em tamanho e/ou desempenho) e ofuscar bytecodes Java (incluindo Java para Android). integrada ao processo de construo de aplicaes para Android. A ferramenta no est habilitada por padro, mas se estiver, ser invocada somente quando a aplicao for construda no modo release [Android Developers Project 2012d]. Saikoa um otimizador e ofuscador comercial para bytecodes Dalvik baseado no Proguard que permite encriptao de strings e de cdigo, ocultao de chamadas a APIs crticas atravs de uso de reflexo, e insero de cdigo para deteco de modificao no autorizada da aplicao. yGuard um compactador e ofuscador para bytecode Java.
O malware DroidKungFu, por exemplo, encriptou os bytecodes Dalvik e o cdigo nativo de vrios exploits (Exploid, RATC e Zimperlich) como resource file dentro do APK e com isso no foi detectado (ao ser descoberto) por nenhum dos antivrus do mercado [Zhou e Jiang 2012]. Este exemplo mostra que a tcnica de encriptao de cdigo muito eficaz contra as tecnologias utilizadas pelos antivrus atuais para Android. Outra tcnica que tem sido empregada por malwares para dificultar a anlise esttica alterao manual dos bytecodes Dalvik de modo que um (ou mais) dissassemblers/descompiladores no consigam desmontar/descompilar parte do cdigo de seu cdigo. O trabalho [Enck et al. 2011] aponta problemas de desmontagem e descompilao de bytecodes Java de diversas aplicaes Android, at mesmo quando so utilizadas ferramentas estado-da-arte para estas atividades. A anlise de uma das variantes do malware Spitmo [Apvrille 2012a] mostrou problemas de descompilao
83
com o JD, e a autora sugeriu usar outros descompiladores, como por exemplo o JAD, para tentar resolver o problema. Em ltimo caso, a anlise dever ser feita diretamente sobre o bytecode Dalvik. Para tanto, os mesmos podem ser desmontados em mnemnicos atravs da ferramenta Baksmali. O malware RootSmart utilizou a tcnica anterior para esconder o cdigo que desofusca a URL dos servidores de C&C [Mullaney 2012], de modo que o descompilador JD no foi capaz de descompilar este trecho do cdigo, forando o analista a reconstruir manualmente o cdigo Java a partir dos bytecodes Dalvik. Outra tcnica que vem sendo empregada pelos malwares a utilizao de bibliotecas de cdigo nativo (cujas funes so invocadas pelo mecanismo JNI) e de cdigo nativo puro (sem JNI). Isto dificulta muito a anlise esttica, pois fora a anlise do cdigo Assembly da CPU do dispositivo (ARM, em sua maioria), ou a anlise do cdigo C obtido por descompilao. Existem poucos descompiladores ARM disponveis, p.ex.: Hex-Rays ARM Decompiler. Despejo (drop) de cdigo. O malware despeja cdigo contido dentro do APK. Pode ser apenas uma classe, ou ento uma aplicao (APK) inteira que ser instalada. Execuo de cdigo baixado da internet. Carga dinmica atravs da classe DexClassLoader. Exemplo: malwares Plankton e AnswerBot [Zhou e Jiang 2012]. Atualizao maliciosa. malware solicita atualizao da aplicao, o usurio autoriza, e ento as atividades maliciosas se iniciam. Tcnicas anti-emulao. deteco de execuo dentro de emulador e consequente mudana de comportamento O trabalho [Strazzere 2012] ilustrou tcnicas de anti-anlise esttica e props a ferramenta Apkfuscator para ofuscao de bytecodes Dalvik, inclusive para impossibilitar a descompilao por certos descompiladores. No sentido da anti-emulao (deteco do emulador), o trabalho [Matenaar e Schulz 2012] mostrou uma prova de conceito para a deteco de emulao via Qemu, e disponibilizou o seu cdigo-fonte. O Qemu um emulador de processadores usado como base para o emulador do Android SDK, TaintDroid, DroidBox, Andrubis e o Google Bouncer [Oberheide e Miller 2012]. 2.4.4. Desafios da Anlise de Malware para Android Alm dos desafios para lidar com as tcnicas de evaso (Subseo 2.4.3), podemos destacar os encontrados na rea de monitorao de comunicao em redes mveis. 2.4.4.1. Monitorao de Comunicao por Mensagens SMS Uma variante do malware Zitmo (Android/Zitmo.E!tr.spy) utiliza SMS para comunicao com os servidores de C&C [Apvrille 2012a], e foi analisado atravs de uma jaula GSM criada pela autora [Apvrille 2011]. O trabalho [Apvrille 2012b] mostra como foi construda tal jaula e descreve a anlise da comunicao via SMS entre um celular (o servidor C&C) e um celular infectado com o malware Zitmo. A autora montou uma estao rdio-base GSM, usando apenas: um USRP (Universal Software Radio Peripheral), um PC Linux rodando o OpenBTS (Open Base Transceiver Station) e o Asterix. A jaula construda foi
84
comparada a outros ambientes de anlise de comunicao via SMS, sob os critrios: confiabilidade, realismo, dificuldade de construo e custo. H neste assunto o desafio de integrar estes ambientes de monitorao da comunicao por mensagens SMS s ferramentas do ambiente de anlise dinmica de malware, permitindo ao analista uma viso mais completa sobre as aes do cdigo malicioso. 2.4.4.2. Monitorao da Comunicao em Redes Mveis 3G e 4G Apesar da prevalncia das redes mveis 3G em muitos pases e a recente introduo das redes 4G, no temos conhecimento sobre trabalhos a respeito da construo de estaes rdio base para monitorao (com baixo custo), e nem sobre tcnicas e ferramentas para interceptao da comunicao em redes 3G e 4G reais.
2.5.
Avaliao de Segurana
Nesta seo, so demonstradas vulnerabilidades em aplicativos para a plataforma Android, considerando a identificao das mesmas e sua importncia no contexto da mobilidade. Os aplicativos para dispositivos mveis manipulam diversas informaes sensveis dos usurios, tais como contatos, mensagens recebidas e enviadas, histrico de ligaes, emails, documentos de escritrio, fotos, vdeos, histrico de navegao, informaes de localizao, credenciais de acesso a servios online e informaes financeiras. A possvel exposio de tais informaes pode causar danos ao usurio, aumentando os riscos associados a estes aplicativos. Adicionalmente, podem existir vulnerabilidades nos aplicativos que possibilitem a execuo remota de cdigo ou o vazamento das informaes mantidas por ele para outros aplicativos, ou at mesmo para outras entidades remotas. Considerando-se o alto risco circundando tais aplicativos, faz-se necessria uma avaliao de segurana com a finalidade de assegurar a manipulao segura das informaes sensveis em todos os pontos por onde passam, alm de identificar pontos vulnerveis. O processo de avaliao de segurana em aplicaes mveis segue o mesmo formato da avaliao em aplicaes stand-alone, a qual se baseia na engenharia reversa do software, o que inclui anlise dinmica comportamental, depurao, descompilao, desmontagem, alm de se alicerar em validaes dos pontos de entrada de dados por meio de fuzzing, na captura e no tampering de trfego, e na personificao de uma das entidades, no caso de aplicativo baseado em arquitetura cliente-servidor. importante que se possua total acesso sobre o sistema a fim de que se realize uma avaliao de segurana, isso se deve ao fato de que so necessrios privilgios mais elevados a fim de executar algumas ferramentas de depurao, de acessar dados de aplicativos, etc. Para tal, pode-se utilizar um emulador ou um dispositivo que passou pelo processo de rooting. 2.5.1. Engenharia Reversa O processo de anlise de cdigo Smali (equivalente a cdigo Assembly da mquina virtual Dalvik), que pode ser obtido por meio de ferramentas como Apktool e Dedexer,
85
uma tarefa muito complexa e custosa. J a anlise de cdigo Java algo mais factvel, todavia, a descompilao pode no ser to trivial, dependendo do cenrio. Devido a esses percalos, a engenharia reversa baseia-se na anlise das permisses que podem ser obtidas no arquivo AndroidManifest.xml e nos recursos utilizados pelo aplicativo que tambm podem ser obtidos no APK. Alm disso, apoia-se na chamada reverso em nvel de sistema, a fim de levantar o comportamento do software sendo analisado, sua estrutura, componentes utilizados e os pontos de maior interesse, onde podero ser dispendidos maiores esforos. Essa estratgia se utiliza de tcnicas de monitoramento do programa sendo analisado em relao s interaes com o sistema operacional, alm de englobar a anlise das cadeias de caracteres contidas no binrio, das referncias estticas a chamadas de API, etc. Dentre as ferramentas que provm essas funcionalidades, destacam-se: DroidBox, APIMonitor e DDMS. Adicionalmente, depuradores so de extrema importncia neste processo, devido ao fato de poderem ser utilizados a fim de analisar o programa enquanto em execuo. Permitem a definio de pontos de interrupo (breakpoints) em pontos especficos do cdigo (software breakpoints) ou quando ocorre um acesso a uma regio de memria especificada (hardware breakpoints), e a execuo de instrues passo-a-passo (singlestepping) permitindo a visualizao do estado da CPU enquanto executando o programa sendo depurado. No caso da plataforma Android, o gdb (Gnu Debugger) pode ser utilizado para depurar a mquina virtual Dalvik responsvel por executar o aplicativo, e a ferramenta Andbug - que utiliza JDWP e DDMS, permitindo o hook de mtodos Dalvik, anlise do estado do processo, breakpoints, etc. permite a depurao do aplicativo. Vale ressaltar que as diversas sees do processo em execuo podem ser analisadas, tais como a regio de dados somente leitura, os dados globais inicializados e os no inicializados, assim como as regies de memria mapeadas dinamicamente como a heap e a stack. Alm disso, um bom depurador tambm deve permitir a anlise das diversas threads em execuo, bem como dos mdulos e bibliotecas carregadas pelo programa. Estratgias mais complexas e que permitem uma confiabilidade maior para a avaliao podem ser empregadas. Ferramentas como Apktool, AXMLPrinter, Baksmali, Axml2xml.pl, Dex2jar, JD, APKInspector, Ded e Androguard podem ser utilizadas. Esta classe de ferramentas tenta, a partir de um cdigo binrio, gerar um cdigo de mais alto nvel, semanticamente equivalente, que pode ser analisado mais facilmente. O foco dado na subseo atual voltado para os objetivos da engenharia reversa, em se tratando de avaliao de segurana. As tcnicas de reverso so melhor detalhadas na Seo 2.4. 2.5.1.1.Reviso de Cdigo A reviso do cdigo-fonte um passo muito importante na avaliao. A partir dela, pode-se verificar se recomendaes de programao segura, como as apresentadas anteriormente (Subseo 2.3.4) foram empregadas.
86
Deve-se checar se boas prticas da definio de componentes foram aplicadas, se permisses foram devidamente empregadas, e se os dados de IPC esto sendo adequadamente validados antes de serem utilizados. No caso de componentes, aconselha-se verificar se as decises de exportao foram acertadas, ou seja, se faz parte da lgica da aplicao que determinado componente interaja com componentes externos. Ademais, as funcionalidades do aplicativo devem ser analisadas objetivando validar se esto de fato dentro do especificado. De acordo com essas funcionalidades levantadas, analizam-se as permisses utilizadas pelo aplicativo visando assegurar o princpio do menor privilgio. As tcnicas criptogrficas utilizadas devem ser analisadas, bem como os mecanismos de autenticao e autorizao, visando levantar potenciais inconsistncias. Os mecanismos de autenticao e de autorizao, tanto do usurio para com o aplicativo mvel, como do aplicativo mvel para a aplicao backend, caso aplicvel, devem ser avaliados de modo a garantir uma implementao robusta. 2.5.1.2.Manifest e Recursos O arquivo Manifest contm muita informao relevante sobre o aplicativo e, principalmente, sobre os pontos de exposio do mesmo. Deve ser analisado com a finalidade de validar as permisses sendo definidas, sendo utilizadas e as que esto sendo aplicadas para a proteo de componentes. A ferramenta Aapt permite a converso do arquivo Manifest de XML binrio para texto, e o APKtool pode ser utilizado a fim de obter os recursos utilizados pelo aplicativo. O Manifest Explorer pode ser utilizado para exibir o contedo do Manifest de cada aplicativo instalado no sistema, fornecendo uma viso da superfcie de ataque do software [Dwivedi, Clark e Thiel 2010]. J a ferramenta Androlyze, que faz parte do pacote Androguard, pode ser utilizada para mapear as permisses de um aplicativo. Tal ferramenta capaz de levantar se as permisses requisitadas esto de fato sendo utilizadas, e ainda apresenta o mtodo ou a chamada que necessita da permisso em questo. Com o auxlio dessa, possvel verificar se permisses desnecessrias esto sendo requisitadas e levantar trechos do cdigo que exigem determinadas permisses de interesse. Uma outra ferramenta de interesse o Package Play que exibe todos os aplicativos instalados no sistema, incluindo os aplicativos adicionadas pelo fabricante e pela operadora. De acordo com [Dwivedi, Clark e Thiel 2010], por meio desta pode-se visualizar componentes, sua definio de exportao e as respectivas permisses necessrias para interagir com os mesmos, listar todas as permisses definidas e utilizadas e invocar Activities exportadas. 2.5.1.3.Acesso ao Sistema de Arquivos O monitoramento do acesso ao sistema de arquivos importante pois possibilita o mapeamento dos arquivos manipulados pelo aplicativo, facilitando a anlise das informaes neles armazenadas. As permisses de acesso aos arquivos manipulados
87
devem respeitar o princpio do menor privilgio, e informaes sensveis devem ser armazenadas de modo seguro utilizando algoritmos criptogrficos robustos. Em se tratando de informaes sensveis, deve-se verificar se de fato necessrio que as mesmas sejam persistidas no sistema de arquivos. Essa anlise est diretamente relacionada lgica de negcio do aplicativo, portanto, necessrio o entendimento do propsito desta a fim de avali-lo adequadamente. Ademais, chaves criptogrficas podem ser armazenadas no sistema de arquivos, o que uma prtica insegura. O ideal que qualquer informao sensvel, seja informaes pessoais, de localizao, credenciais de acesso, tokens de sesso ou chaves criptogrficas, simtricas ou assimtricas, deve ser protegida por tcnicas criptogrficas. A chave de encriptao e decriptao desses dados deve ser derivada de uma senha definida pelo usurio, do mesmo modo que feito pelo sistema ao se habilitar encriptao da partio de dados. Tal prtica aliada a uma poltica de senhas forte, aumenta consideravelmente a complexidade de que ataques de pr-computao e de fora bruta sejam empregados. Ainda em relao aos arquivos manipulados pelo aplicativo, importante verificar que, caso o carto SD esteja sendo utilizado, nenhuma informao sensvel esteja sendo armazenada neste. Isso pelo fato de o mecanismo de controle de acesso no se aplicar sobre essa mdia de armazenamento. Caso seja necessrio armazenar informaes desse tipo em tais mdia, deve-se armazenar o contedo encriptado. Um outro fator que deve ser levado em considerao a validao dos dados contidos em arquivos. Caso o contedo dos arquivos utilizados pela aplicao sejam acessveis por outras aplicaes, os mesmos devem ser considerados como potencialmente maliciosos e no aconselhvel confiar em seu contedo. Isso tambm vlido para o caso de aplicativos que se utilizam de arquivos pertencentes a outros aplicativos. Arquivos de log tambm devem ser inspecionados visando avaliar as informaes sendo ali armazenadas. importante que mecanismos de log registrem informaes a respeito de um evento de modo que se possa rastrear a sequncia de aes realizadas, alm de assegurar a responsabilizao. Contudo, informaes sensveis no devem ser armazenadas. Por exemplo, ao registrar uma alterao de senha por parte de um usurio, deve-se registrar o evento, todavia, no se deve registrar em log a nova senha definida. Os aplicativos podem se utilizar de arquivos especiais, tal como os arquivos de preferncias e bases de dados SQL, alm das funes de cache disponibilizadas pela API do Android. Todo o contedo armazenado nesses arquivos especiais deve ser avaliado minuciosamente assim como feito com o restante dos arquivos. Em particular, para a anlise de bases de dados SQL, pode-se utilizar ferramentas como SQLite3, SQLite Analyzer e SQLite Database Browser. Os aplicativos devidamente implementados devem se preocupar com a correta remoo de arquivos com informaes sensveis, e o monitoramento das operaes sobre o sistema de arquivos pode permitir a validao deste requisito. Ademais, esta tcnica permitiria a identificao do cdigo responsvel pela realizao desta tarefa, possibilitando uma anlise mais minuciosa via reviso desse cdigo.
88
2.5.1.4.Levantamento das Cadeias de Caracteres do Binrio Tal tcnica auxilia no processo de entendimento do software visto que pode fornecer uma srie informaes valiosas para o analista, tais como mensagens de erro, mensagens informativas, mensagens solicitando tomada de deciso, palavras ou frases que so interpretadas como comandos, etc. possvel tambm encontrar credenciais de acesso ou outras informaes sensveis, inclusive relacionadas lgica de negcios do aplicativo. Uma mensagem de erro resultado de uma operao anmala, como, por exemplo, um erro em uma operao do RSA que retorna algo do tipo: RSA operation error. Tal mensagem pode permitir a identificao do trecho do programa susceptvel a esse erro, e tal trecho, muito provavelmente, faa parte do componente que prov o suporte a tal criptossistema. Dessa forma, as rotinas responsveis pela implementao do RSA neste software poderiam ser identificadas para anlise. De forma semelhante, uma mensagem como "Deseja realmente enviar essa mensagem? [y/n]:", poderia prover uma grande quantidade de informao. Nesse caso, poderia ser utilizada a fim de se identificar um desvio no cdigo baseado em uma deciso de usurio. Dessa forma seria possvel mapear qual o trecho de cdigo responsvel por realizar o envio da mensagem. Para isso, basta verificar o cdigo Assembly subsequente rotina que exibe esta mensagem para o usurio. 2.5.1.5.Monitoramento de Rede A atividade de rede tambm um ponto importante de ser observado quando se trata da avaliao de um aplicativo. Um software indevidamente construdo, ou mal intencionado, pode vazar informaes sensveis para mquinas e dispositivos remotos. Em [Filiol, 2011], mostrou-se que, mesmo num trfego protegido pelo protocolo IPSec (IP Security), possvel enviar mensagens e informaes sensveis por meio do tamanho dos pacotes de controle ICMP, por exemplo, de maneira praticamente imperceptvel. Por esse motivo, importante analisar o trfego de rede a fim de verificar se todo o trfego legtimo, ou se existe alguma atividade suspeita. fato que as aplicaes trafegam dados sem o consentimento do usurio, e com a utilizao das bibliotecas de advertising, tais aplicaes passam a trafegar dados sem o consentimento do prprio desenvolvedor. Isso porque tais bibliotecas inserirem cdigo na aplicao que permite que propagandas sejam carregadas de hosts diversos e que informaes de identificao e de localizao sejam passadas para tais hosts. Considerando-se esse fator, a necessidade de monitoramento do trfego de rede de uma aplicao para fins de avaliao de segurana passa a ser indispensvel, visto que a maioria dos aplicativos utilizam bibliotecas de propaganda. Ferramentas de destaque para auxiliar nesse processo so: Lsof, Netstat e Wireshark. Contudo, existem outras de renome que tambm podem ser consideradas. 2.5.1.6.Monitoramento de Processos e Threads Este tipo de monitoramento de fundamental importncia no processo de engenharia reversa. Parte das outras tcnicas de monitoramento podero apontar operaes e associ-las a processos especficos, porm, o analista no deve se restringir somente ao processo sendo analisado. Isso decorre do fato de que este processo pode iniciar outros
89
processos para a realizao de suas atividades. Se isso ocorrer sem que o analista se d conta, a anlise ficar comprometida. O mesmo pode acontecer durante a depurao de um programa. Acompanhando o fluxo de execuo de um programa, pode ser que certo ponto que se deseja analisar nunca seja alcanado, entretanto, uma anlise mais minuciosa poderia concluir que este ponto est sendo executado por uma thread deste mesmo programa ou, ainda, por uma bifurcao do processo em questo. 2.5.1.7.Monitoramento de Memria Mediante o monitoramento da memria do programa possvel identificar informaes sensveis armazenadas. Deve-se assegurar que chaves criptogrficas esto sendo descartadas da memria to logo no sejam mais necessrias. O mesmo vlido para outras informaes como credenciais e informaes pessoais, por exemplo. Para esse fim, pode-se utilizar a ferramenta HPROF, que permite a extrao de dumps de memria dos aplicativos, de modo que se possa analis-los com o Eclipse Memory Analyzer. 2.5.1.8.Interceptao de Chamadas de Sistema e de API O mecanismo de IPC do Android o ncleo da API do sistema. Pelo fato de trafegarem dados entre diferentes componentes, inclusive entre diferentes aplicaes, os Intents so grandes vetores de ataque nesta plataforma. Portanto, uma avaliao dessas chamadas inter-processo se faz necessria. Uma ferramenta interessante a ser utilizada o Intent Sniffer, que permite interceptar os broadcasts de Intents enviados no sistema de modo que se possa analislos minuciosamente, visando levantar comportamentos anmalos, inseguros ou vazamento de informaes sensveis. Ferramentas como o Procrank e PS so de grande importncia para levantar os identificadores de processo dos aplicativos a serem analisados, com o objetivo de os utilizar em ferramentas como o Strace, por exemplo. Outras ferramentas como o DroidBox e DDMS tambm so teis nesse sentido. 2.5.2. Testes de Invaso Normalmente, aplicativos mveis se comunicam com web-services ou com outros servios na internet para prover certas funcionalidades, tornando necessrio a avaliao dos mesmos. Essa avaliao semelhante aos tradicionais testes de invaso de aplicaes web e de aplicaes cliente-servidor, em que so empregadas ferramentas tais como proxies de interceptao, sniffers de rede; fuzzers, etc. Existem vrias opes para auxiliar o processo, tais como: Nmap, Burp Suite, Metasploit Framework, BeEF, SQLMap, Wireshark, entre outras. O diferencial dos testes de invaso em aplicao mvel, quando h interao com servios disponilizados na internet, que se faz necessrio interceptar o trfego gerado pelo dispositivo. Isso pelo fato de que realiz-los a partir da tela do celular no algo vivel. Para interceptar o trfego do dispositivo diversas tcnicas podem ser empregadas.
90
Devido s protees existentes na rede GSM (Global System for Mobile Communications), geralmente, ao analisar um aplicativo que necessite de acesso internet, habilita-se uma rede Wi-Fi para que o dispositivo a utilize para tal. Em tratando de uma rede desse tipo, so utilizadas tcnicas comumente empregadas em testes de invaso de redes. Por exemplo, a ferramenta Cain permite a realizao de ARP (Address Resolution Protocol) spoofing a fim de envenenar a tabela ARP do dispositvo possibilitando um ataque de mitm (Man in the Middle). Uma ferramenta semelhante o Ettercap. Outra alternativa a utilizao da ferramenta Arpspoof, que faz parte da sute Dsniff, a fim de envenear a tabela ARP. Em seguida habilita-se o encaminhamento de pacotes do kernel (ip_forward) e adicionam-se regras ao IPtables para redirecionar o trfego advindo do dispostivo para um proxy de interceptao como o Burp Suite. Alm de ataques de ARP spoofing, outras tcnicas podem ser utilizadas para esse mesmo fim, tal como redirecionamento ICMP ou a definio de um rogue Wi-Fi. Existe tambm a opo de definir o proxy manualmente por meio das configuraes do sistema. Existe tambm a opo de se utilizar o emulador fornecido pelo SDK do Android, ao invs de um dispositivo fsico. Neste caso, basta se obter o APK que foi instalado no dispositivo e execut-lo no ambiente emulado. Via emulador existe a possibilidade de especificar um proxy em tempo de inicializao como seguinte comando: ./emulator -avd <imagem-virtual> -http-proxy localhost:8080, neste caso, considerando que um proxy de interceptao est em execuo esperando conexes na porta. Visto que essa estratgia restringe-se a trfego HTTP, existe a possibilidade de utilizar a ferramenta Tsock que permite o encapsulamento de todo o trfego para um proxy SOCK. possvel ainda definir um servidor de DNS para ser utilizado pelo emulador. O principal fator do qual depende essas tcnicas o modelo utilizado para o transporte de dados via rede. Caso a aplicao esteja utilizando SSL/TLS ser necessrio que o proxy de interceptao apresente o seu certificado para a aplicao, nesse caso, existem duas possibilidades: 1. O aplicativo pode estar se utilizando do chamado trust store mantido pelo sistema, que nada mais do que um local de armazenamento dos certificados confiveis. 2. O aplicativo pode estar se utilizando da tcnica de certificate pinning, que permite empacotar o certificado dentro do prprio aplicativo por meio de um keystore. No primeiro caso, a partir da verso 4.0, uma tela ser apresentada para o usurio permitindo-o aceitar ou no tal certificado como confivel. Caso o usurio o aceite, este certificado ser adicionado ao trust store. Pode-se ainda adicionar manualmente o certificado por meio da ferramenta Keytool. J no segundo caso, isso no ser possvel e o estabelecimento do canal seguro no ocorrer. Em [Osborne e Diquet 2012] so citadas algumas estratgias para que seja possvel contornar esse controle, alm de ser apresentada uma ferramenta para este fim. Uma das estratgias que se pode ser empregada a engenharia reversa do aplicativo, seguida da alterao
91
do certificado e do reempacotamento do aplicativo com a gerao de uma nova assinatura para fins exclusivos de avaliao de segurana. Um considerao que deve ser feita que muitas aplicaes s estabelecem o canal seguro para o transporte de credenciais. Neste caso, to logo a autenticao seja realizada, um canal inseguro volta a ser utilizado em que o token de sesso do usurio tranportado. Existem ferramentas que permite a obteno de tais tokens e o sequestro de sesses, como o DroidSheep, por exemplo. Essa deciso de no utilizar um canal seguro de comunicao ou de utilizar-se deste artifcio apenas para o transporte de credenciais tomada, muitas vezes, por falta de conhecimento dos aspectos de segurana envolvidos com os mecanismos de gerenciamento de sesso, ou a fim de no sobrecarregar o servidor com processamento adicional. Tal deciso pode ser tomada tambm com o objetivo de se economizar a bateria do dispositivo, visto que operaes criptogrficas resultam em um consumo maior de energia. Um aspecto interessante que merece destaque o fato da verso mvel de alguns web sites se comportarem de maneira insegura, como exemplo cita-se o caso do Facebook, em que o usurio explicitamente entra na verso HTTPS do site, por meio de https://www.facebook.com e automaticamente redirecionado para http://m.face book.com/. O problema de redirecionamento para sites mveis inseguros muito comum atualmente. Desenvolvedores verificam por qual tipo de navegador o usurio est acessando o site e, caso seja mvel, redireciona sempre para o mesmo site com protocolo inseguro. Seria necessrio tambm uma verificao se o usurio est tentando o acesso ao protocolo com segurana ativada. Ainda em relao a acesso web via navegadores, destaca-se o fato de que alguns sites, como o do Gmail, redirecionam o usurio para a verso HTTPS caso o usurio acesse a verso HTTP. Isso feito atravs de um redirecionamento HTTP 302. Um programa como o Sslstrip permite interceptar esse redirecionamento e apresentar o contedo via HTTP para a vtima. Isso possvel pois a ferramenta acessa a verso HTTPS e fica intermediando as duas pontas, possibilitando assim o roubo de credenciais de acesso da vtima. A nica forma de mitigar esta tcnica educando o usurio a sempre requisitar diretamente no navegador a verso segura do site sendo acessado. Aps obter o acesso ao trfego por meio de um proxy de intercepo, possvel testar os pontos de entrada da aplicao servidora, manipular parmetros, desativar controles aplicados no lado do cliente, entre outros. Vale ressaltar tambm que possvel alterar as respostas enviadas pelo servidor, visando alterar o comportamento do aplicativo mvel. Recomenda-se realizar ainda todos os tipos de testes pertinentes a aplicaes web, visando identificar vulnerabilidades que normalmente afetam tais tipos de sistemas, tais como: injeo de SQL, XSS (Cross-site Scripting), CSRF (Cross-site Request Forgery), fixao de sesso, CSI (Client Side Injection), dentre outras, descritas pela equipe do OWASP [OWASP, 2012]. Um guia interessante para a realizao desses testes o OWASP Testing Guide [OWASP, 2008].
92
Vale ressaltar que muitas aplicaes web alteram seu comportamento de acordo com o navegador com o qual esto interagindo, e o mesmo vlido para navegadores de dispositivos mveis. Ento ao testar tais aplicaes de um desktop, deve-se personificar esses navegadores. Um ponto interessante quando se trata de navegao web via dispositivos mveis que os usurios normalmente no realizam o logout na aplicaes que utilizam [Dwivedi, Clark e Thiel 2010], o que aumenta a janela de explorao de vulnerabilidades de CSRF. Reforando o problema, est o fato de links poderem ser facilmente mascarados aproveitando-se do tamanho de tela restrito e da dificuldade de se visualizar o endereo real para o qual o mesmo aponta (visto que pode no ser o que est sendo apresentado). Outra tcnica que pode ser utilizada o fuzzing, que consiste no fornecimento de dados invlidos, no esperados ou aleatrios para um ponto de entrada, com a finalidade de analisar o comportamento do programa. Os dados que deve-se conferir mais ateno so os que cruzam os limites de confiana do sistema. Uma ferramenta que pode ser utilizada com esse propsito o Intent Fuzzer, que possibilita o envio de Intents esprios para os componentes do sistema, visando alcanar trechos do programa potencialmente vulnerveis que podem resultar na quebra do mesmo. Ainda nessa linha, ferramentas como Peach, Sulley e Hachoir podem ser utilizadas.
2.6.
Recomendaes de Segurana
Tomando por base as sees anteriores, esta seo oferece recomendaes gerais de segurana contra as ameaas aos dispositivos mveis, em particular, aquela considerada por muitos pesquisadores a ameaa mais devastadora aos dispositivos mveis modernos, a saber: os softwares maliciosos. No entanto, a ameaa de maior probabilidade de ocorrncia o extravio do dispositivo, a qual possui um grande risco quando em conjunto com a injeo de cdigo malicioso. Para se proteger de possveis ataques, algumas medidas devem ser tomadas pelo dono do dispositivo, a fim de se obter um maior nvel de segurana. Em especial, devese conhecer os riscos de se habilitar permisses administrativas. 2.6.1. Medidas de Segurana Inicialmente, necessrio um bom gerenciamento das configuraes que o dispositivo possui. Existem vrias opes que so ativadas por padro no dispositivo (ou que so ativadas pelo usurio, mas depois no so desativadas). Algumas delas, enquanto no esto sendo utilizadas, ou quando foram mal definidas pelo usurio, podem servir de entrada para possveis exploraes de vulnerabilidades a partir de aplicativos maliciosos. So descritas abaixo uma srie de configuraes que devem ser utilizadas com cautela, a fim de se prevenir possveis pontos de entrada para ataques. Opes do desenvolvedor: Nesta seo do dispositivo existem vrias configuraes, as quais foram disponibilizadas para auxiliar o desenvolvimento de aplicativos para o mesmo. O ideal seria ativar somente as opes que se deseje utilizar, e desativ-las aps o uso. O principal exemplo de possvel problema o Modo Debug (Subseo 2.2.4), o qual permite que, atravs de
93
uma conexo USB, seja possvel a execuo de ferramentas de desenvolvedor, as quais poderiam ser facilmente utilizadas para um ataque. Vale ressaltar que a seo Opes do desenvolvedor foi criada na verso 4.0 do Android, mas j existia um equivalente nas verses anteriores, o Modo Debug, o qual deve ser utilizado com o mesmo cuidado. Fontes desconhecidas: A instalao de aplicativos provenientes de lojas de terceiros, ou seja, as lojas existentes alm da Play Store, da Google, abre um grande vetor de entrada para aplicativos maliciosos no dispositivo. Um atacante pode modificar um aplicativo seguro, transformando-o em um malware, e no haver uma entidade para verificar questes pertinentes em relao segurana. Logo, o mesmo poder ser baixado e executado pelo usurio, ativando suas funes maliciosas. importante notar que nem toda loja de terceiros ilegal ou insegura, como exemplo cita-se a loja da Amazon e a da Samsung. Bloqueio de tela: Existem quatro modos de bloqueio de tela em um dispositivo Android (Subseo 2.2.5). O recomendado que se utilize o controle por senha de no mnimo 8 caracteres, incluindo alfabticos maisculos e minsculos, caracteres numricos e smbolos, dificultando assim, ataques de fora bruta. Alm disso, no aconselhvel o uso de palavras comuns ou de dados pessoais, para que a senha no seja quebrada atravs de um ataque de dicionrio. Encriptao de disco: Nos dispositivos em que existir essa opo, o ideal ativ-la para manter os dados seguros mesmo contra roubo e extravio do dispositivo mvel. importante definir uma senha forte para a proteo desses dados, caso contrrio um atacante poder facilmente obt-los por meio de um ataque de fora bruta. Bluetooth: Uma opo que normalmente ativada e esquecida. Deixar o bluetooth ativado abre mais uma porta para possveis ataques. A recomendao que se ative apenas pelo tempo necessrio para a realizao da atividade pretendida. Formatao Remota: Comumente conhecida como remote wipe. Nos dispositivos em que a opo estiver disponvel, essa uma boa precauo a se utilizar. Atravs dela, caso o dispositivo seja perdido, seja por roubo ou por extravio, ser possvel apagar seus dados remotamente, protegendo-se assim do roubo de informaes. GPS: Deixar o GPS desligado por padro, e tomar cuidado com opes de aplicativos permitindo que seja monitorada a sua localizao. J houveram estudos provando que possvel se prever onde um usurio estar de acordo com o perfil criado da anlise de vrias localizaes disponveis pelo seu dispositivo [Malm e Osborn 2012].
Alm dos cuidados explicados anteriormente, vale ressaltar que outras precaues devem ser tomadas, afim de se diminuir os riscos de segurana no aparelho: Conexo com a internet: Sempre verifique se sua conexo com a internet confivel antes de utiliz-la para a transmisso de dados sensveis, como uma transao financeira, por exemplo. Apesar de ser possvel a criao de uma rede de celular maliciosa, muito mais fcil comprometer uma rede Wi-Fi. Por isso,
94
na dvida, priorize o uso da internet via canal de dados atravs da operadora, principalmente para a transmisso de dados sigilosos. Navegao: Vrios cuidados devem ser tomados enquanto se navega pela internet utilizando um dispositivo mvel: o Ao acessar um website sempre especificar o protocolo HTTPS no URL (por exemplo: https://www.gmail.com), forando com que, caso seja possvel, uma conexo segura seja estabelecida com o servidor. o No aceitar certificados digitais sem antes analis-los. O uso de um certificado malicioso pode ser uma porta de entrada para futuros ataques. Levar em considerao que, uma vez aceito um certificado, o mesmo ficar armazenado na trust store e, caso se deseje, dever ser removido manualmente. o Ler todo o endereo antes de digitar informaes em uma pgina. Principalmente em smartphones, que possuem uma tela pequena, um site malicioso poderia se aproveitar disso criando uma pgina com o endereo www.banco.com.br.sitemalicioso.com, mas na tela s iria aparecer www.banco.com.br, e o usurio iria pensar que est acessando o site legtimo. o Tentar no utilizar o navegador padro disponvel no aparelho [Hoog 2011]. Como ele considerado o mais utilizado, considerado tambm o mais estudado e explorado por atacantes. Permisses: muito comum no se ler quais as permisses que um aplicativo solicita ao instal-lo. necessrio ter um olho bem crtico em relao a essas permisses, pois elas indicam possveis vetores de ataque que sero postos em prtica pelo aplicativo. Por exemplo, no caso de jogo que pea permisso para gerenciar suas mensagens de texto, nada garante que ele no ir ler e enviar mensagens sigilosas que foram armazenadas. claro que, como toda regra, h excees. Neste caso, o jogo poderia utilizar a permisso para fazer propaganda para os contatos da agenda. Sistema de reputao: Um modo simples de se obter informaes de um software atravs do sistema de reputao existente na maioria das lojas de aplicativos. A partir dos comentrios e notas dados por usurios que j instalaram o referido aplicativo, possvel ter uma noo da confiabilidade do mesmo. Atualizao da plataforma: Sempre que possvel, mantenha o dispositivo atualizado com a verso mais recente disponvel do sistema operacional, pois todas as vulnerabilidades encontradas s sero resolvidas atravs dessas atualizaes. Uso do carto SD: Um fator importante de um dispositivo Android o uso do carto SD para armazenamento de dados. Como o carto uma memria externa ao dispositivo, ela no possui um gerenciamento de privilgios. Com isso, qualquer dado armazenado no mesmo pode ser visto por qualquer aplicativo instalado no aparelho.
95
Antivrus e firewall: Principalmente para quem instala aplicativos de fora da loja oficial da Google, ou para quem se conecta em vrias redes diferentes, possvel a utilizao de um aplicativo antivrus e/ou de firewall como uma medida adicional de segurana. SMS e MMS: Apesar do texto das mensagens de texto e multimdia serem encriptados, a confidencialidade no assegurada fim-a-fim. Isso quer dizer que, toda informao que enviada pode ser lida pela operadora. Por isso, deve-se tomar cuidado ao enviar informaes sigilosas via este tipo de mensagem.
Conclui-se que, com um bom conhecimento das funcionalidades existentes em um dispositivo mvel, conforme visto anteriormente, possvel um melhor gerenciamento do mesmo, afim de se diminuir os riscos de segurana no aparelho. 2.6.2. Riscos Associados ao Rooting do Dispositivo Um grande risco existente a habilitao de permisses de acesso administrativo no dispositivo, em outras palavras, o rooting. Alguns usurios utilizam vulnerabilidades para alcanar tais permisses, e assim conseguirem executar comandos especficos no sistema (como uma modificao na aparncia do sistema operacional, por exemplo). O acesso privilegiado ao sistema traz consigo diversos riscos, principalmente no que se diz respeito segurana do mesmo. No h um modo efetivo de se limitar o acesso das aplicaes a tais permisses, por isso, um aplicativo malicioso poderia se beneficiar dessas permisses e obter vrias informaes que deveriam estar fora de seu alcance, como a base de dados de outro aplicativo, por exemplo. Na maioria dos dispositivos possvel, aps o rooting, desabilitar o acesso administrativo ao sistema. Tal tcnica foi popularmente nomeada unrooting. Para usurios que precisam ou desejam executar uma nica funo que necessita de permisses privilegiadas, esta uma boa opo para ser utilizada ao trmino da ao de interesse. Resumindo, a recomendao que no se deve habilitar o acesso de root em dispositivos com Android. Se, apesar disso, ainda exista a necessidade de ativ-lo, a recomendao que tal acesso seja desativado to logo no seja mais necessrio.
2.7.
Consideraes Finais
Este minicurso busca atender a uma demanda recentemente identificada por profissionais e acadmicos em relao ao tratamento multidisciplinar das vulnerabilidades relacionadas s plataformas modernas de dispositivos mveis, as quais agregam diversas reas de conhecimento, tais como segurana da informao, redes de comunicao sem fio e desenvolvimento de aplicativos mveis. Com o grande aumento do uso de dispositivos mveis, h a tendncia de que atacantes deem mais ateno a estes dispositivos, sendo necessrio um estudo aprofundado das vulnerabilidades na plataforma e em aplicativos a fim de que se possam aplicar controles de segurana mais eficazes com o intuito de reduzir a probabilidade de concretizao das ameaas pertinentes aos dispositivos mveis. Alm disso, as pessoas esto acessando tanto redes pessoais quanto corporativas com seus prprios dispositivos, o que est demandando esforos por parte das empresas para
96
atender tal demanda, reduzindo os possveis impactos da utilizao destes dispositivos no ambiente. Um outro fato notvel que a aplicao de controles de segurana no ncleo do sistema, que tm como finalidade dificultar a explorao e reduzir o impacto provocado pela explorao de uma vulnerabilidade de corrupo de memria em uma aplicao, aliada ao confinamento de aplicaes, vem fazendo com que os criminosos digitais se dediquem muito mais ao desenvolvimento de aplicativos com funcionalidades maliciosas e em meios de fazer com que o usurio os instale conscientemente [Dwivedi et al. 2010]. O crescimento do nmero de aplicaes financeiras envolvendo dispositivos mveis como, por exemplo, internet banking, m-payments e mobile point-of-sale (POS), refora a tendncia do elevado crescimento no nmero de ataques a estes dispositivos, dada a prevalncia de ataques no Brasil a aplicaes de internet banking e pagamentos on-line nos computadores de mesa.
2.8.
Referncias
Android Developers Project. (2012a). Android Debugging Tools. Disponvel em: <http://developer.android.com/tools/debugging/index.html>. Acessado em: 05 de Setembro de 2012. Android Developers Project. (2012b). DDMS - Dalvik Debug Monitor Server. Disponvel em: <http://developer.android.com/tools/debugging/ddms.html>. Acessado em: 05 de Setembro de 2012. Android Developers Project. (2012c). Platforms Versions. Disponvel em: <http://developer.android.com/about/dashboards/index.html>. Acessado em: 10 de Setembro de 2012. Android Developers Project. (2012d). Proguard. Disponvel em: <http://developer.android.com/tools/help/proguard.html>. Acessado em: 06 de Setembro de 2012. Android Developers Project. (2012e). Profiling with Traceview and dmtracedump. Disponvel em: <http://developer.android.com/tools/debugging/debuggingtracing.html>. Acessado em: 05 de Setembro de 2012. Android Open Source Project. (2012a). Android Security Overview. Android Open Source Project. Disponvel em <http://source.android.com/tech/security/index.html>. Acessado em: 12 de Setembro de 2012. Android Open Source Project. (2012b). Dalvik Technical Information. Disponvel em: <http://source.android.com/tech/dalvik/index.html>. Acessado em: 11 de Setembro de 2012. Android Open Source Project. (2012c). Notes on the implementation of encryption in Android 3.0. Disponvel em: <http://source.android.com/tech/encryption/android_crypto_implementation.html>. Acessado em: 12 de Setembro de 2012.
97
Apvrille, A. (2011). An OpenBTS GSM Replication Jail for Mobile Malware. Acessado em: <http://www.virusbtn.com/conference/vb2011/abstracts/Apvrille.xml>. Disponvel em: 10 de Setembro de 2012. Apvrille, A. (2012a). Android Reverse Engineering Tools - From an anti-virus analysts perspective. In InsomniHack12. Apvrille, A. (2012b). Controlling Android / Zitmo by SMS commands. Disponvel em: <http://blog.fortiguard.com/controlling-android-zitmo-by-sms-commands/>. Acessado em: 10 de Setembro de 2012. Aviv, A. J.; Gibson, K.; Mossop, E.; Blaze, M.; Smith, J. M. (2010). Smudge Attacks on Smartphone Touch Screens. 4th USENIX Workshop on Offensive Technologies. Bansal, V.; Henein, N.; Hogben, G.; Nohl, K.; Mannino, J.; Papathanasiou, C.; Rueping, S.; Woods, B. (2011). Smartphone Secure Development Guidelines for App Developers. European Network and Information Security Agency (ENISA). Disponvel em: <http://www.enisa.europa.eu/activities/Resilience-and-CIIP/criticalapplications/smartphone-security-1/smartphone-secure-development-guidelines>. Acessado em: 01 de Setembro de 2012. Bjrnheden, M. (2009). The Android boot process from power on. Disponvel em: <http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html>. Acessado em: 12 de Setembro de 2012. Bojinov, H., Boneh, D., Rich, C., Malchev, I. (2011). Address Space Randomization for Mobile Devices. Proceedings of the fourth ACM conference on Wireless network security. 127-138p. Bornstein, D. (2008). Dalvik VM Internals. Google I/O 2008. Callaham, J. (2011). Galaxy nexus android 4.0 face unlock broken by picture. Disponvel em: http://www.neowin.net/news/galaxy-nexus-android-40-faceunlockbroken-by-picture. Acessado em: 4 de Setembro de 2012. Cannon, T. (2012). Into The Droid: Gaining Access to Android User Data. DefCon 20. Chen, G., Kotz, D. (2000). A survey of context-aware mobile computing research. Dept. of Computer Science, Dartmouth College, Relatrio Tcnico TR2000-381. Dwivedi, H., Clark, C., Thiel, D. (2010). Mobile Application Security. McGraw-Hill Companies. 432p. Enck, W., Octeau, D., McDaniel, Patrick and Chaudhuri, S. (2011). A Study of Android Application Security. Proceedings of the 20th USENIX Security Symposium. Felt, A. P., Finifter, M., Chin, E., Hanna, S. and Wagner, D. (2011). A survey of mobile malware in the wild. Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices. ACM. Filiol, E. (2011). Dynamic Cryptographic Backdoors. CanSecWest 2011, Vancouver, Canada. Heyman, A. (2011). First SpyEye Attack on Android Mobile Platform now on the Wild. Disponvel em: <http://www.trusteer.com/blog/first-spyeye-attack-androidmobile-platform-now-wild>. Acessado em: 5 de Setembro de 2012.
98
Hoog, A. (2011). Android Forensics: Investigation, Analysis and Mobile Security for Google Android. Editora Elsevier. 432p. Hopper, A. (2000). Sentient Computing. Philosophical Transactions of the Royal Society of London, v. 358. Huang, J. (2012). Understanding the Dalvik Virtual Machine. Google Technology User Groups, Taipei 2012. Disponvel em: <http://0xlab.org/~jserv/tmp/dalvik.pdf>. Acessado em: 11 de Setembro de 2012. Jakev (2012a). Debugging Android Apps with Native Code - Part 1. Disponvel em: <http://thecobraden.blogspot.com.br/2012/02/debugging-apps-with-native-code-part1_09.html>. Acessado em: 10 de Setembro de 2012. Jakev (2012b). Debugging Android Apps with Native Code - Part 2. Disponvel em: <http://thecobraden.blogspot.com.br/2012/02/debugging-apps-with-native-code-part2.html>. Acessado em: 10 de Setembro de 2012. Kang, S., Lee, J., Jang, H., et al. (2008). SeeMon: scalable and energy-efficient context monitoring framework for sensor-rich mobile environments. Proceedings of the 6th international conference on Mobile systems, applications, and services. ACM. Kephart, J. O. and Chess, D. M. (2003). The vision of autonomic computing. Computer, IEEE, v. 36, n. 1, p. 4150. Lafortune, E. (2012). Proguard. Disponvel em: <http://proguard.sourceforge.net/>. Acessado em: 06 de Setembro de 2012. Li, Y. (2012). Android.Notcompatible. Disponvel em: <http://www.symantec.com/security_response/writeup.jsp?docid=2012-050307-271299>. Acessado em: 20 de Agosto de 2012. Lineberry, A., Richardson, D. L., Wyatt, T. (2010). These Aren't The Permissions You're Looking For. DefCon 18, 2010. Malm, S.; Osborne, L. (2012) Mobile phone companies can predict future movements of users by building a profile of their lifestyle. Disponvel em: <http://www.dailymail.co.uk/sciencetech/article-2190531/Mobile-phone-companiespredict-future-movements-users-building-profile-lifestyle.html>. Acessado em: 10 de Setembro de 2012. Maslennikov, D. (2011). Zeus-in-the-Mobile - Facts and Theories. Disponvel em: <http://www.securelist.com/en/analysis/204792194/ZeuS_in_the_Mobile_Facts_and_T heories>. Acessado em: 05 de de Setembro de 2012. Matenaar, F., Schulz, P. (2012). BtDetect - Detecting Android Sandboxes. Disponvel em: <http://www.dexlabs.org/blog/btdetect>. Acessado em: 10 de Setembro de 2012. Mullaney, C. (2012). Android.Bmaster: A Million-Dollar Mobile Botnet. Disponvel em: <http://www.symantec.com/connect/blogs/androidbmaster-million-dollar-mobilebotnet>. Acessado em: 31 de Agosto de 2012. Oberheide, J., Jahanian, F. (2010). When mobile is harder than fixed (and vice versa): demystifying security challenges in mobile environments. Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications. Oberheide, J., Miller, C. (2012). Dissecting Google Bouncer. SummerCon 2012.
99
Osborne, J., Diquet, A. (2012). When Security Gets in the Way: PenTesting Mobile Apps That Use Certificate Pinning. Black Hat USA 2012. OWASP. (2012). Category:Attack. Disponvel em <https://www.owasp.org/index.php/Category:Attack>. Acessado em: 16 de Setembro de 2012. OWASP. (2011). OWASP Mobile Security Project: Top 10 Mobile Risks. Disponvel em: <https://www.owasp.org/index.php/OWASP_Mo bile_Security_Project#tab=Top_Ten_Mobile_Risks>. Acessado em: 06 de Setembro de 2012. OWASP. (2008). OWASP Testing Guide. OWASP EU Summit 2008. Percoco, N. J., Schulte, S. (2012). Adventures in BouncerLand: Failures of Automated Malware Detection within Mobile Application Markets. Black Hat USA 2012. Pinto, A. S., Pedrini, H., Schwartz, W. R., Rocha, A. (2012). "Video-Based Face Spoofing Detection through Visual Rhythm Analysis". XXV SIBGRAPI, Conference on Graphics, Patterns and Images. Reddy, S., Burke, J., Estrin, D., Hansen, M. and Srivastava, M. (2008). Determining transportation mode on mobile phones. Wearable Computers, 2008. ISWC 2008. 12th IEEE International Symposium on. Ridley, S., Lawler, S. (2012). Advanced ARM Exploitation. Black Hat USA 2012. Satyanarayanan, M. (2001). Pervasive computing: Vision and challenges. Personal Communications, IEEE, v. 8, n. 4, p. 1017. Satyanarayanan, M. (2010). Mobile computing: the next decade. In Proceedings of the 1st ACM Workshop on Mobile Cloud Computing & Services: Social Networks and Beyond. Schwartz, W. R., Rocha, A., Pedrini, H. (2011). Face Spoofing Detection through Partial Least Squares and Low-Level Descriptors. Joint Conference on Biometrics, Outubro de 2011, pp. 18. Serna, F. J. (2012). The Info Leak Era On Software Exploitation. Black Hat USA 2012. Six, J. (2012). Application Security for the Android Platform: Processes, Permissions, and Other Safeguards. Gravenstein Highway North, Sebastopol, CA, EUA: O'Reilly. 100p. Strazzere, T. (2012). Dex Education: Practicing Safe Dex. BlackHat 2012. Vidas, T., Votipka, D., Christin, N. (2011) All Your Droid Are Belong To Us: A Survey of Current Android Attacks. USENIX, WOOT, 2011. Weiser, M. (1991). The computer for the 21 st century. ACM SIGMOBILE mobile computing and communications review, v. 3, n. 3, p. 311. Zhou, Y., Jiang, X. (2012). Dissecting android malware: Characterization and evolution. 2012 IEEE Symposium on Security and Privacy.
100

2012 Sbseg mc2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2012 Sbseg mc2

Hochgeladen von

Copyright:

Verfügbare Formate

Minicursos do XII Simpsio Brasileiro em Segurana da Informao e de Sistemas Computacionais SBSeg 2012

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

Arquitetura de Segurana da Plataforma Android

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

Quadro 2: Especificao no AndroidManifest.xml das permisses requisitadas pela aplicao.

MODE_WORLD_WRITABLE - disponibilizao de acesso de escrita para qualquer aplicao do dispositivo.

Anlise de Artefatos Maliciosos

Figura 2: Transformao de cdigo fonte Java em Dex. Fonte: [Strazzere 2012].

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

c 2012 SBC Soc. Bras. de Computao

Das könnte Ihnen auch gefallen