Minicursos SBSeg 2012

5/20/2018 Minicursos SBSeg 2012

1/204


2/204


3/204

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

ii


4/204


iii


5/204


iv


6/204


v


7/204


vi


8/204


vii


9/204


10/204


2 c2012 SBC Soc. Bras. de Computao


11/204




12/204




13/204




14/204




15/204




16/204




17/204




18/204




19/204




20/204




21/204




22/204




23/204




24/204




25/204




26/204




27/204




28/204




29/204




30/204




31/204




32/204




33/204




34/204




35/204




36/204




37/204




38/204




39/204




40/204




41/204




42/204




43/204




44/204




45/204




46/204




47/204




48/204




49/204




50/204




51/204




52/204




53/204




54/204




55/204




56/204




57/204




58/204




59/204




60/204

Captulo

2Introduo Segurana de Dispositivos Mveis

Modernos Um Estudo de Caso em Android

Alexandre Melo Braga, Erick Nogueira do Nascimento, Lucas Rodriguesda 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 theseissues, 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 detais 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 osaspectos 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 protagonistasda atual onda de mudana no mundo das TICs (Tecnologias da Informao e daComunicao) de uso pessoal e profissional. Esta mudana caracterizada pelo uso dedispositivos com grande poder de processamento e conectividade em ambientes

pblicos e privados.




61/204

O aumento do poder de computao, a grande conectividade e o grande aumentorecente da variedade de servios e aplicativos disponveis nos dispositivos mveis pemossmartphonese os tabletsem evidncia como alvos de ataques de risco elevado. Em

vista disto, a segurana da informao, outrora centralizada e com permetro bemdefinido, tende a se tornar descentralizada e individualizada. Este minicurso aborda osaspectos de segurana relacionados aos dispositivos mveis de acordo com trs aspectosinter-relacionados.

O primeiro a constatao no segundo semestre de 2011 que os dispositivosmveis representaro a prxima fronteira de proliferao de software malicioso. Estefato foi evidenciado pelo grande aumento no ltimo quarto de 2011 da quantidade deartefatos maliciosos voltados plataforma Android, da Google, o qual foi motivado em

parte pelo aumento da fatia de mercado desta plataforma em relao s outrasplataformas 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 osegmento corporativo, ao contrrio do que ocorreu, por exemplo, com tecnologias comoos computadores de grande porte e os aparelhos de fax. Deste modo, indivduos quetrocam frequentemente seus dispositivos, passam a utiliz-los de modo intenso noapenas em atividades pessoais, mas tambm profissionalmente, em um fenmenocomportamental conhecido como BYOD (Bring Your Own Device). Com estecomportamento, estes indivduos influenciam as organizaes a que pertencem e que

por sua vez so levadas adaptao forada s novas tecnologias e ao tratamento dasegurana dos dispositivos mveis de forma descentralizada, pois se perde o controle deativos inseridos no ambiente de rede e a noo de permetro de segurana.

O terceiro aspecto um desdobramento dos anteriores, em que em um ambientede TIC, caracterizado pelos fenmenos da consumerizao e do BYOD, muitos doscontroles de segurana tradicionais, comumente aplicados sobre desktops e outrosativos da infraestrutura, tornam-se ineficazes.

Um exemplo da situao descrita acima o caso de software malicioso voltadopara plataformas mveis. Uma vez que sua proliferao no se d por transfernciasdiretas entre dispositivos, como normalmente ocorria nos computadores portteis e demesa, mas usualmente por meio das lojas de aplicativos ou de sites de terceiros

potencialmente no confiveis. Por exemplo, ao permitir que um tablet pessoal sejainfectado 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 dispositivoscontrolados remotamente por um atacante) de smartphones para realizao de ataquesmacios sincronizados e outras fraudes coordenadas, incluindo ataques potenciais redede telecomunicaes.

2.1.1. Evoluo dos Ambientes Mveis

Esta subseo oferece uma viso panormica sobre a evoluo tecnolgica dosambientes mveis. Os pargrafos a seguir fazem uma reviso bibliogrfica breve dosconceitos e vises que levaram ao contexto atual de ambientes mveis.




62/204

O sonho da informao na ponta dos dedos em qualquer lugar e a qualquermomento" e a viso ldica e at certo ponto ficcional de dcadas passadas foramcapazes de antecipar muitos dos desafios que se apresentam hoje aos dispositivos

mveis. As plataformas mveis de hoje so resultado de diversas inovaes conceituaise de modelos de computao vislumbrados no final do sculo passado e cujas primeirasimplementaes remontam ao final do milnio passado.

Dentre as inovaes mais importantes podem ser citadas as seguintes: acomputao pervasiva, a computao autonmica, a computao senciente e sensvel aocontexto, as redes de comunicao sem fio de curto alcance, a eficincia energtica e osoftware adaptvel.

Neste momento, fazem-se necessrios conceitos relevantes. Computaopervasiva ou computao ubqua um termo que foi publicado pela primeira vez em1991 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 ainterao pessoa-mquina invisvel (ou imperceptvel), ou seja, integrar a informticacom as aes e comportamentos naturais das pessoas.

Computao autonmica uma rea da computao cujo objetivo odesenvolvimento de sistemas computacionais capazes de autogerenciamento e deadaptao a mudanas imprevisveis, permitindo a expanso de sistemascomputacionais complexos e uma melhor utilizao dos recursos computacionais. Umsistema autnomo toma decises utilizando instrues de alto nvel, que iro verificarconstantemente os procedimentos realizados e aperfeioa-los, adaptando-se s novascondies.

A computao senciente se refere possibilidade de interconexo decomputadores e objetos atravs de sensores que passam a se reconhecer de maneiraautnoma e a trocar informaes.

Segundo Satyanarayanan [Satyanarayanan 2010], o e-mail e o acesso webonipresentes j so realidades para milhes de usurios em todo o mundo atravs deseus dispositivos mveis. Mantendo esta linha de atuao, os servios da web mvel eas oportunidades de publicidade sensvel ao contexto comearam a aparecer comoatividades 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 utilizadosatualmente. Tais dispositivos seriam amplamente utilizados pelas pessoas na realizaodas mais diversas atividades da vida cotidiana e estariam intrinsecamente agregados rotina humana. Alm disto, Weiser [Weiser 1991] tambm pregou que o PC (PersonalComputer) tradicional em formato desktop seria inadequado para integrarverdadeiramente a computao s prticas de trabalho do sculo XXI. Ele argumentouque a presena de um computador bem projetado seria quase imperceptvel, eefetivamente invisvel, ao realizar as tarefas dirias.

