AtaquesTítulo

Inserir e Defesa
Aqui para
Inserir Título Móveis
Dispositivos Aqui
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
 Ataques em Sistema Operacional Android

Fonte: Getty Images

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.

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!
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 Figura 1 – Andy Ruby, um dos pais do Android
Telecomunicações, com a intenção acelerar sua Fonte: Getty Images

entrada no Mercado móvel.

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
 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
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
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ções
de 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
9
UNIDADE
Ataques em Sistema Operacional Android

Observe na tabela a seguir:

Tabela 1
App Web App Híbrido App Nativo
• São aplicados codificadas em linguagem própria
• São sites responsivos, embarcados em • São apps, embarcados em webviews, com
da plataforma que interagem diretamente com
webviews, como um janela particular; algumas chamadas de sistema local;
o sistema;
• Desenvolvimento e manutenção são • Desenvolvimento e manutenção são
• Desenvolvimento e manutenção e manutenção
mais baratos o que faz esse tipo de mais baratos o que faz esse tipo de
deste tipo de app é mais caro porém permite
aplicação popular. aplicação popular.
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
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
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 – Definiçã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
 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 decorrente da
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
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
 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áticas 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
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

Os dispositivos móveis, geralmente, são configurados para permitir a instalação

de aplicativos somente em uma loja de aplicativos autorizada (por exemplo,
Upload de Aplicativo Malicioso
Google Play Store ou Apple App Store). Um atacante pode tentar colocar um
via App Store autorizada
aplicativo malicioso em uma Loja de Aplicativos autorizada, permitindo que o
aplicativo seja instalado em dispositivos de destino.

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
Upload aplicativos maliciosos
de um aplicativo mal-intencionado em dispositivos móveis segmentados sem
por outros meios
envolver uma loja de aplicativos autorizada (por exemplo, Google Play Store ou
Apple App Store).

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
Compromisso de passagem
explorar vulnerabilidades em analisadores de mídia, conforme demonstrado pela
vulnerabilidade do Android Stagefright.

Se o dispositivo móvel estiver conectado (normalmente via USB) a uma

Explorar via estação de estação de carregamento ou a um PC, por exemplo, para carregar a bateria do
carregamento ou PC 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 O dispositivo móvel pode ser alvo de exploração através da sua interface para
de rádio Redes celulares ou outras interfaces de rádio.

Um atacante pode tentar instalar configurações inseguras ou mal-intencionadas

Instalar configuração insegura
ou maliciosa
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.

Um atacante com acesso físico a um dispositivo móvel pode tentar ignorar a tela
Bypass Lockscreen
de bloqueio do dispositivo, utilizando recursos físicos ou lógicos.

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,
Aplicativo clonado
mas contém funcionalidades maliciosas adicionais. O atacante poderia publicar
esse aplicativo em lojas de aplicativos ou usar outra técnica de entrega.

16
 Nome
Compromisso da cadeia
de suprimentos
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.
Nome
Autorize o acesso do
administrador do dispositivo
para impedir a remoção
App Auto-Start na inicialização
do dispositivo
Modifique o códig
executável em cache
Modifique o Kernel do SO ou
a Partição de Inicialização
Modifique a partição do Sistema
Modifique o ambiente
de execução confiável
Descrição
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.
Tabela 3
Descriçã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.
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.
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.
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.
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.
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
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 Um aplicativo mal-intencionado pode explorar vulnerabilidades não corrigidas no

exploração do SO 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
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
Ataque PC via conexão USB
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.
Atacantes podem tentar explorar servidores corporativos, estações de
trabalho ou outros recursos na Rede. Essa técnica pode aproveitar o acesso do
Explorar Recursos Da Empresa
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
 Tabela 6
Nome Descrição
Um atacante pode criptografar arquivos armazenados no dispositivo móvel para impedir
que o usuário os acesse, apenas desbloqueando o acesso aos arquivos após o pagamento
de um resgate. Sem privilégios escalados, o atacante é geralmente limitado a somente
Criptografar arquivos para resgate
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.
Um atacante poderia tentar gerar receita de publicidade fraudulenta a partir
Gerar receita de publicidade
de dispositivos móveis, por exemplo, acionando cliques automáticos de links de
fraudulenta
publicidade sem o envolvimento do usuário.

Um atacante pode tentar bloquear o usuário legítimo fora do dispositivo, por

Bloquear usuário fora do dispositivo
exemplo, até que um resgate seja pago.

Um atacante pode usar o acesso às credenciais de um dispositivo comprometido para

Manipular classificações ou tentar manipular classificações ou classificações de lojas de aplicativos acionando
classificações da App Store downloads de aplicativos ou postando avaliações falsas de aplicativos. Essa técnica,
provavelmente, requer acesso privilegiado (um dispositivo com root).

Um aplicativo malicioso pode usar APIs padrão do Android para enviar mensagens
Fraude de tarifação Premium SMS SMS. Mensagens SMS podem potencialmente ser enviadas para números premium
que cobram o proprietário do dispositivo e geram receita para um atacante.

Um aplicativo malicioso pode abusar do acesso de administrador do dispositivo

Limpar dados 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
Um atacante pode fazer com que o dispositivo móvel use Protocolos menos
seguros, por exemplo, ao interferir nas frequências usadas por Protocolos
Downgrade para Protocolos
mais novos, como o LTE, e permitir que Protocolos mais antigos, como o GSM,
não seguros
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.

Se o tráfego de Rede entre o dispositivo móvel e os servidores remotos não

Escutas na Comunicação
estiver criptografado ou estiver criptografado de maneira insegura, um atacante
de Rede Insegura
posicionado na Rede poderá escutar a comunicação.

19
19
UNIDADE
Ataques em Sistema Operacional Android
Nome
Explorar SS7 para redirecionar
chamadas telefônicas/SMS
Explorar o SS7 para rastrear o local
do dispositivo
Bloqueio ou negação de serviço
Manipular a comunicação
do dispositivo
Estação base celular desonesta
Pontos de acesso Wi-Fi desonestos
Troca de cartão SIM
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.
20
Descrição
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.
Um atacante pode explorar as vulnerabilidades do Sistema de sinalização para
rastrear a localização de dispositivos móveis.
Um invasor pode interceptar sinais de rádio (por exemplo, Wi-Fi, celular, GPS) para
impedir que o dispositivo móvel se comunique.
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.
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.
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.
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.
Figura 9 - Drozer App
Fonte: mobiletools.mwrinfosecurity.com
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
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
Figura 14 – Local de alteração de proxy em dispositivos Android
Fonte: Reprodução

Figura 15 – Burp interceptando aplicação web responsiva

23
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.attacksurface com.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
 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
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
 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 novamente:

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
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
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
29