I_Teorico

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Ataques e Defesa para 
Dispositivos Móveis
Ataques em Sistema Operacional Android
Responsável pelo Conteúdo:
Prof. Hélvio Benedito Dias de Carvalho Júnior
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Nesta unidade, trabalharemos os seguintes tópicos:
• Dispositivos Móveis Base – Conceitos Gerais;
• Arquitetura do Sistema;
• Máquina Virtual Android;
• Modelo de Segurança do Android;
• Táticas em Ambiente Mobile;
• Ataques.
Fonte: Getty Im
ages
Objetivos
• Capacitar os alunos a identificarem ataques cibernéticos em dispositivos móveis, com
ferramentas de simulação de ambientes de Sistemas Operacionais Android e iPhone; 
• Identificar ataques aos Sistemas Operacionais citados, erradicação dos malwares e recu-
peração dos dispositivos.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Ataques em Sistema Operacional Android
UNIDADE 
Ataques em Sistema Operacional Android
Dispositivos Móveis Base – Conceitos Gerais 
Histórico do Android 
A Android nasceu como uma empresa, a
Android Inc., fundada por Andy Rubin, Chris White, 
Nick Sears e Rich Miner, em Outubro 2003. 
Eles criaram a Empresa com o objetivo de 
desenvolver dispositivos móveis inteligentes, que 
pudessem levar em consideração informações de 
localização e preferências de usuário. 
Mesmo acertando a demanda do Mercado 
com essa ideia, eles ainda tinham dificuldades 
financeiras para lançá-la.
Foi então que a Google adquiriu a Android 
Inc., em agosto de 2005. Durante o período 
seguinte, a Google começou a construir parce-
rias com Empresas de hardware, software e de 
Telecomunicações, com a intenção acelerar sua 
entrada no Mercado móvel.
Figura 1 – Andy Ruby, um dos pais do Android
Fonte: Getty Images
Após diversas parcerias fechadas, em novembro de 2007, foi criada a Open Handset 
Alliance (OHA). 
A ideia desse Consórcio de Empresas, que incluía 34 membros fundadores lidera-
dos pela Google, era fazer o Android finalmente sair do papel.
Além disso, seria possível acelerar a inovação da Plataforma Móvel e oferecer aos 
consumidores um serviço móvel mais rico, barato e uma melhor experiência. 
Os membros dessa associação representam todas as partes do ecossistema móvel, 
incluindo operadoras móveis, fabricantes de aparelhos, Empresas de semicondutores, 
software, Empresas e muito mais.
Com a OHA em funcionamento, a Google anunciou seu primeiro produto móvel, o 
Android, disponibilizado para o público em geral, em outubro de 2008. 
O lançamento do primeiro telefone Android publicamente disponível, o HTC G1, 
marcou o início de uma nova era.
6
7
Figura 2 – Primeiro Android HTC G1
Fonte: Reprodução
Arquitetura do Sistema 
A arquitetura geral Android consiste em componentes que se enquadram em seis 
camadas principais, incluindo: aplicativos Android, o Android ou Java API Framework, 
a Máquina Virtual Dalvik, o Código Nativo do espaço do usuário, a camada de hardware 
e o kernel do Linux. 
A Figura 3 mostra como essas camadas compõem a pilha de software do Android.
Figura 3 – Arquitetura Android
Fonte: developer.android.com
7
UNIDADE 
Ataques em Sistema Operacional Android
A camada System Apps é onde as aplicações instaladas pelo usuário residem e executam.
A camada Java API Framework expõe as APIs do Sistema para funcionalidades 
comuns que são rotineiramente usadas pela maioria das aplicações. 
Isso inclui funcionalidades de elementos visuais, compartilhamento de dados ou aces-
sos como telefone ou funcionalidades GPS.
A camada Native C/C++ Libraries contém as Bibliotecas C e C++, as quais geren-
ciam processos de baixo nível, como desenhos gráficos, encriptação de Rede, multimí-
dia e renderização de imagens.
A camada Android Runtime representa a área do Sistema Operacional onde a Má-
quina Virtual (VM) responsável pelas aplicações em execução reside.
A camada Hardware Abstraction Layer (HAL) define as interfaces padrão para os 
fabricantes de hardware implementarem. Utilizando a HAL, os fabricantes podem im-
plementar as funcionalidades sem afetar ou modificar o Sistema alto nível.
A camada Linux Kernel é a camada subjacente que une todas as camadas superio-
res. Essa camada controla todo o acesso ao hardware do dispositivo por meio de drivers 
de dispositivo. 
Como ocorre em qualquer computador, o kernel é o responsável pelo gerenciamento 
de memória, processos e energia. O kernel do Android é baseado no kernel do Linux 2.6.
Os componentes de Código Nativo do espaço do usuário do Android incluem: servi-
ços do Sistema, como void e DBus, serviços de Rede, como dhcpd e wpa_supplicant e 
Bibliotecas, como bionic libc, WebKit e OpenSSL. 
Alguns desses serviços e Bibliotecas se comunicam com serviços e drivers no 
nível do kernel, enquanto outros facilitam operações nativas de nível inferior para o 
Código gerenciado.
O Android fez inúmeras adições e alterações na árvore de fontes do kernel, algumas 
das quais possuem suas próprias ramificações de segurança.
Os drivers no nível do kernel também fornecem funcionalidades adicionais, como 
acesso à câmera, Wi-Fi e outros dispositivos de Rede. De particular atenção é o driver 
do Binder, que Implementa Comunicação entre Processos (IPC).
Figura 4 – Ilustração sobre Mercado mobile
Fonte: developer.android.com
8
9
Características Técnicas
A base do Android traz consigo uma herança bem compreendida do isolamento do pro-
cesso semelhante ao Unix e o princípio do menor privilégio, especificamente, o conceito 
em que os processos em execução como usuários separados não podem interferir uns com 
os outros, como o envio de sinais ou o acesso ao espaço de memória um do outro. 
Logo, grande parte do sandbox do Android se baseia em alguns conceitos-chave: 
isolamento de processo padrão do Linux, UIDs (IDs de usuário exclusivos) para a maio-
ria dos processos e permissões do Sistema de arquivos altamente restritas.
O Android compartilha o paradigma UID/ID de grupo (GID) do Linux, mas não possui os 
arquivos password e group tradicionais para sua origem de credenciais de usuário e grupo. 
Em vez disso, o Android define um mapa de nomes para identificadores exclusivos 
conhecidos como IDs do Android (AIDs). 
O mapeamento inicial de AID contém entradas estáticas reservadas para privilégios 
e usuários críticos do Sistema, como o usuário/grupo do Sistema. 
O Android também reserva intervalos de AID usados para provisionar UIDs de aplica-
tivos. Versões do Android após o 4.1 adicionaram intervalos adicionais de AID para vá-
rios perfis de usuários e usuários de processos isolados (por exemplo, para o sandboxing 
adicional do Chrome). 
Você pode encontrar definições para AIDs no Sistema/core/include/private/an-
droid_filesystem_config.h, na árvore do Projeto de Código Aberto Android (AOSP). 
Além dos AIDs, o Android usa grupos suplementares para permitir que processos 
acessem recursos compartilhados ou protegidos. Por exemplo, a associação ao grupo 
sdcard_rw permite que um processo leia e grave o diretório/sdcard, já que suas opçõesde montagem restringem quais grupos podem ler e gravar. Isso é semelhante a como 
grupos suplementares são usados em muitas distribuições do Linux. 
Por padrão, os dispositivos Android vem de fábrica com a permissão root (adminis-
trador) desabilitada para o Sistema, pois caso isso ocorresse, alguns usuários sem pre-
paro poderiam realizar ações que os deixassem expostos ou até mesmo que causassem 
dano ou perda de funcionalidade do dispositivo. 
Uma segunda característica técnica está na opção de desenvolvedores, cada disposi-
tivo possui um modo para destravar o modo desenvolvedor que permite a execução de 
aplicações não publicadas na loja oficial.
Existem no Mercado, atualmente, três tipos de aplicativos mobile suportados 
pela Plataforma.
9
UNIDADE 
Ataques em Sistema Operacional Android
Observe na tabela a seguir:
Tabela 1
App Web App Híbrido App Nativo
• São sites responsivos, embarcados em 
webviews, como um janela particular;
• Desenvolvimento e manutenção são 
mais baratos o que faz esse tipo de 
aplicação popular.
• São apps, embarcados em webviews, com 
algumas chamadas de sistema local;
• Desenvolvimento e manutenção são 
mais baratos o que faz esse tipo de 
aplicação popular.
• São aplicados codificadas em linguagem própria 
da plataforma que interagem diretamente com 
o sistema;
• Desenvolvimento e manutenção e manutenção 
deste tipo de app é mais caro porém permite 
maior segurança.
Fonte: //https://www.gsma.com
Máquina Virtual Android
Máquinas virtuais (do inglês, Virtual Machines – VM) são camadas de abstração entre 
a aplicação e as camadas subjacentes do dispositivo Android. 
Ambos os aplicativos Android e o Java API Framework são desenvolvidos na Lin-
guagem de Programação Java e executados na Máquina Virtual da Dalvik (Dalvik VM). 
Essa Máquina Virtual (VM) foi especialmente projetada para fornecer uma camada de 
abstração eficiente ao Sistema operacional subjacente. 
O Dalvik é uma VM baseada em registro que interpreta o formato de código de byte 
do Executável Dalvik (DEX). Por sua vez, o Dalvik depende da funcionalidade fornecida 
por várias Bibliotecas de Código Nativo de suporte. 
Isso ocorre para que o Sistema suporte as diferenças entre os Sistemas Operacionais sem 
que o desenvolvedor tenha a necessidade de escrever aplicativos para dispositivos específicos.
Apesar da maioria das aplicações Android serem desenvolvidas em Java, é possível 
escrevê-las diretamente no Código Nativo. Esse processo é comumente utilizado em 
aplicações de alto desempenho, como jogos.
O uso de qualquer VM, incluindo as do Android, sempre resultará em perda de de-
sempenho, se comparada à mesma funcionalidade implementada em “Código nativo” 
(C, C++ etc.). 
Em termos de segurança, a utilização da VM não sofre com alguns tipos de ataque 
como o Buffer Overflow.
10
11
Modelo de Segurança do Android
De modo geral o Modelo de Segurança do Android detém duas camadas distintas 
de segurança.
A primeira camada é implementada dentro do Sistema Operacional e mantém as 
aplicações instaladas fundamentalmente isoladas uma das outras.
A segunda, é a camada de aplicação dentro da própria aplicação que:
Permite aos desenvolvedores da aplicação expor de forma seletiva as funcionalidades 
para outras aplicações;
Configura os recursos da aplicação alinhado à sua tolerância ao risco.
No Sistema Operacional Android, é definido um ID de Usuário (User ID ou UID), no 
qual é herdado do Sistema Operacional Linux. Esse processo é atribuído automatica-
mente na instalação do aplicativo e define de forma essencial a identificação dele.
Basicamente, assim, como no Linux, a aplicação pode interagir com qualquer arqui-
vo de sua propriedade (mesmo UID), porém não com de outros UIDs, a não ser que seja 
explicitamente compartilhado por outra aplicação ou pelo Sistema Operacional.
Falhas de Segurança Comuns ao Android 
Com a segurança tradicional do aplicativo, há vários problemas que surgem repetida-
mente nos Relatórios de Avaliação de Segurança e vulnerabilidade para dispositivos móveis. 
Os tipos de problema variam de vazamentos de informações confidenciais a vulnera-
bilidades críticas de código ou de execução de comandos. Aplicativos Android não são 
imunes a essas falhas, embora os vetores para alcançar essas falhas possam diferir dos 
aplicativos tradicionais.
Vamos tratar sobre alguns dos problemas de segurança normalmente encontrados 
durante Testes de Segurança de Aplicativos Android e pesquisas públicas. 
Esta certamente não é uma lista detalhada, as Interfaces de Programação de Aplicati-
vos (APIs) do Android evoluem e sofrem alteração sempre considerando a possibilidade 
de personalização da Plataforma entre fabricantes e operadoras. 
11
UNIDADE 
Ataques em Sistema Operacional Android
Questões de Permissão de Aplicativos
Dada à granularidade do modelo de permissão do Android, há uma oportunidade para os 
desenvolvedores solicitarem mais permissões para o aplicativo do que pode ser necessário. 
Esse comportamento pode ser devido a inconsistências na execução e na documenta-
ção de permissão. Embora os documentos de referência do desenvolvedor descrevam a 
maioria dos requisitos de permissão para determinadas classes e métodos, eles não são 
100% completos ou 100% precisos. 
Equipes de Pesquisa tentaram identificar algumas dessas inconsistências de várias 
maneiras. Por exemplo, em 2012, os pesquisadores Andrew Reiter e Zach Lanier tenta-
ram mapear os requisitos de permissão para a API do Android disponível no Android 
Open Source Project (AOSP). 
Entre algumas das descobertas nesse esforço de mapeamento, eles descobriram 
inconsistências entre a documentação e a implementação de alguns métodos na classe 
WiFiManager. Por exemplo, a documentação do desenvolvedor não menciona os 
requisitos de permissão para o método startScan. 
A Figura 5 mostra uma captura de tela da documentação de desenvolvimento do 
Android desse método.
Figura 5 – Defi nição de class, de acordo com o Manual da Linguagem e da Plataforma Android 
Fonte: https://developer.android.com
Transmissão Insegura de Dados Sensíveis
A ideia geral de segurança de transporte (por exemplo, TLS 1.2, 1.3, e assim por 
diante) é, geralmente, bem compreendida. 
12
13
Infelizmente, isso nem sempre se aplica ao mundo dos aplicativos para dispositivos 
móveis. Talvez devido à falta de compreensão sobre como implementar adequadamente 
SSL ou TLS ou apenas a noção incorreta sobre a Rede da Operadora e a segurança 
sobre ela, os desenvolvedores de aplicativos para dispositivos móveis, às vezes, não pro-
tegem os dados confidenciais em trânsito.
Esse problema tende a se manifestar em uma ou mais das seguintes maneiras:
• Criptografia fraca ou falta de criptografia – Em alguns casos não é feita imple-
mentação de conexão HTTPS via TLS devido à confiança colocada no Canal de 
Comunicação e, pelo mesmo motivo, muitas vezes, o Certificado de Validação TLS 
aceita cifras fracas como RC4, SHA1, DES etc.;
• Criptografia forte, mas falta de atenção para avisos de segurança ou certificado de 
erros de validação – Cada Plataforma de desenvolvimento possui em seu guia a ma-
neira correta de implementar validação sobre chaves e certificados; porém poucas 
pessoas costumam ler ou consultar esses manuais buscando temas de segurança. 
Então, o desconhecimento é um dos maiores fatores para que avisos e validações 
de segurança sejam implementadas incorretamente. Não é boa prática, por exem-
plo, que falhas de segurança retornem ao cliente qualquer detalhe sobre o que está 
ocorrendo, e muito menos que esta resposta contenha tags que de alguma forma 
direcionam os próximos passos em caso de erro;
• Uso de texto simples após falhas – Tentativas de conexão com certificados inválidos 
ou chaves fracas devem ser tratados vez após vez, independentemente da quanti-
dade de tentativas. Quando esta validação não é implementada corretamente, após 
algumas tentativas é possível realizar interceptação em texto claro decorrenteda 
desativação do recurso de criptografia após inúmeras falhas;
• Uso inconsistente da segurança de transporte por tipo de Rede (por exemplo, ce-
lular versus Wi-Fi) – Descobrir problemas de transmissão inseguros pode ser tão 
simples quanto capturar o tráfego enviado do dispositivo de destino. Existem nu-
merosas ferramentas man-in-the-middle e tutoriais para facilitar essa tarefa. Num 
piscar de olhos, o emulador do Android suporta tanto o proxy do tráfego quanto o 
tráfego para um rastreamento de pacote no formato PCAP. Você pode conseguir 
isso passando as opções -http-proxy ou -tcpdump, respectivamente.
Armazenamento de Dados Inseguro
O Android oferece vários recursos padrão para o armazenamento de dados, ou seja, 
preferências compartilhadas, Bancos de Dados SQLite e arquivos antigos simples. 
Além disso, cada um desses tipos de armazenamento pode ser criado e acessado 
de várias maneiras, incluindo Códigos gerenciados e nativos, ou por meio de interfaces 
estruturadas, como provedores de conteúdo. Os erros mais comuns incluem armazena-
mento de dados confidenciais de texto sem formatação, provedores de conteúdo despro-
tegidos e permissões de arquivo inseguras.
13
UNIDADE 
Ataques em Sistema Operacional Android
Um exemplo de armazenamento de texto puro e permissões de arquivo inseguras é o 
cliente Skype para Android, que foi encontrado com esses problemas em abril de 2011. 
Reportado por Justin Case (jcase) via http://AndroidPolice.com, o aplicativo Skype 
criou inúmeras arquivos, como Bancos de Dados SQLite e arquivos XML, com permis-
sões que podem ser lidas pelo mundo e graváveis pelo mundo. 
Além disso, o conteúdo não foi criptografado e incluiu Dados de Configuração e 
registros de IM. 
A imagem a seguir mostra o diretório de dados do aplicativo Skype do jcase, bem 
como o conteúdo parcial do arquivo.
# ls -l /data/data/com.skype.merlin_mecha/files/jcaseap 
-rw-rw-rw- app_152 app_152 331776 2011-04-13 00:08 main.db 
-rw-rw-rw- app_152 app_152 119528 2011-04-13 00:08 main.db-journal 
-rw-rw-rw- app_152 app_152 40960 2011-04-11 14:05 keyval.db 
-rw-rw-rw- app_152 app_152 3522 2011-04-12 23:39 config.xml drwxrwxrwx app_152 app_152 2011-04-11 
14:05 voicemail 
-rw-rw-rw- app_152 app_152 0 2011-04-11 14:05 config.lck 
-rw-rw-rw- app_152 app_152 61440 2011-04-13 00:08 bistats.db drwxrwxrwx app_152 app_152 2011-04-12 
21:49 chatsync 
-rw-rw-rw- app_152 app_152 12824 2011-04-11 14:05 keyval.db-journal 
-rw-rw-rw- app_152 app_152 33344 2011-04-13 00:08 bistats.db-journal 
# grep Default /data/data/com.skype.merlin_mecha/files/shared.xml 
 <Default>jcaseap</Default> 