Ainda em 2000, surge formalmente o conceito de computao senciente [Hopper2000], 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




63/204

mveis, onde cada indivduo carrega consigo o seu prprio conjunto de computadoresmveis 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 dousurio e segurana (privacidade e confiana).

Em 2003, Kephart e Chase [Kephart e Chase 2003] vislumbraram que o sistemaformado por todos os dispositivos mveis e os aplicativos neles residentes umaestrutura to gigantesca que somente poderia ser entendida como um sistema decomputao autonmica ou autogerenciado. Este sistema seria capaz de integrar novoscomponentes automaticamente em uma grande base sistmica existente e gerenciar asoperaes dirias a partir de objetivos gerais definidos por um administrador impessoal

e distante dos detalhes operacionais. Atualmente, sabe-se que a complexidade dossistemas, que so compostos por dezenas de milhes de linhas de cdigo, cada vezmaior e est sendo amplificada em vrias ordens de magnitude pela tendncia decomputao pervasiva, que tem como uma de suas caractersticas, a autogesto desistemas adaptativos.

Apenas recentemente, aspectos de computao sensvel ao contexto comearama ser integrados aos dispositivos mveis, realizando operaes de monitoramentosensvel ao contexto com base nos mltiplos sensores e aplicativos disponveis nossmartphones [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, andandode bicicleta ou em um transporte motorizado.

O conceito de computao sensvel ao contexto anterior ao ano 2000 [Chen eKotz 2000] e estabelece que um sistema de computao seja capaz de modificar seucomportamento com base em seu contexto local, utilizando localizao geogrfica, horado dia, quem est por perto e estado de movimento. Como resultado, as aplicaessensveis ao contexto podem fornecer uma experincia aprimorada, personalizando oseu comportamento para melhor apoiar as tarefas do usurio. Este tipo de adaptao

particularmente til ao projetar aplicaes mveis que sero colocadas em contextosmutveis. H dois componentes principais necessrios para a criao de sensibilidade aocontexto: em primeiro lugar, a capacidade de capturar uma grande variedade de dadosde 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 equalitativa das cinco principais plataformas modernas de smartphones em relao aostrs modelos atuais de segurana para plataformas mveis:

Entrega segura de aplicaes: refere-se ao nvel de garantia de segurana daaplicao, 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 umaaplicao a ser instalada no dispositivo.




64/204

Nveis de confiana: refere-se granulao do controle de acesso aos recursosdo aparelho e determina os graus de confiana e privilgios a seremimplementados por mecanismos de controle de acesso.

Isolamento de aplicaes e do SO (Sistema Operacional): refere-se capacidadede uma plataforma mvel em isolar ou conter uma aplicao em particular,como uma estratgia de preveno contra o comprometimento de outrasaplicaes, resultando no grau de conteno do dano causado por aplicaescomprometidas sobre outras aplicaes e o resto do sistema.

O artigo sugere que a plataforma Android da Google apresenta o modelo desegurana mais consistente e seguro sendo que o Symbian OS viria em seguida e porfim 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 umaresposta rpida dos fornecedores de produtos de segurana da informao. A falta derespostas no foi motivada pela falta de interesse comercial, mas sim pela ausncia detecnologias 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 artefatosmaliciosos, desenvolvimento de aplicativos e avaliao de segurana. Portanto estaseo discute tais aspectos.

2.2.1. Plataforma Android

O Android uma plataforma open source para dispositivos mveis composta porsistema operacional, middleware, frameworks de aplicao e algumas aplicaesessenciais para provimento das funcionalidades bsicas dos dispositivos. O esforoinicial em sua concepo foi da Google, que, posteriormente, o passou para a OpenHandset Alliance, grupo composto por operadoras, fabricantes de dispositivos e decomponentes 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 dasfunes bsicas do dispositivo. Estas aplicaes vm pr-instaladas e, cita-se comoexemplo: servio de voz, servio de SMS/MMS, email, calendrio, navegador web eagenda. Ademais, os OEMs (Original Equipment Manufacturer) podem inserir seus

prprios aplicativos no dispositivo por motivos diversos. Um exemplo de um aplicativodesse tipo o Samsumg Kies que vem junto ao Galaxy SII. Aplicaes de terceirostambm fazem parte dessa camada, contudo as mesmas devem ser instaladas pelousurio 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 devemser ativadas nas configuraes do aparelho. As aplicaes dessa camada so compostas

por componentes que so responsveis pelo provimento das mais diversasfuncionalidades suportadas pela API do Android. So eles: Activities, BroadcastReceivers, Services e Content Providers.




65/204

J oframeworkde aplicao composto por cdigo compilado para a mquinavirtual Dalvik - que foi desenvolvida para rodar de modo eficiente nas plataformasutilizadas por dispositivos mveis - e prov os mais diversos servios para os

aplicativos desenvolvidos para esta plataforma. Nessa camada encontram-se mduloscomo o provedor de servios de localizao, de gerenciamento de Activities e deContent Providers.

Figura 1: Pilha de software do Android. Fonte: [Android Open Source Project

2012a].

A camada de middlewareimplementa servios que so disponibilizados para oframework de aplicao e para as aplicaes. composta por diversas bibliotecasnativas que so devidamente compiladas para cada dispositivo e provm as maisdiversas funcionalidades, dentre elas: acesso grfico tela, enginede 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 seusrespectivos servios. As aplicaes construdas para executar na mquina virtual Dalviktambm possuem, cada uma, sua prpria instncia da mquina virtual, ou seja, cadaaplicao possui um processo associado quando em execuo, e esse processo nadamais 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 kerneldo Linux, que responsvelpela abstrao do hardware e pelo provimento das interfaces para manipulao destehardware por meio dos drivers de dispositivo. Nessa camada so aplicados algunscontroles de segurana referentes ao confinamento de aplicaes, afora alguns outros

que fazem desta uma das camadas mais importantes no que diz respeito segurana.




66/204

Conforme [Android Open Source Project 2012a], a plataforma Android foiconcebida 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 nesteprocesso. Isso alcanado por meio do confinamento de aplicaes, pelo esquema depermisses - tanto do sistema de arquivos como de chamadas de API, que preza asegurana por default- e pelo mecanismo de IPC (Inter-Process Communication), quetambm aplica tais permisses para conceder acesso ou no entre os diferentescomponentes. Tal plataforma alicerada em torno de algumas caractersticas,conforme visto a seguir:

Dispositivos de hardware - assim como o prprio Linux, diversas configuraesde hardware so suportadas pelo Android, entre elas: smartphones, tablets, set-top-boxes e e-readers. Cada um desses dispositivos possui controles de

segurana implementados em hardware - como por exemplo o ARM (AdvancedRISC Machine) TrustZone e o ARM XN (execute never) - e o sistema capaz dese utilizar de tais capacidades;

Sistema operacional - baseado no kerneldo Linux, o ncleo do Android prov ainterface para a utilizao do dispositivo. O acesso a todos os recursos mediado pelo sistema operacional e fica restrito aos controles de seguranaimplementados por este;

Ambiente de execuo de aplicaes (Android Application Runtime) - A maioriados aplicativos para Android so desenvolvidos em Java e rodam na mquinavirtual Dalvik, embora seja possvel criar aplicaes que executam cdigo nativona plataforma do dispositivo. Ainda assim, essas aplicaes, juntamente com os

outros servios providos pela plataforma e pelas bibliotecas, que rodam cdigonativo, executam em um ambiente confinado denominadosandboxde aplicao.Este confinamento restringe as permisses de acesso da aplicao, em seuambiente de execuo, ao sistema, a recursos do sistema, a dados de outrasaplicaes e a outras aplicaes em execuo.

A segurana da arquitetura baseia-se fortemente nos mecanismos de seguranaaplicados pelo kernel do Linux e na disponibilizao de uma comunicao inter-

processo segura. Todo cdigo de aplicao, incluindo as que executam cdigo nativo,ficam restritas pelosandboxde aplicao, que implementado por meio de um modelode 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 ohardware em questo, ficando sob responsabilidade do fabricante do dispositivo. Aseguir, est descrito um resumo desse processo de acordo com o detalhado em[Bjrnheden 2009].

Inicialmente, um cdigo carregado da ROM (Read Only Memory) executado afim de detectar algum cdigo de boot (bootloader) em alguma das mdias dearmazenamento disponveis, para, em seguida, carreg-lo e transferir a execuo para omesmo. O cdigo da ROM verifica a assinatura do cdigo de boot e, somente se a

mesma for vlida, a inicializao prossegue. O cdigo de bootcitado dividido em doisestgios.




67/204

O primeiro responsvel por configurar a memria RAM (Random AccessMemory) externa, visto que tudo at ento vinha sendo carregado na memria RAMinterna. Esse estgio geralmente d a opo de carregar imagens de recuperao, alm

de possibilitar a execuo de funes de desenvolvimento tais como: realizarflashingebaixar e executar outras verses do sistema. Embora tais opes sejam disponibilizadas,a funo usual desse primeiro estgio o carregamento do segundo estgio do cdigo debootna RAM externa.

O cdigo do segundo estgio responsvel pela configurao dos firmwaresepelo carregamento do kernelna memria. Nessa etapa existe a possibilidade de verificara assinatura do kernelantes de passar o controle da CPU (Central Processing Unit) aele, contudo, os fabricantes normalmente no aplicam a checagem em questo.

O processo de inicializao a partir desse momento prossegue como emqualquer 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 oobjetivo de executar cada aplicativo que se fizer necessrio. Em seguida, um serviochamado System Server ser iniciado visando ativar os servios essenciais dodispositivo.

2.2.3.

Modo de Recuperao e ModoBootloader

O modo de recuperao, mantido em uma partio (/recovery) de inicializao queno a partio de boottradicional (/boot), permite o fornecimento de uma imagem derecuperao 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 permiteainda a formatao do dispositivo.

Normalmente, quando se obtm acesso administrativo ao dispositivo, altera-se aimagem de recuperao com uma imagem maliciosa. Esse modo de recuperaomodificado permite a atualizao do sistema com imagens no assinadas pelofabricante, o que permite que seja fornecida uma imagem que prov acessoadministrativo ao sistema, ainda que esteja definida uma senha ou PIN para controle deacesso.

J no modo bootloader, possvel fazerflashingna ROM do dispositivo, sendopossvel modificar as parties de boot, de recuperao e de sistema. Normalmente, essa

tcnica aplicada para obter aceso mais privilegiado ao sistema, por meio do flashingde imagens que permitam aceso administrativo.

Para tal, diversos protocolos podem ser utilizados - normalmente via USB - oque varia de acordo com o fabricante e at mesmo entre dispositivos do mesmofabricante. necessrio tambm que o bootloaderno esteja em modo protegido porhardware, o que impossibilitaria o flashing. A proteo supracitada trata-se da secure

flag, que permite apenas o flashingde imagens assinadas pelo fabricante. possveldesativar essa flag, todavia todas as informaes no dispositivo so descartadas e omesmo volta para o estado de fbrica.




68/204

2.2.4.

Depurao via USB

Existe um servio de depurao em todo sistema Android que pode ser ativado em suasconfiguraes. Feito isso, um daemon ser iniciado, o adbd (Android Debug Bridge

Daemon), com as permisses do usurioshell. Esse depurador possibilita a instalao edesinstalao de aplicativos, o gerenciamento de logs, a execuo de comandos deshell,a cpia de arquivos de e para o dispositivo, a gerao e restaurao de backups, entreoutros.

Essa interface de acesso utilizada para copiar exploits para o dispositivo eexecut-los a fim de ganhar acesso privilegiado ao sistema. A exposio se torna aindamaior pelo fato desse servio de depurao ser iniciado por defaultcaso o sistema tenhasido 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 definidos4 modos com diferentes nveis de segurana. Abaixo uma descrio de cada um emordem crescente de segurana:

Reconhecimento Facial: o modo mais inseguro. J houveram ataques em queessa controle foi quebrado com simplesmente uma foto sendo apresentada aosensor [Callaham 2011]. Hoje em dia, uma foto pode ser facilmente obtidaatravs 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 mecanismosmais robustos contra ataques despoofing.

Padro de desenho: neste modo, desenha-se um padro na tela ligando pontosem um campo. Considerando um campo 3x3, e que cada um pode serrepresentado, este modo nada mais que uma senha de nove nmeros, os quaisno 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 dodispositivo, 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 asenha, o fato de ser composta apenas por caracteres numricos limita suasegurana.

Senha: a senha que possibilita o uso de letras, nmeros e smbolos. Devido aodomnio 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 deacesso 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 telarequisitando a credencial de acesso apresentada novamente. Esse um mtodo quevisa garantir que apenas o legtimo dono do dispositivo consiga utiliz-lo.

No caso de vrias tentativas errneas de acesso ao sistema ocorrerem, ummecanismo de bloqueio de tentativas baseado em backlogexponencial aplicado. Neste

caso, dada a opo de recuperao do acesso ao dispositivo, considerando que acredencial de acesso foi perdida. possvel ento obter acesso ao sistema fornecendo




69/204

uma conta Gmail previamente associada ao sistema operacional, juntamente com suarespectiva senha de acesso.

Uma funcionalidade que passou a ser implementada a partir da verso 3.0 doAndroid a encriptao de disco / da partio de dados . Essa necessidade advm dofato 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 todasas informaes nele armazenadas. Essa funcionalidade, que pode ser habilitada nasconfiguraes do sistema, busca assegurar que o extravio do dispositivo no resulte nocomprometimento da informao, ainda que o bootloader ou o sistema sejammodificados pelo atacante por meio deflashing.

Ainda que a memria permanente do dispositivo seja dividida em diversasparties, dentre elas: boot, recuperao, sistema e dados, a encriptao ocorre apenasna partio de dados, que onde os dados pessoais do usurio, suas configuraes,

aplicativos e logsficam armazenados. O processo de encriptao dos dados da partioocorre da seguinte maneira [Android Open Source Project 2012c]:

1. Uma chave mestra de 128 bits gerada por meio de /dev/urandoma fim deser utilizada para a encriptao da partio;

2. Utiliza-se ento essa chave mestra para encriptar a partio por meio doalgoritmo AES (Advanced Encryption Standard) em modo de operao CBC(Cipher Block Chaining). A fim de gerar um vetor de inicializao nico paracada 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 PINdescritos 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 (Password-Based Key Derivation Function 2), juntamente com umsaltgerado por meio de/dev/urandom. O salt adicionado visa dificultar ataques baseados emrainbow table, e, a fim de tornar ataques de fora bruta mais custosos, aplica-sea funo de derivao repetidamente por 2000 vezes, tcnica essa conhecidacomo key stretching. A sada dessa operao um valor de 256 bits;

2. Divide-se a sada de 256 bitsdo 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, taiscomo: soluo criptogrfica utilizada, tamanho da chave e o salt adicionado senha.

Recentemente mostrou-se [Cannon 2012] como obter o crypto footer a fim derealizar fora bruta da credencial de acesso com o objetivo de decriptar a partio eobter os dados do usurio. Os controles por PIN foram quebrados em questo desegundos e os autores ainda alertaram para o fato de que controles por senha geralmenteresultam 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




70/204

chave de encriptao do disco e outra para o bloqueio de tela. Na primeira poder-se-iaaplicar uma poltica de definio de senhas forte e requisit-la apenas quando o sistemaestivesse 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 usuriono 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 permissesnecessrios para a realizao de suas tarefas.

Esse nvel de segurana elevado alcanado pelo fato de o sistemaimpossibilitar que o usurio instale aplicativos com permisses de superusurio, o que

concederia tais permisses ao aplicativo em questo. Outro fator relevante o fato de sepermitir a proteo de contedo digital includo nos aparelhos, tais como ringtones ewallpapers. E, por ltimo, pelo fato de impossibilitar que usurios quebrem o sistemade boqueio empregado pelas operadoras, como, por exemplo, impossibilitar que odispositivo seja utilizado como um hotspotcom o objetivo de compartilhar o pacote dedados contratado com terceiros.

O grande problema com essa estratgia de restringir o acesso ao usurio o fatode que um usurio com acesso fsico a um dispositivo, normalmente, caso realmentemotivado, pode conseguir contornar qualquer mecanismo de segurana aplicado. E, deacordo com [Dwivedi et al. 2010], isso no se limita somente a vulnerabilidades no

Android, a subverso dos mecanismos de segurana tambm podem resultar devulnerabilidades no bootloader, nos firmwares do dispositivo, no mecanismo deproteo de memria por hardware e em configuraes de barramento, tanto emhardware como em software.

2.2.7. Rooting

Foi criado o termo rootingpara se referir ao ganho de acesso irrestrito plataforma dosdispositivos rodando Android, algo equivalente ao processo dejailbreakingexistente noiOS, da Apple, ou no PlayStation 3, da Sony. O processo de rooting mudasignificantemente de dispositivo para dispositivo, de acordo com diferenas dehardware existentes em cada um deles.

Como o Android derivado do Linux, fazer o rooting equivale obterpermisses de acesso administrativo no dispositivo, ou seja, as permisses da contaroot. As motivaes para a habilitao de tal acesso so vrias, como por exemplo:Instalao de verses modificadas do Android (sendo a ClockWorkMod a mais famosadelas); Uso de temas personalizados; Executar modificaes no kernel; Backup de todosos dados, pois necessrio acesso administrativo para se obter tais dados; Ativarfuncionalidades que foram bloqueadas por operadoras (como o NFC). Para se efetuar aativao de tal acesso, existem quatro tcnicas diferentes, que sero explicadas a seguir.

1. Flash recovery: Os dispositivos Android possuem um modo chamado Flashrecovery, 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




71/204

administrativo ao sistema, e restaurar o dispositivo a seu estado original defbrica a partir desta.

2. Flash boot(Fastboot): Uma tcnica bastante utilizada para rooting oflashing

de imagem modificada nas parties do sistema de modo que se possa obteracesso privilegiado.

3. Escalada local de privilgios: Um atacante que obtiver acesso a um shell nosistema (o qual limitado e com poucos privilgios) pode conseguir fazer umaescalada 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 aosistema, contudo pode ser possvel se utilizar de tal via de acesso para exploraruma vulnerabilidade que permite escalada de privilgios.

Existem algumas ferramentas que contm payloadsmalicosos que permitem a

explorao de vulnerabilidades existentes no sistema visando obter acessoadministrativo. Uma famosa opo a ferramenta SuperOneClick. Ela executada emambiente Windows e tenta identificar a verso do dispositivo Android atualmenteconectado, para, em seguida, aplicar um ou mais ataques afim de se obter o root noaparelho. Outra opo a z4root, a qual funciona em dispositivos com verso 2.3 ouinferior do Android. A ferramenta explora uma vulnerabilidade para executar umaescalada 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 doscasos pois, atualmente, 75% dos aparelhos que usam a plataforma da Google rodam averso 2.3 ou alguma anterior [Android Developers Project 2012c].

Vale ressaltar que a Subseo 2.6.2 contm informaes sobre os riscos desegurana 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 depermisses de usurio do Linux, em que cada usurio recebe um UID (user-id) e oacesso aos recursos dos sistema controlado por usurio.

Os recursos do sistema, tais como interface de rede e cmera so mapeados paraentradas 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 privilgiosaplicados ao dono do arquivo sejam isolados dos aplicados ao grupo ao qual esseusurio pertence e dos outros usurios do sistema. Embora simples, esse um modeloque j provou sua eficcia por ter sido o modelo adotado pelo Unix, e por vir sendoutilizado 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 cadaaplicativo instalado, cria-se um diretrio no sistema de arquivos onde todos os arquivosassociados sero armazenados. Apenas o UID do aplicativo possui total acesso a essediretrio, o grupo ao qual pertence e os outros no possuem qualquer permisso deacesso.

Esse modelo funciona como se cada aplicativo fosse um usurio no modelo depermisses do Linux, dessa forma, cada aplicativo executado com suas prprias




72/204

permisses de acesso. Esse controle impossibilita o acesso por parte de aplicativosmaliciosos a recursos protegidos do sistema ou de outros aplicativos, diferente domodelo 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 injetadopermanecer restrito s permisses da aplicaes em questo, no sendo possvel oacesso a outros recursos.

O kerneldo Linux tambm prov uma forma de controle de acesso a regies dememria dos processos, assegurando que diferentes processos no interfiram ouacessem as regies de memria de outro. Esse conceito a base para o modelo deconfinamento de aplicativos do Android [Six 2012].

Como pode-se notar, a segurana do sistema extremamente dependente dessemecanismo de controle de acesso aplicado pelo kerneldo Linux, todavia existem aindaoutros mecanismos de segurana relacionados a permisses de API que sero tratadosmais 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 devulnerabilidades de corrupo de memria e de tornar o processo de desenvolvimentode exploits complexo a fim de dificultar que exploitsgenricos sejam utilizados paraganhar acesso ao dispositivo.

Devido ao fato de ser possvel encontrar todas as verses de Android nomercado, importante compreender as protees aplicadas em cada uma delas com oobjetivo de entender os riscos associados a cada um das verses. A seguir umdetalhamento das melhorias obtidas, em relao a contramedidas implementadas, aolongo 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 afim de garantir a utilizao de operaes seguras com inteiros; rotinas degerenciamento de memria que aplicam protees contra vulnerabilidades de double

freevisando prevenir ataques de consolidao de chunksda heap.

A partir da verso 2.3 adicionaram-se os seguintes controles: protees contravulnerabilidades de format string; preveno de execuo de regies de dados porhardware; definio de endereo mnimo para mapeamento de memria visandoimpossibilitar exploraes baseadas em null pointer dereference.

O lanamento da verso 4.0 marcou o incio do suporte ASLR (Address SpaceLayout Randomization), entretanto, apenas na verso 4.1, foi introduzido suporte PIE(Position Independent Executable) e RELRO (Relocation Read-Only). Visando evitarvazamento de endereamento do kernel, dmesg_restrict e kptr_restrict, passaram a sersuportados tambm nessa verso.

Embora diversas tcnicas sejam aplicadas, as mesmas apenas dificultam aexplorao dessas vulnerabilidades. Atualmente, com a utilizao de ROP (Return




73/204

Oriented Programming) e de uma vulnerabilidade que possibilite a obteno deinformao sobre o mapeamento de memria da aplicao, possvel se utilizar de umaoutra vulnerabilidade para ganhar o controle de execuo. Em [Serna 2012] mostrou-se

como, a partir de uma vulnerabilidade, obter informaes sobre o processo emexecuo. Um outro trabalho interessante [Ridley e Lawler 2012], apresentou tcnicasde explorao modernas em arquitetura ARM.

Ainda que um mecanismo de aleatorizao seja aplicado, dois grandesproblemas com o modelo da arquitetura do Android vm tona. O primeiro o fato deque, 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 serresponsvel por interpret-lo. Esse processo de bifurcao nada mais do que um clonedo processo, seguido do carregamento de uma nova rea de cdigo (.text). Como

resultado dessa operao, os parmetros de aleatorizao sero sempre os mesmos emtoda 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 quemantm 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 submeteraplicativos 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 dapessoa registrada, caso seja necessrio.

Feito isso, o desenvolvedor pode submeter seus aplicativos para a loja. Osaplicativos devem ser assinados digitalmente e o certificado deve ser empacotado

juntamente com o aplicativo no APK. Ao ser instalada, o Package Manager verifica se oaplicativo foi de fato assinado com o certificado includo junto a ele.

Um ponto muito criticado o fato de no ser necessrio um certificado geradopor um entidade confivel para assinar os aplicativos. A prtica a gerao decertificados auto-assinados para este fim. Desse modo qualquer sujeito pode gerar umcertificado em nome de outra entidade e assinar aplicativos como se fosse esta.

O que se conclui disso que o objetivo dessa assinatura no a rastreabilidadedo desenvolvedor a fim de poder responsabiliz-lo no caso de serem identificadasfuncionalidades maliciosas no aplicativo, mas sim associar umcertificado/desenvolvedor com aplicativos anteriormente disponibilizados de modo queos usurios possam avali-lo, o que vai ditar se o mesmo confivel ou no. Aindarelacionado a essa temtica, est o fato de os aplicativos executarem com certaslimitaes caso no tenham sido assinados. Isso, justamente pelo fato de o aplicativono estar associado a nenhum certificado/desenvolvedor.

Alm disso, a assinatura serve para agrupar aplicativos do mesmo autor de modoque os mesmos possam interagir entre si sem ficarem restritos pelo esquema de

permisses que usualmente se aplica comunicao inter-processo. Essas aplicaespodem, inclusive, compartilhar um UID, bastando que isso seja explicitamente




74/204

configurado no AndroidManifest.xml de ambas. Por ltimo, a assinatura tambmpermite associar uma aplicao com sua respectiva atualizao.

Diferentemente da Apple Store que s disponibiliza os aplicativos para osusurios 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 queno a oficial. Um ponto negativo que se pode levantar na estratgia empregada pelaApple o fato de que a reviso manual atrasa o lanamento de aplicativos, aforacomprometer a eficincia da aplicao de atualizaes de segurana, aumentando aindamais 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 tentaridentificar comportamento potencialmente malicioso, o melhor mecanismo de controle

para a plataforma isolar cada aplicao juntamente com seus dados e restringir aschamadas 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 econforme for requisitado no AndroidManifest.xml. No deve ter permisses de utilizartodas as chamadas por default.

Todavia, no incio do ano, a Google apresentou uma soluo que seriaempregada para avaliar as aplicaes e a intitulou de Bouncer. Descobriu-se

posteriormente que era uma soluo automatizada que simula o ambiente de execuodo Android e executa o aplicativo a fim de monitorar seu comportamento e identificarfuncionalidades 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 [Six2012].

Bouncer parte, a segurana nesse modelo de loja de aplicativos adotado peloAndroid se alicera fortemente no usurio que est realizando a instalao de umaplicativo. Para tomar a deciso, o usurio pode se utilizar de trs fontes de informao:revises do aplicativo; reputao do desenvolvedor; e permisses requeridas [Dwivediet al. 2010].

Um funcionalidade controversa que pode ser acionada pela Google a qualquermomento a remoo remota de aplicativos [Vidas et al. 2011]. Caso um aplicativomalicioso 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 questovisando 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 dispositivosremotamente.

2.2.11.

Atualizaes,Patchese Ciclo de Vida das Vulnerabilidades

Como anteriormente discutido, o ncleo do sistema Android disponibilizado pelaGoogle 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 emrelao ao dos demais. Feito isso, a vez das operadoras fazerem suas prprias




75/204

modificaes e inclurem seus aplicativos proprietrios. S ento que o dispositivofica pronto para ir para as lojas e chegar as mos dos usurios.

Toda essa complexidade no processo resulta em um grande problema quando setrata do ciclo de vida das vulnerabilidades na plataforma. A janela de explorao nessecaso muito maior do que a vista normalmente em outros tipos de software. A seguirum 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 driverde dispositivo, porexemplo.

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 odispositivo e a verso ainda estiverem sendo suportados ou se a correo noafetar nenhuma das funcionalidades sendo providas ou gerar umaincompatibilidade com outro componente;

5. Da mesma forma que os fabricantes, a operadora s adequa a correodisponibilizada pelos fabricantes a sua verso caso no afete funcionalidades oucause 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 opatchde segurana.

Nota-se que o processo toda muito complexo, e que existem diversos pontosem que o sistema modificado, seja por fabricante ou por operadora. Dado que existemaproximadamente 50 fabricantes e algo em torno de 300 dispositivos [Hoog 2011], essacomplexidade mostra-se ainda maior, isso sem levar em considerao a quantidade deoperadoras.

Toda essa complexidade na liberao de patches e na manuteno dosdispositivos com as verses mais atualizadas do sistema resulta em uma janelaexplorao muito grande. E, devido ao fato de serem lanadas verses corrigidas poralguns fabricantes e operadoras mais rapidamente do que as demais, os atacantes podemfazer engenharia reversa dessespatchesvisando entender a vulnerabilidade corrigida demodo que se possa criar os exploits associados e obter acesso ao dispositivos cujacorreo 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 dedesenvolvimento seguro vm sendo seguidas, afora serem criados/aplicados controles




76/204

de segurana a fim de dificultar ou impossibilitar exploraes ao sistema. Ademais,existe um quantidade muito maior de aplicativos difundidos no mercado do quesistemas operacionais, e a quantidade de desenvolvedores de SOs muito inferior a de

desenvolvedores de aplicativos, alm de que os primeiros normalmente so muito maisexperientes e possuem um conhecimento de computao muito mais consistente do queos ltimos. Disso resulta uma quantidade muito maior de aplicativos vulnerveis do quede SOs.

Como mostrou-se em 2.2, o Android permite o confinamento de aplicaes pormeio 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 umdiretrio para armazenamento de seus dados que restrito pelo esquema de permissesdo sistema de arquivos apenas a ela. Esse modelo s pode ser "quebrado" por aplicaesassinadas com o mesmo certificado digital e que explicitamente requeiram o

compartilhamento do UID via o arquivoManifest[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 deassegurar 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 darede celular.

Sendo assim, criou-se um esquema de permisses que limitam o acesso dasaplicaes 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 naaplicao que permita uma explorao, o cdigo injetado ficar confinado no ambientedesta aplicao e ter apenas os privilgios que a mesma possua. Ou seja, a exploraode uma vulnerabilidade em um jogo, por exemplo, no permitiria que informaes decontatos fossem obtidas por meio de cdigo injetado, isso, claro, se as devidas

permisses tiverem sido atribudas ao jogo em questo. O esquema funciona da seguintemaneira:

1. O desenvolvedor lista no AndroidManifest.xml todas as permisses necessriaspara o funcionamento da aplicao;

2. Durante a instalao desta, o usurio alertado sobre as permisses sendorequisitadas, tendo a opo de aceit-las ou no;

a.Modelo tudo ou nada. Ou o usurio aceita e utiliza a aplicao ou nega e aaplicao no instalada.

3. Aps a aceitao do usurio, a aplicao instalada e passa a desfrutar daspermisses que lhe foram atribudas. O usurio no mais informado sobre aspermisses sendo utilizadas;

4. possvel, por meio das configuraes do sistema, visualizar as permissesatribudas a cada aplicao instalada;

5. O usurio tambm pode desabilitar globalmente algumas funcionalidades, taiscomo: 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




77/204

atualizao no ocorrer de modo automtico, sendo necessria a interao do usuriopara 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 setratando de mensagens relacionadas segurana. A exemplo da aceitao de certificadosinvlidos nos navegadores, isso decorre do fato de os usurios considerarem taismensagens como empecilhos para a usabilidade da aplicao ou do sistema.

Adicionalmente, podem existir problemas com a implementao dessemecanismo 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 estutilizando APIs e servios disponibilizados pelo sistema. Neste caso necessriolevantar quais permisses so requeridas pelas funcionalidades sendo utilizadas a fim deinclu-las no Manifest do aplicativo. A segunda quando se est disponibilizandoservios. Neste caso, necessrio assegurar que os componentes e aplicaesutilizando-os possuem as devidas permisses para realizar as operaes sendofornecidas.

A aplicao de algumas permisses so deixadas a cargo do kernel. Porexemplo, as permisses de acesso internet, escrita em dispositivos dearmazenamento externo e ao Bluetooth so concebidas por meio da criao de gruposno sistema. Ao requisitar a permisso de acesso internet, por exemplo, o UID da

aplicao adicionado ao grupo inet, desse modo, tornando possvel o acesso schamadas de sistema associadas. Essa estratgia permite a manuteno do sistema de

permisses, geralmente para acesso a sensores, ainda que haja um comprometimento namquina virtual.

As permisses default do Android so divididas em 4 categorias, chamadasnveis de proteo, a saber:

1. Normal - categoria de permisses, que so aceitas automaticamente durante ainstalao 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 dodispositivo. Essas permisses so informadas ao usurio em tempo de instalaoe s so delegadas caso este as aceite. Exemplos incluem:ACCESS_FINE_LOCATION, READ_CALL_LOG, CAMERA, INTERNET eWRITE_SETTINGS;

3. Signature - uma permisso nessa categoria automaticamente concedida aaplicaes assinadas como o mesmo certificado digital da aplicao que a criou,caso contrrio, ela negada. Esse nvel de proteo permite o compartilhamentode dados entre aplicaes do mesmo desenvolvedor, entretanto, a maiormotivao para esse nvel o controle de permisses extremamente crticas.

Como tais permisses so criadas por aplicaes pr-instaladas, as mesmas spodero ser acessadas por cdigo assinado pelo fabricante. Exemplos incluem:DEVICE_POWER, HARDWARE_TEST e INJECT_EVENTS;




78/204

4. SignatureOrSystem- similar ao nvel Signature, contudo, inclui tambm cdigoda imagem do sistema, ou seja, uma permisso nesse nvel concedida tanto sefor 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 dosistema. Concebido visando permitir que os diversos provedores de aplicaesdo sistema - OHA, fabricante e operadora - possam obter algumas permisseschave. 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 criarsuas prprias permisses objetivando criar controles de acesso a servios providos porsuas aplicaes por meio de componentes como Activities, Services, Content Providerse 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 ocorreto funcionamento de uma aplicao.

Quadro 1: Definio de uma permisso no arquivo AndroidManifest.xml.

Quadro 2: Especificao no AndroidManifest.xml das permisses requisitadas

pela aplicao.

2.3.2. Componentes de Aplicao

Uma aplicao Android possui quatro componentes principais, os quais so citados emelhores 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. Sodefinidos, por exemplo, para checar atualizaes no Facebook - tais como novasrequisies de amizade, novas mensagens ou notificaes - ou para tocar umamsica em background. No primeiro caso chamado de Bound Service, pois

permite a interao com outros componentes via IPC, j no segundo, chamadode Started Service pois realiza sua funo sem qualquer tipo de interao com

outros componentes. Content Provider: uma interface que permite a uma aplicao disponibilizarseus dados para acesso de leitura e escrita para outras aplicaes por meio de

...

...




79/204

URIs (Uniform Resource Identifier) do tipo: content://com.me.app.myapp.mailprovider/messages/inbox/16. Normalmente utilizada paradisponibilizar acesso a uma base SQL.

Broadcast Receivers: funcionam como manipuladores de eventos. Ficam emmodo de escuta esperando por Intents que podem ser enviados diretamente aocomponente ou o sistema pode designar determinado Broadcast Receiver paratrat-lo de acordo com o IntentFilter definido.

Normalmente, esses componentes so executados no mesmo processo daaplicao, 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 fazemparte de aplicativos distintos, porm, escritos pelo mesmo desenvolvedor, possamcompartilhar um mesmo processo.

2.3.2.1. Intent

Os Intents so estruturas de dados que permitem a requisio de uma operao. So, defato, a base do mecanismo de IPC do Android.

De acordo com [Six 2012], Intents podem ser criados por uma aplicao eenviados para componentes especficos ou podem ser enviados para todos oscomponentes do sistema por meio de broadcasts. Normalmente, Intents so criados afim de iniciar Activities ou Services, todavia, podem carregar dados para serem tratados

por algum componente especificado ou enviar os dados e esperar que algumcomponente seja capaz de faz-lo.

Um componente pode especificar, via sua definio no AndroidManifest.xml,IntentFilters visando demonstrar interesse em determinados Intents. Por exemplo, pode-se criar um Intent a fim de abrir uma URL. Nesse caso, o Activity Manager verificarqual 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 definiode uma Activity com um IntentFilter associado que demonstra interesse no recebimentoIntents requisitando visualizao de contedo HTTP.

Quadro 3: Definio de uma Activity interessada em Intents requisitando a

visualizao de contedo HTTP.

Um cenrio de explorao descrito em [Dwivedi et al. 2010], quando umaaplicao envia um Intent to logo invocada. Nesse caso, deve-se assegurar que todasas aplicaes que a invocarem tenham as devidas permisses para o envio desse Intent,

...




80/204

caso contrrio, as aplicaes chamadoras poderiam utilizar essa aplicao mal escrita afim 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 aoidentificador da aplicao chamadora.

2.3.2.2.Permisses Aplicadas a Componentes

possvel que componentes de diferentes aplicaes interajam entre si (comunicaointer-processo), todavia, essa interao pode expor dados sensveis de uma aplicao

para a outra. Ademais, a API permite um baixo acoplamento entre os componentesdevido 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 acessarinformaes de um Content Provider, ou ainda para enviar broadcastspara BroadcastReceivers. Para ser acessado por componentes de outras aplicaes, necessrio que omesmo seja exportado explicitamente ou que defina ao menos um IntentFilter, casocontrrio, 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, abusandode 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 onome do pacote em questo. Esse diretrio associado ao UID recm criado e ocontrole de acesso sobre o mesmo aplicado pelo kerneldo Linux. Por defaultapenas odono do diretrio possui acesso irrestrito ao diretrio. Grupos e outros no possuemnenhuma permisso. Alguns diretrios nessa estrutura incluem:

files/- todos os arquivos criados pela aplicao;

shared_prefs/ - A API permite a definio de modo programtico decampos nome/valor em arquivos XML (Extensible Markup Language) que somantidos 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 cachemantidos 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 paraqualquer aplicao no dispositivo;




81/204

MODE_WORLD_WRITABLE - disponibilizao de acesso de escrita paraqualquer aplicao do dispositivo.

Deve-se destacar o fato de que tais permisses tambm se aplicam a bases dedados 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 deoutros componentes a essas informaes por meio de permisses aplicadas acomponentes.

2.3.4. Programao Segura

Nesta subseo, so listadas e explicadas tcnicas e medidas que devem ser tomadaspara a programao segura em dispositivos mveis, de acordo com um estudo conjuntoda 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 deescrever cdigo mais robusto contra ataques, seja ele voltado para Android ou no [Six2011].

Foi elaborada uma lista com as boas prticas e medidas a serem tomadas peloprogramador, 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 computadorpessoal;

o Dados sensveis precisam ser protegidos (com criptografia, porexemplo), a fim de minimizar os riscos e o dano do roubo ou da perda dedados e do aparelho;

o Outro meio de se proteger os dados o armazenamento no servidor aoinvs de no prprio dispositivo.

Criao de sites parasmartphonese tablets:

o Crie URLs seguras e intuitivas;

o A falta de padro aumenta o potencial dephishing.

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 aaplicao considere tais arquivos como fonte confivel de dados e no osvalide antes de process-los;

o Outras aplicaes no devem possuir permisso de escrita sobre cdigosexecutveis e arquivos de configurao;

o Outras aplicaes, geralmente, no devem possuir permisso de leitura

sobre arquivos de loge bases de dados. Armazene e transmita de forma segura as credenciais do usurio:




82/204

o Spywares e malwares esto cada dia mais comuns em dispositivosmveis, sobretudo em Android;

o Uma credencial, se roubada, pode permitir o acesso no autorizado afuncionalidades e dados no s do prprio servio que usa taiscredenciais como de outros servios do usurio. Caso seja umaautenticao compartilhada por outros servios (como a do Facebook), orisco ainda maior;

o Permita ao usurio ter a opo de mudar sua senha e, sempre que fornecessrio o armazenamento, utilize criptografia.

Sempre proteja dados sensveis durante a transmisso:

o Dispositivos mveis modernos podem se utilizar de vrias redes paracomunicao (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 seaproveitar da integrao para obter e transmitir dados sensveis;

o Sempre faa a validao dos dados recebidos e enviados de outrosaplicativos.

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 mesmoproveniente de um aparelho que foi comprometido.

Implemente autenticao e gerenciamento de sesso corretamente:

o O uso indevido da autenticao e do gerenciamento de sesso permiteque um atacante faa um acesso indevido ao sistema, e que o mesmoreuse tokensou cookies;

o Utilize a classe AccountManager, disponvel no Android, para o uso de

tokensna autenticao com servidores. O uso do AccountManager com oAuthenticator o ideal para a autenticao dos usurios, ao invs deverificao de logine senha;

o Pea ao usurio para que use senhas fortes e utilize protocolos seguros decomunicao.

Preste ateno ao coletar e usar dados pessoais do usurio:

o Crie uma poltica de privacidade e pea o consenso do usurio antes dacoleta e uso dos dados do mesmo.

Crie programas com provisionamento de segurana:

o Os aplicativos devem permitir o uso de atualizaes de segurana pararesolver possveis problemas futuros.




83/204

Implemente controles para prevenir o acesso no autorizado a recursos depagamento:

o Existem vrios meios de pagamento disponveis hoje em um aparelhocom Android. Tome cuidado com as chamadas a APIs e o uso de taisservios, 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 domesmo. O cdigo-fonte de um aplicativo Android facilmente revelado

por meio de engenharia reversa, e a ofuscao uma boa ttica paradificultar este processo;

o A Google disponibiliza uma ferramenta chamada ProGuard a qualdiminui, otimiza e ofusca seu cdigo Android [Android Developers

Project 2012d]. Ela pode ser baixada e usada gratuitamente [Lafortune2012].

Cuidado ao utilizar o sistema de permisses:

o Sempre especifique permisses estaticamente durante a definio doscomponentes no arquivo Manifest, assegurando assim que todos osmtodos de um componente vo estar com as permisses adequadas;

o Se houver a necessidade de gerenciar tais permissesprogramaticamente, deve-se aplicar checagens por meio de chamadas acheckCallingPermission 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 delocalizao. 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 statementspreparados, ao invs de concatenar os dados aos comandos SQL.

Preste ateno nas boas prticas de programao independentes de linguagem eplataforma:

o Teste exaustivamente seu aplicativos;o Valide todas as entradas;




84/204

o Tente fazer um cdigo pequeno e sem muita complexidade;

o Use analisadores de cdigo esttico e dinmico, para levantamento dasvulnerabilidades grosseiras;

o Use o mnimo de privilgios possvel, e tenha cuidado com os privilgiosnecessrios pelas APIs utilizadas;

o No autorize nenhum cdigo a ser executado em nvel administrativo;

o Tente no abrir nenhuma porta especfica para comunicao, e muitomenos a deixe aberta em listening. Use sempre os mecanismos decomunicao 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. Sointroduzidas tcnicas para (1) anlise esttica, (2) dinmica e (3) via depurador dosartefatos. A primeira envolve a inspeo do bytecode ou cdigo de mquina, com oauxlio de tcnicas e ferramentas para disassembly e descompilao. J a segundaenvolve o monitoramento e a interao com o aplicativo em execuo. Por fim, aterceira 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 necessriasalgumas definies [Felt et al. 2011]:

Malware o software que rouba, modifica, ou apaga dados de aplicaes ou dosistema operacional do usurio sem o consentimento deste. Isto , no foi obtidaautorizao 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 deum usurio. A diferena entre este tipo e o malware que na instalao dosoftware 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 usurioalvo (usurio que utilizar o dispositivo aps instalao).

Nesta seo consideraremos somente ameaas do tipo malware. No entanto, astcnicas e ferramentas apresentadas se aplicam a spywares, ou a qualquer outro tiposoftware malicioso ou benigno.

Todas as ferramentas citadas nesta seo so gratuitas e de cdigo aberto, excetoonde for dito o contrrio.

2.4.1. Organizao do Cdigo de uma Aplicao

definida nesta subseo conceitos importantes sobre a organizao do cdigo deaplicaes Android que sero utilizados em subsees subsequentes. As principaisestruturas de cdigo de uma aplicao so:




85/204

Bytecodes Dalvik: instrues da mquina virtual Dalvik (DVM). Soexecutadas por uma instncia da DVM, dentro do processo Linux destainstncia.

Dex (Dex Executable): um formato de cdigo executvel para a DVM. Umarquivo .dex pode ser abstrado como uma coleo de arquivos compilados, cadaum correspondendo a uma classe do cdigo fonte original. Os arquivoscompilados so arquivos binrios contendo bytecodesDalvik.

A Figura 2 ilustra o processo a partir do qual um ou mais arquivos de cdigofonte na linguagem Java so transformados em um arquivo Dex. O programa javaco compilador Java distribudo pelo projeto Apache Harmony (e incorporado ao AndroidSoftware Development Kit, ou Android SDK), e transforma um cdigo fonte Java emarquivos .class, os quais contm bytecodesda JVM (Java Virtual Machine). Por sua vez,o programa dx distribudo no Android SDK, e transforma os bytecodesda JVM em

bytecodesda 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 em49 famlias, coletadas de Agosto de 2010 a Outubro de 2011, e constitui a anlise maiscompleta realizada at hoje sobre a caracterizao e evoluo de malwares para a

plataforma Android. Os resultados mostram que 86% das amostras so trojansque re-empacotam aplicaes legtimas com a adio de payloadmalicioso (daqui em diantechamados malwares de re-em

Minicursos SBSeg 2012

Documents

Transcript of Minicursos SBSeg 2012