Figura 6 – Diretório de dados do aplicativo Skype do jcase
Fonte: Drake et al., 2017 
As permissões de arquivo inseguras foram o resultado de um problema anterior, me-
nos divulgado, com a criação de arquivos nativos no Android. 
O Banco de Dados SQLite, arquivos de Preferências Compartilhadas e arquivos sim-
ples criados por meio de interfaces Java usaram um modo de arquivo de 0660. 
Isso tornou as permissões de arquivo de leitura/gravação para o ID do usuário e o ID 
do grupo proprietários. No entanto, quando qualquer arquivo foi criado por meio de Có-
digo Nativo ou por comandos externos, o processo do aplicativo herdou permissões de 
seu processo pai, Zygote – uma máscara de 000, que significa leitura/gravação global. 
O cliente Skype usou Código Nativo para grande parte de sua funcionalidade, in-
cluindo a criação e a interação com esses arquivos.
Vazamento de Informações Através de Logs
O recurso de registro do Android é uma ótima fonte de vazamentos de informações. 
Por meio do uso gratuito de métodos de registro pelos desenvolvedores, geralmente 
para fins de depuração, os aplicativos podem registrar qualquer coisa, desde mensagens 
gerais de diagnóstico até credenciais de login ou outros dados confidenciais. 
Mesmo os processos do Sistema, como o ActivityManager, registram mensagens 
bastante detalhadas sobre a chamada de atividade. Aplicativos com a permissão READ_
LOGS podem obter acesso a essas mensagens de log (por meio do comando logcat).
14
15
Como um exemplo de exposição de registro do ActivityManager, considere o seguin-
te trecho:
I/ActivityManager(13738): START {act=android.intent.action.VIEW 
dat=http://www.wiley.com/ 
cmp=com.google.android.browser/com.android.browser.BrowserActivity 
(has extras) u=0} from pid 11352 
I/ActivityManager(13738): Start proc com.google.android.browser for 
activity com.google.android.browser/com.android.browser.BrowserActivity: pid=11433 uid=10017 gids={3003, 1015, 1028} 
Figura 7 – Diretório de Dados do Aplicativo Skype do jcase
Fonte: Drake et al., 2017 
Quando você vê o navegador de ações sendo chamado, talvez por meio do usuário 
tocando em um link em uma mensagem de e-mail ou SMS, os detalhes da chamada 
sendo passada são claramente visíveis e incluem a URL (http://www.wiley.com/) que o 
usuário está visitando. 
Embora esse exemplo trivial possa não parecer uma questão importante, nessas 
circunstâncias, ele apresenta uma oportunidade de coletar algumas informações sobre a 
atividade de navegação na Web de um usuário.
Um exemplo mais convincente de logging excessivo foi encontrado no navegador 
Firefox para Android. 
Neil Bergman relatou esse problema no rastreador de bugs do Mozilla, em dezembro 
de 2012. 
O Firefox no Android registrou atividade de navegação, incluindo URLs que foram 
visitadas. Em alguns casos, isso incluía identificadores de sessão, como Neil apontou em 
sua entrada de bug e saída associada do comando logcat:
I/GeckoBrowserApp(17773): Favicon successfully loaded for URL = 
https://mobile.walmart.com/m/pharmacy;jsessionid=83CB330691854B071CD172D41DC2C3 AB 
I/GeckoBrowserApp(17773): Favicon is for current URL = 
https://mobile.walmart.com/m/pharmacy;jsessionid=83CB330691854B071CD172D41DC2C3 
AB 
E/GeckoConsole(17773): [JavaScript Warning: "Error in parsing value for 
 'background'. Declaration dropped." {file: 
"https://mobile.walmart.com/m/pharmacy;jsessionid=83CB330691854B071CD172D41DC2C 
3AB?wicket:bookmarkablePage=:com.wm.mobile.web.rx.privacy.PrivacyPractices" line: 0}] 
Figura 8 – Diretório de dados do aplicativo Firefox do Neil Bergman
Fonte: Drake et al., 2017 
Tática s em Ambiente Mobile
Ataques para dispositivos móveis ocorrem em diversos cenários possíveis. 
O primeiro ponto a ser compreendido é o objetivo do ataque. Em muitas situações, o 
objetivo pode ser ganhar acesso a um dispositivo específico, ao hardware em si ou a um 
público de aplicativo específico. Essa definição nos ajuda a traçar a estratégia de ataque. 
15
UNIDADE 
Ataques em Sistema Operacional Android
Como vimos, a Plataforma possui algumas camadas e cada uma delas pode oferecer 
portas de entrada para ataques, desde falhas no chip de processamento até personaliza-
ções de distribuidoras que podem oferecer risco.
Vamos ver alguns exemplos de tópicos principais do guia MITRE ATT&CK para 
mobile, considerando a Plataforma Android com alvo.
Acesso Inicial
A tática de acesso inicial representa os vetores que os atacantes usam para ganhar 
uma posição inicial em um dispositivo móvel.
Tabela 2
Nome Descrição
Upload de Aplicativo Malicioso 
via App Store autorizada
Os dispositivos móveis, geralmente, são configurados para permitir a instalação 
de aplicativos somente em uma loja de aplicativos autorizada (por exemplo, 
Google Play Store ou Apple App Store).  Um atacante pode tentar colocar um 
aplicativo malicioso em uma Loja de Aplicativos autorizada, permitindo que o 
aplicativo seja instalado em dispositivos de destino.
Upload aplicativos maliciosos 
por outros meios
Aplicativos maliciosos são um vetor de ataque comum usado pelos atacantes 
para ganhar presença em dispositivos móveis. Essa técnica descreve a instalação 
de um aplicativo mal-intencionado em dispositivos móveis segmentados sem 
envolver uma loja de aplicativos autorizada (por exemplo, Google Play Storeou 
Apple App Store). 
Compromisso de passagem
Com essa técnica, o navegador da Web do usuário é direcionado para exploração. Por 
exemplo, um site pode conter conteúdo de mídia mal-intencionado, destinado a 
explorar vulnerabilidades em analisadores de mídia, conforme demonstrado pela 
vulnerabilidade do Android Stagefright.
Explorar via estação de 
carregamento ou PC
Se o dispositivo móvel estiver conectado (normalmente via USB) a uma 
estação de carregamento ou a um PC, por exemplo, para carregar a bateria do 
dispositivo, uma estação de carregamento comprometida ou mal-intencionada 
ou um PC poderá tentar explorar o dispositivo móvel por meio da conexão.
Explorar através de interfaces 
de rádio
O dispositivo móvel pode ser alvo de exploração através da sua interface para 
Redes celulares ou outras interfaces de rádio.
Instalar configuração insegura 
ou maliciosa
Um atacante pode tentar instalar configurações inseguras ou mal-intencionadas 
no dispositivo móvel, por meio de e-mails de phishing ou mensagens de 
texto, contendo diretamente as definições de configuração como um anexo 
ou contendo um link da Web para as definições de configuração.  O usuário do 
dispositivo pode ser induzido a instalar as configurações por meio de Técnicas 
de Engenharia Social.
Bypass Lockscreen Um atacante com acesso físico a um dispositivo móvel pode tentar ignorar a tela de bloqueio do dispositivo, utilizando recursos físicos ou lógicos. 
Aplicativo clonado 
Um atacante pode baixar um aplicativo legítimo, desmontá-lo, adicionar código 
malicioso e, em seguida, remontá-lo. O aplicativo parece ser o aplicativo original, 
mas contém funcionalidades maliciosas adicionais. O atacante poderia publicar 
esse aplicativo em lojas de aplicativos ou usar outra técnica de entrega.
16
17
Nome Descrição
Compromisso da cadeia
de suprimentos
O comprometimento da cadeia de fornecimento é a manipulação de produtos ou 
mecanismos de entrega de produtos antes do recebimento por um consumidor 
final para fins de comprometimento de dados ou Sistema.  Algo relacionado, os 
atacantes também podem identificar e explorar vulnerabilidades inadvertidamente 
presentes.  Em muitos casos, pode ser difícil ter certeza se a funcionalidade 
explorável é devida à intenção maliciosa ou simplesmente erro inadvertido.
Persistência 
Persistência é qualquer alteração de acesso, ação ou configuração em um dispositivo 
móvel que fornece ao atacante uma presença persistente no dispositivo. 
Os invasores, geralmente, precisarão manter o acesso a dispositivos móveis por meio de 
interrupções, como reinicializações de dispositivos e até redefinições de dados de fábrica.
Tabela 3
Nome Descrição
Autorize o acesso do 
administrador do dispositivo
para impedir a remoção
Um aplicativo mal-intencionado pode solicitar privilégios de administrador do 
dispositivo.  Se o usuário conceder os privilégios, o aplicativo poderá executar 
etapas para tornar sua remoção mais difícil.
App Auto-Start na inicialização
 do dispositivo
Um aplicativo Android pode ouvir a transmissão BOOT_COMPLETED, garantindo que 
a funcionalidade do aplicativo seja ativada toda vez que o dispositivo for iniciado, 
sem precisar esperar que o usuário do dispositivo inicie manualmente o aplicativo.
Modifique o códig
 executável em cache
O ART (o Android Runtime) compila código otimizado no próprio dispositivo para 
melhorar o desempenho. Se um atacante puder escalar privilégios, ele poderá usar 
esses privilégios para modificar o código em cache a fim de ocultar o comportamento 
mal-intencionado. Como o código é compilado no dispositivo, ele pode não receber 
o mesmo nível de verificações de integridade fornecidas ao código em execução na 
partição do Sistema.
Modifique o Kernel do SO ou
 a Partição de Inicialização
Se um atacante puder escalar privilégios, ele poderá usar esses privilégios 
para colocar código mal-intencionado no kernel do dispositivo ou em outros 
componentes de partição de inicialização, em que o código pode escapar da 
detecção, persistir após a Redefinição do dispositivo e não ser removível pelo 
usuário do dispositivo. Em alguns casos, o ataque pode ser detectado, mas pode 
resultar no posicionamento do dispositivo em um estado que não permite mais 
determinadas funcionalidades.
Modifique a partição do Sistema
Se um atacante puder escalar privilégios, ele poderá usar esses privilégios para 
inserir um código mal-intencionado na partição do Sistema do dispositivo, em 
que ele poderá persistir após as redefinições do dispositivo e não ser facilmente 
removido pelo usuário do dispositivo.
Modifique o ambiente
 de execução confiável
Se um atacante puder escalar privilégios, ele poderá usar esses privilégios para 
inserir um código mal-intencionado no Trusted Execution Environment 
(TEE) do dispositivo ou em outro ambiente de execução isolado, no qual o 
código pode escapar da detecção, persistir após redefinições do dispositivo e não 
ser removível pelo usuário do dispositivo.  Executar código dentro do TEE pode 
fornecer a um atacante a capacidade de monitorar ou adulterar o comportamento 
geral do dispositivo.
17
UNIDADE 
Ataques em Sistema Operacional Android
Escalação de Privilégios
A escalação de privilégios inclui técnicas que permitem que um invasor obtenha um 
nível mais alto de permissões no dispositivo móvel. 
Os invasores podem entrar no dispositivo móvel com privilégios muito limitados e 
podem ser obrigados a aproveitar a fraqueza de um dispositivo para obter os privilégios 
mais altos necessários para realizar com êxito seus objetivos de missão.
Tabela 4
Nome Descrição
Vulnerabilidade de
exploração do SO
Um aplicativo mal-intencionado pode explorar vulnerabilidades não corrigidas no 
Sistema Operacional para obter privilégios escalonados.
Exploit Vulnerabilidade TEE
Um aplicativo mal-intencionado ou outro vetor de ataque pode ser usado para explorar 
vulnerabilidades no código em execução no Trusted Execution Environment (TEE).  O 
atacante poderia, então, obter privilégios mantidos pelo TEE, potencialmente incluindo 
a capacidade de acessar chaves criptográficas ou outros dados sensíveis.  Privilégios 
escalados do Sistema Operacional podem ser primeiro requeridos para ter a capacidade de 
atacar o TEE. Se não, os privilégios dentro do TEE podem potencialmente ser usados para 
explorar o Sistema operacional.
Movimentação Lateral 
Movimentação lateral consiste em técnicas que permitem a um atacante acessar e 
controlar Sistemas Remotos em uma Rede e podem, mas não necessariamente, incluir 
a execução de ferramentas em Sistemas Remotos. 
Tabela 5
Nome Descrição
Ataque PC via conexão USB
Com privilégios escalados, um atacante pode programar o dispositivo móvel 
para representar dispositivos USB, como dispositivos de entrada (teclado e 
mouse), dispositivos de armazenamento e/ou dispositivos de Rede, a fim de 
atacar um PC fisicamente conectado. Wang e Stavrou e Kamkar descrevem essa 
técnica. Essa técnica foi demonstrada no Android e não temos conhecimento de 
nenhuma demonstração no iOS.
Explorar Recursos Da Empresa
Atacantes podem tentar explorar servidores corporativos, estações de 
trabalho ou outros recursos na Rede. Essa técnica pode aproveitar o acesso do 
dispositivo móvel a uma Rede Corporativa Interna por meio de conectividade 
local ou por meio de uma Rede Privada Virtual (VPN).
Efeitos
Os efeitos consistem em Técnicas usadas pelo atacante para executar seus objetivos 
de missão, mas que não se encaixam perfeitamente em outra categoria, como Coleção.
Os objetivos da missão variam de acordo com os objetivos de cada atacante, mas os 
exemplos incluem fraude de tarifação, destruição de dados do dispositivo ou bloqueio do 
usuário fora de seu dispositivo, até que um resgate seja pago.
18
19
Tabela 6
Nome Descrição
Criptografar arquivos para resgate
Um atacante pode criptografar arquivos armazenados no dispositivo móvel para impedir 
que o usuário os acesse, apenas desbloqueando o acessoaos arquivos após o pagamento 
de um resgate. Sem privilégios escalados, o atacante é geralmente limitado a somente 
criptografar arquivos em locais de armazenamento externos/compartilhados.  Essa 
técnica foi demonstrada no Android e não temos conhecimento de nenhum uso 
demonstrado no iOS.
Gerar receita de publicidade 
fraudulenta
Um atacante poderia tentar gerar receita de publicidade fraudulenta a partir 
de dispositivos móveis, por exemplo, acionando cliques automáticos de links de 
publicidade sem o envolvimento do usuário.
Bloquear usuário fora do dispositivo Um atacante pode tentar bloquear o usuário legítimo fora do dispositivo, por exemplo, até que um resgate seja pago.
Manipular classificações ou 
classificações da App Store
Um atacante pode usar o acesso às credenciais de um dispositivo comprometido para 
tentar manipular classificações ou classificações de lojas de aplicativos acionando 
downloads de aplicativos ou postando avaliações falsas de aplicativos. Essa técnica, 
provavelmente, requer acesso privilegiado (um dispositivo com root).
Fraude de tarifação Premium SMS
Um aplicativo malicioso pode usar APIs padrão do Android para enviar mensagens 
SMS.  Mensagens SMS podem potencialmente ser enviadas para números premium 
que cobram o proprietário do dispositivo e geram receita para um atacante.
Limpar dados do dispositivo
Um aplicativo malicioso pode abusar do acesso de administrador do dispositivo 
Android para limpar o conteúdo do dispositivo, por exemplo, se um resgate não 
for pago.
Efeitos – Rede 
No ambiente móvel, os dispositivos móveis são frequentemente conectados à Redes 
fora do controle corporativo, como Redes celulares ou Redes Wi-Fi públicas. 
Os atacantes podem tentar evitar a detecção comunicando-se nessas Redes e, po-
tencialmente, até usando mecanismos que não sejam do Protocolo da Internet, como o 
Serviço de Mensagens Curtas (SMS). 
No entanto, as Redes Celulares, geralmente, têm limites de dados e/ou taxas de dados 
extras que podem aumentar o potencial de detecção de comunicação adversária.
Tabela 7
Nome Descrição
Downgrade para Protocolos
não seguros
Um atacante pode fazer com que o dispositivo móvel use Protocolos menos 
seguros, por exemplo, ao interferir nas frequências usadas por Protocolos 
mais novos, como o LTE, e permitir que Protocolos mais antigos, como o GSM, 
comuniquem-se conforme descrito no NIST SP 800-187.  O uso de Protocolos 
menos seguros pode tornar a comunicação mais fácil de escutar ou manipular.
Escutas na Comunicação
de Rede Insegura
Se o tráfego de Rede entre o dispositivo móvel e os servidores remotos não 
estiver criptografado ou estiver criptografado de maneira insegura, um atacante 
posicionado na Rede poderá escutar a comunicação.
19
UNIDADE 
Ataques em Sistema Operacional Android
Nome Descrição
Explorar SS7 para redirecionar 
chamadas telefônicas/SMS
Um atacante pode explorar as vulnerabilidades do Sistema de sinalização para 
redirecionar chamadas ou mensagens de texto para um número de telefone sob 
o controle do invasor. O atacante poderia, então, agir como um homem no meio 
para interceptar ou manipular a comunicação.
Explorar o SS7 para rastrear o local 
do dispositivo
Um atacante pode explorar as vulnerabilidades do Sistema de sinalização para 
rastrear a localização de dispositivos móveis.
Bloqueio ou negação de serviço Um invasor pode interceptar sinais de rádio (por exemplo, Wi-Fi, celular, GPS) para impedir que o dispositivo móvel se comunique.
Manipular a comunicação
do dispositivo
Se o tráfego de Rede entre o dispositivo móvel e um servidor remoto não estiver 
protegido com segurança, um invasor posicionado na Rede poderá manipular 
a comunicação da Rede sem ser detectado.  Por exemplo, os pesquisadores 
da FireEye descobriram, em 2014, que 68% dos 1.000 principais aplicativos 
gratuitos da Google Play Store tinham pelo menos uma vulnerabilidade de 
implementação de TLS (Transport Layer Security), potencialmente abrindo o 
tráfego de Rede dos aplicativos para ataques man-in-the-middle.
Estação base celular desonesta
Um atacante poderia montar uma estação base de celulares e usá-la para 
espionar ou manipular a comunicação de dispositivos celulares.  Por exemplo, 
Ritter e DePerry, da iSEC Partners, demonstraram essa técnica usando uma 
femtocell comprometida na Black Hat USA 2013.
Pontos de acesso Wi-Fi desonestos
Um atacante pode configurar pontos de acesso Wi-Fi não autorizados ou comprometer 
pontos de acesso existentes e, se o dispositivo se conectar a eles, realizar ataques 
baseados em Rede, como interceptar ou modificar a comunicação da Rede, conforme 
descrito no NIST SP 800-153.
Troca de cartão SIM
Um atacante pode convencer a operadora de Rede Móvel (por exemplo, por 
meio de Redes Sociais, identificação forjada ou ataques internos realizados 
por funcionários confiáveis) a emitir um novo cartão SIM e associá-lo a um 
número de telefone e conta existentes.  O atacante poderia, então, obter 
mensagens SMS ou sequestrar telefonemas destinados a outra pessoa.
Ataques
Ferramentas Importantes 
Algumas ferramentas utilizadas para inter-
ceptação podem ser instaladas no Computador 
usado para o ataque e outras são instaladas nos 
dispositivos móveis. 
A seguir, estão listadas as principais:
• Burp Suite;
• Terminal SSH (Putty);
• Drozer;
• Android Studio.
Figura 9 - Drozer App
Fonte: mobiletools.mwrinfosecurity.com
20
21
Bypass Reconhecimento de Digital 
Ataques desse tipo podem ser realizados considerando como alvo potencial as OEMs, 
as fabricantes e as distribuidoras dos dispositivos.
O kit de ferramentas de remoção de tela de bloqueio do Android oferece suporte ao 
dispositivo Samsung e LG, para evitar o bloqueio de impressões digitais sem perder dados. 
Também pode remover os outros tipos de bloqueio, PIN, senha e padrão com 
poucos cliques. 
Operações fáceis e eficazes são mostradas nas etapas a seguir. 
Figura 10 – Aplicativo que auxilia no processo de by-pass de login
Fonte: Reprodução
Figura 11 – Aplicativo que auxilia no processo de by-pass de login
Fonte: Reprodução
21
UNIDADE 
Ataques em Sistema Operacional Android
O kit de ferramentas baixará e instalará o pacote de recuperação para o seu dispositivo 
automaticamente. Basta seguir as instruções do programa, conforme podemos ver a seguir. 
Figura 12 – Aplicativo que auxilia no processo de by-pass de login
Fonte: Reprodução
Após esse procedimento, é importante cadastrar uma nova digital e remover a an-
terior para que não ocorram problemas; caso contrário o processo pode ser revertido.
Interceptação 
O processo de interceptação se baseia no uso de proxy e, basicamente, por meio des-
se recurso, podemos realizar testes internos ou ataques. A disparidade está realmente 
no local de configuração. Podemos configurar o proxy no roteador caso o objetivo seja 
ganhar acesso ou, diretamente, no dispositivo de teste, como podemos ver na Figura 11:
Figura 13
Fonte: Acervo do Conteudista
22
23
Figura 14 – Local de alteração de proxy em dispositivos Android
Fonte: Reprodução
Figura 15 – Burp interceptando aplicação web responsiva
23
UNIDADE 
Ataques em Sistema Operacional Android
Por meio da interceptação, é possível mapear as chamadas realizadas pelo App para o 
servidor, entender o funcionamento de tokens e verificar os dados que estão sendo trafegados. 
Ataque Surface 
Para esse ataque, iremos utilizar o Drozer como ferramenta auxiliar, simulando ação 
de um aplicativo terceiro malicioso. 
O Drozer deve ser instalado no dispositivo móvel alvo utilizando a técnica de acesso 
inicial, para aplicativos não autorizados. Para realizar o controle das operações, deve-se 
instalar a versão console também no Computador origem. 
Após feita a instalação: 
O primeiro passo a ser feito é identificar o pacote alvo: 
dz> run app.package.list -f nome_principal_do_pacote 
>com.mwr.example.sieve
Depois de identificar o pacote, podemos verificar algumas informações sobre ele:
dz> run app.package.attacksurfacecom.mwr.example.sieve 
 
> Attack Surface: 
 3 activities exported 
 0 broadcast receivers exported 
 2 content providers exported 
 2 services exported 
 is debuggable 
Figura 16
Fonte: Acervo do Conteudista
Isso nos mostra que temos vários vetores em potencial. O aplicativo exporta várias 
atividades de telas usadas pelo aplicativo, objetos de banco de dados e serviços trabalha-
dos em segundo plano. 
Também observamos que o serviço é debuggable, o que significa que podemos ane-
xar um depurador ao processo, usando adb e percorrer o Código.
Podemos aprofundar essa superfície de ataque usando alguns comandos mais específicos. 
Por exemplo, podemos perguntar quais atividades são exportadas pelo Sieve:
dz> run app.activity.info -a com.mwr.example.sieve 
Package: com.mwr.example.sieve 
 com.mwr.example.sieve.FileSelectActivity 
 com.mwr.example.sieve.MainLoginActivity 
 com.mwr.example.sieve.PWList 
Figura 17
Fonte: Acervo do Conteudista
Nesse caso, o retorno esperado seriam apenas as telas de inicialização como login 
ou splash de carregamento. 
24
25
Atividades como PWlist não são esperadas e não requerem permissão. Podemos 
pedir ao Drozer para lançá-la:
dz> run app.activity.start --component com.mwr.example.sieve 
com.mwr.example.sieve.PWList 
Figura 18
Fonte: Acervo do Conteudista
Esse comando irá iniciar uma intent apropriada em segundo plano e a entrega ao 
Sistema por meio da chamada startActivity. Teremos sucesso no ataque, caso a autori-
zação seja ignorada, e recebemos uma lista das credenciais do usuário.
Roubo de Informações Sensíveis 
Ainda utilizando o Drozer, podemos mapear os provedores de conteúdo exportados 
como vimos anteriormente.:
dz> run app.package.attacksurface com.mwr.example.sieve 
 
> Attack Surface: 
 3 activities exported 
 0 broadcast receivers exported 
 2 content providers exported 
 2 services exported 
 is debuggable 
dz> run scanner.provider.finduris -a com.mwr.example.sieve 
Scanning com.mwr.example.sieve... 
Unable to Query content://com.mwr. 
example.sieve.DBContentProvider/ 
... 
Unable to Query content://com.mwr.example.sieve.DBContentProvider/Keys 
Accessible content URIs: 
content://com.mwr.example.sieve.DBContentProvider/Keys/ 
content://com.mwr.example.sieve.DBContentProvider/Passwords 
content://com.mwr.example.sieve.DBContentProvider/Passwords/ 
Figura 19
Fonte: Acervo do Conteudista
Após identificar os provedores, podemos utilizar o seguinte comando para ler as 
informações armazenadas nestes provedores, podendo conseguir as credenciais do usu-
ário logado ou histórico. 
dz> run app.provider.query 
content://com.mwr.example.sieve.DBContentProvider/Passwords/ --vertical 
_id: 1 
service: Email 
username: incognitoguy50 
password: PSFjqXIMVa5NJFudgDuuLVgJYFD+8w== (Base64 
- 
encoded) 
email: incognitoguy50@gmail.com 
Figura 20
Fonte: Acervo do Conteudista
25
UNIDADE 
Ataques em Sistema Operacional Android
Clonagem de APP
O Processo de Clonagem de App envolve conseguir acesso ao APK e acessar o 
Código da Aplicação. 
Caso o código esteja legível, é possível alterá-lo e obter privilégios ou informações 
privilegiadas, devido à possibilidade de falsificação do App original. 
Para nos auxiliar na obtenção do arquivo APK, temos alguns sites, como o https://apps.
evozi.com, ou também podemos capturar o arquivo via SSH no diretório da aplicação. 
Figura 21 – Site que permite download direto do APK
Fonte: Reprodução
Após a obtenção do arquivo .apk, podemos abri-lo usando aplicativos de descompac-
tação e capturar o arquivo dex, enviando para o dex2jar realizar a abertura do código 
para arquivo jar.
Figura 22 – Aplicativo dex2jar, efetuando conversão de arquivo .dex para .jar
Fonte: https://apps.evozi.com
26
27
Após a alteração da extensão de dex > jar, basta abrir o arquivo em um compilador 
java, como o eclipse ou JDGUI, e realizar as alterações ou avaliações necessárias. 
Para realizar a recompilação e gerar um APK falsificado, deve-se obter apktool e 
seguir os comandos:
apktool b -f -d nome-do-aplicativo
Para que seja possível instalar o App, deve-se assiná-lo n ovamente:
java -jar SignApk.jar testkey.x509.pem testkey.pk8 nome-do-aplicativo.apk nome-do-
aplicativo_signed.apk 
Após esse processo, será gerado arquivo .apk no diretório em que estão sendo trata-
dos arquivos; basta instalar ou distribuir na Loja.
Clonagem de Dispositivo
O processo de Clonagem de Dispositivos, basicamente, envolve a restauração de backups 
de dispositivos específicos. 
No caso de um alvo, muitas aplicações permitem que sejam restauradas ou arma-
zenadas em backup, sem necessidade de vincular à conta Google. Essa configuração 
pode permitir ganhar acesso à aplicação e aos dados armazenados no dispositivo, como 
usuários e senha. 
O processo de clonagem envolve capturar o arquivo de backup, que pode estar em 
outro vetor, como computador da vítima, e restauração ou cópia direta para o dispositivo 
mobile utilizado como base.
Figura 23 – Ilustração sobre local de alteração de proxy no dispositivo
27
UNIDADE 
Ataques em Sistema Operacional Android
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Web Aplication hackers handbook – Finding and Exploiting Security Flaws
STUTTARD, D; PINTO, M. Web Aplication Hackers Handbook – Finding and 
Exploiting Security Flaws. 2.ed. Hoboken: Wiley Publishing, 2011; 
 Leitura
Curso GIAC SEC575
https://bit.ly/2ZI5BPH
Top 10 2013/ProjectMethodology
https://bit.ly/2vuQI5s
OWASP Mobile Security Project
https://bit.ly/1FAIJiv
MITRE ATT&CK
https://bit.ly/2vtTMyw
Fingerprints On Mobile Devices: Abusing and Leaking
https://ubm.io/2ielAyR
28
29
Referências
CHELL, D. et al. The Mobile Application Hacker‘s Handbook. Nova York: John 
Wiley & Sons Inc, 2015.
CVE-2018-0591. [S. l.], 2018. Disponível em: https://www.talosintelligence.com/vul-
nerability_reports/TALOS-2018-0591. Acesso em: 20 fev. 2019.
DEVELOPER Guide Android. [S. l.], 2019. Disponível em: https://developer.android.
com/docs. Acesso em: 20 fev. 2019.
DRAKE, J. et al. Android Hacker‘s Handbook. Canada: John Wiley & Sons Inc, 
2014. (E-book).
ELENKOV, N. Android Security Internals: An In-Depth Guide to Android‘s Security 
Architecture. EUA: No Starch Press, 2014. (E-book).
GRÁFICOS sobre pesquisas. [S. l.], 2019. Disponível em: https://web.archive.org/
web/20140816052125/http://www.statista.com/. Acesso em: 20 fev. 2019.
MILLER, C. et al. IOS Hacker’s Handbook. Nova York: John Wiley & Sons Inc, 2012.
MITRE ATT&CK. [S. l.], 2019. Disponível em: https://attack.mitre.org/tactics/mobile/. 
Acesso em: 20 fev. 2019.
29