5 en PT

Traduzido do Inglês para o Português - www.onlinedoctranslator.
com
68 Capítulo 3-Enraizando seu dispositivo
Depois de desbloquear o carregador de inicialização em alguns dispositivos, você pode inicializar o código
não assinado, mas não pode exibir o código não assinado. Nesse caso, a atualização de um sistema
personalizado ou imagem de recuperação só é possível depois de obter root no sistema inicializado. Nesse
cenário, você usariaddpara gravar uma imagem de recuperação personalizada diretamente no dispositivo de
bloco para a partição de recuperação.
Enraizamento com um carregador de inicialização bloqueado
Quando o carregador de inicialização está bloqueado e o fabricante não fornece um método legítimo
para desbloqueá-lo, geralmente você precisa encontrar uma falha no dispositivo que servirá como
ponto de entrada para fazer o root.
Primeiro você precisa identificar qual tipo de bloqueio do carregador de inicialização você
possui; pode variar dependendo do fabricante, operadora, variante do dispositivo ou versão do
software no mesmo dispositivo. Às vezes, o acesso fastboot é proibido, mas você ainda pode
usar o protocolo de flash proprietário do fabricante, como Motorola SBF ou Samsung ODIN. Às
vezes, as verificações de assinatura no mesmo dispositivo são aplicadas de maneira diferente ao
usar o fastboot em vez do modo de download proprietário do fabricante. A verificação de
assinatura pode acontecer no momento da inicialização, no momento de piscar ou em ambos.
Alguns carregadores de inicialização bloqueados apenas impõem a verificação de assinatura em partições

selecionadas; um exemplo típico é ter partições de inicialização e recuperação bloqueadas. Nesse caso, não é
permitido inicializar um kernel personalizado ou uma imagem de recuperação modificada, mas você ainda
pode modificar a partição do sistema. Nesse cenário, você pode executar o enraizamento editando a partição
do sistema de uma imagem de estoque, conforme descrito na seção “Enraizando com um carregador de
inicialização desbloqueado”.
Em alguns dispositivos, onde a partição de inicialização está bloqueada e a inicialização
de um kernel personalizado é proibida, é possível exibir uma imagem de inicialização
personalizada na partição de recuperação e inicializar o sistema com o kernel
personalizado inicializando no modo de recuperação ao ligar o telefone. Neste caso, é
possível obter acesso root através deshell adbmodificando odefault.proparquivo da imagem
de inicialização personalizada initrd, como você verá na seção “Abusing adbd to Get Root”.
Em alguns dispositivos, a imagem de recuperação de estoque permite aplicar atualizações
assinadas com o Android padrãochave de teste. Essa chave é uma chave genérica para
pacotes que não especificam uma chave. Está incluído noconstruir/alvo/produto/segurança
diretório na árvore de origem do AOSP. Você pode fazer root aplicando um pacote de
atualização personalizado contendo osubinário. Não se sabe se o fabricante deixou isso de
propósito ou não, mas sabe-se que isso funciona em alguns dispositivos Samsung com
Android 4.0 e recuperação de estoque 3e.
Na pior das hipóteses, as restrições do carregador de inicialização não permitirão que você
inicialize com uma partição que falhe na verificação de assinatura. Neste caso, você deve usar
Capítulo 3-Enraizando seu dispositivo 69
outras técnicas para obter acesso root, conforme descrito na seção “Ganhando root em
um sistema inicializado”.
Ganhando root em um sistema inicializado
Obter acesso root inicial em um sistema inicializado consiste em obter um shell de root por
meio de uma falha de segurança não corrigida no sistema operacional Android. Um método de
enraizamento como esse também é amplamente conhecido comoraiz maciaporque o ataque é
quase inteiramente baseado em software. Normalmente, um soft root é realizado por meio de
uma vulnerabilidade no kernel do Android, um processo executado como root, um programa
vulnerável com o bit set-uid definido, um ataque de link simbólico contra um bug de permissão
de arquivo ou outros problemas. Há um grande número de possibilidades devido ao grande
número de áreas em que os problemas podem ser introduzidos e os tipos de erros que os
programadores podem cometer.
Embora os binários root set-uid ou set-gid não sejam comuns no Android, operadoras ou
fabricantes de dispositivos às vezes os introduzem como parte de suas modificações
personalizadas. Uma falha de segurança típica em qualquer um desses binários set-uid pode
levar ao escalonamento de privilégios e, posteriormente, gerar acesso root.
Outro cenário típico é explorar uma vulnerabilidade de segurança em um processo
executado com privilégios de root. Tal exploit permite que você execute código
arbitrário como root. O final deste capítulo inclui alguns exemplos disso.
Como você verá no Capítulo 12, essas explorações estão se tornando mais difíceis de desenvolver à
medida que o Android amadurece. Novas técnicas de mitigação e recursos de proteção de segurança
são introduzidos regularmente com as novas versões do Android.
Abusando do adbd para obter root
É importante compreender que oadbddaemon começará a ser executado como root e descartará seus
privilégios para oConchausuário (AID_SHELL), a menos que a propriedade do sistema
ro.secureestá configurado para0.Esta propriedade é somente leitura e geralmente é definida comoro.secure=1
pela imagem de inicialização initrd.

oadbddaemon também iniciará como root sem perder privilégios para o shell se a propriedade
ro.kernel.qemuestá configurado para1 (para iniciaradbdexecutando como root no emulador do Android),
mas essa também é uma propriedade somente leitura que normalmente não será definida em um
dispositivo real.
As versões do Android anteriores a 4.2 lerão o /data/local.propna inicialização e aplique quaisquer
propriedades definidas neste arquivo. A partir do Android 4.2, este arquivo só será lido em
compilações de não usuário, sero.depurávelestá configurado para1.
O /data/local.proparquivo e oro.secureero.kernel.qemuapropriado-
laços são de importância fundamental para obter acesso root. Lembre-se disso, pois você
verá alguns exploits usando-os na seção “Histórico de ataques conhecidos” mais adiante
neste capítulo.
Bloqueios NAND, Raiz Temporária e Raiz Permanente

Alguns dispositivos HTC têm um sinalizador de segurança (@secuflag)no rádio Non-Volatile Random
Access Memory (NVRAM) que é verificado pelo carregador de inicialização do dispositivo (HBOOT).
Quando este sinalizador é definido como “true”, o carregador de inicialização exibe uma mensagem
“security on” (S-ON) e um bloqueio NAND é aplicado. O bloqueio NAND impede a gravação no sistema,
nas partições de inicialização e de recuperação. Com S-ON, uma reinicialização perde a raiz e as
gravações nessas partições não ficam. Isso impossibilita ROMs de sistema personalizadas, kernels
personalizados e modificações de recuperação personalizadas.
Ainda é possível obter acesso root por meio de uma exploração para uma vulnerabilidade suficientemente
grave. No entanto, o bloqueio NAND faz com que quaisquer alterações sejam perdidas na reinicialização. Isso
é conhecido como umraiz temporáriano Androidmodificaçãocomunidade.
Para alcançar umraiz permanenteem dispositivos HTC com um bloqueio NAND, uma das duas
coisas deve ser feita. Primeiro, você pode desabilitar o sinalizador de segurança na banda base.
Segundo, você no
não enf ty
desligadomensagem
Figura 3-3:HTC HBOOT bloqueado e desbloqueado
Antes da HTC fornecer o procedimento oficial de desbloqueio do carregador de inicialização em agosto de

2011, um HBOOT corrigido era a única solução disponível. Isso pode ser feito em alguns dispositivos por
ferramentas não oficiais de desbloqueio do carregador de inicialização, como AlphaRev (disponibilidade
capaz emhttp://alpharev.nl/)e Não revogado (disponível emhttp://unrevoked
. com/),que mais tarde se fundiu na ferramenta Revolutionary.io (disponível emhttp://revolucionário.io/).
Essas ferramentas geralmente combinam várias explorações públicas ou privadas para poder
atualizar o carregador de inicialização corrigido e ignorar os bloqueios NAND. Na maioria dos casos, a
atualização de um HBOOT de estoque reativa o sinalizador de segurança do dispositivo (S-ON).
Os exploits Unlimited.io disponíveis emhttp://unlimited.io/,como JuopunutBear,
LazyPanda e DirtyRacun, permitem obter S-OFF de rádio completo em
alguns dispositivos combinando vários exploits presentes nas ROMs do Android da HTC e na
banda base do dispositivo.
Em dezembro de 2010, Scott Walker publicou o exploit gfree disponível emhttps://
github.com/tmzt/g2root-kmod/tree/master/scotty2/gfreesob a GPL3
licença. Esta exploração desativou a proteção incorporada do MultiMediaCard (eMMC) do T-
Mobile G2. A memória eMMC, que contém a partição de banda base, é inicializada no modo
somente leitura quando o carregador de inicialização inicializa o hardware. O exploit então liga
e desliga o chip eMMC usando um módulo de kernel Linux e define o @bandeira segurapara falso.
Finalmente, ele instala um filtro de solicitação de bloco MultiMediaCard (MMC) no kernel para
remover a proteção contra gravação na partição oculta de configurações de rádio.
Quando a HTC iniciou seu portal oficial de desbloqueio, forneceu imagens HBOOT para alguns
dispositivos que permitem ao usuário desbloquear o carregador de inicialização - e remover bloqueios
NAND - em duas etapas:
1. Primeiro o usuário deve executar o comandofastboot oem get_identifier_ token. O

carregador de inicialização exibe um blob que o usuário deve enviar ao portal de
desbloqueio da HTC.
2. Após enviar o token identificador, o usuário recebe umCódigo de desbloqueio

. caixaarquivo exclusivo para seu telefone. Este arquivo é assinado com a chave privada da
HTC e deve ser exibido no dispositivo usando o comandoflash de inicialização rápida
unlocktoken Unlock_code.bin.
Se oUnlock_code.binarquivo é válido, o telefone permite usar o padrão

flash de inicialização rápidacomandos para fazer flash de imagens de partição não assinadas.
Além disso, permite inicializar essas imagens de partição não assinadas sem restrições. A Figura
3-4 mostra o fluxo de trabalho geral para desbloquear dispositivos. HTC e Motorola são dois
OEMs que utilizam esse tipo de processo.
Outros dispositivos, como alguns tablets Toshiba, também possuem bloqueios NAND. Para
esses dispositivos, os bloqueios são aplicados pelocal do marMódulo Kernel carregável, que
reside na imagem de inicialização initrd. Este módulo é baseado no SEAndroid e impede a
remontagem da partição do sistema para gravação.
Persistindo uma raiz macia
Quando você tem um shell de root (soft root), obter acesso root permanente é simples.
Em telefones sem bloqueios NAND, você só precisa de acesso de gravação à partição do
sistema. Se o telefone tiver um bloqueio NAND, ele deve ser removido primeiro (consulte a
seção “Bloqueios NAND, raiz temporária e raiz permanente” anteriormente neste
capítulo).
Com os bloqueios NAND fora de cena, você pode simplesmente remontar a partição do
sistema no modo de leitura/gravação, colocar umsubinário com permissões de root set-uid e
remonte-o novamente no modo somente leitura; opcionalmente, você pode instalar umsu
wrapper como SuperUser ou SuperSU.
Carregador de inicialização Desbloquear Portal Carregador de inicialização
Dispositivo bloqueado Desbloqueado
Step1 Passo 2 etapa 3 Passo 4
é o telefone
O usuário obtém O usuário envia o O portal de desbloqueio O usuário desbloqueia o
desbloquear tokenusando desbloquearsímbolotoken para valida o dispositivo usando o
fastboot o portal de desbloqueio OEM símboloe envia desbloqueio fornecidochave
o desbloqueiochave e inicialização rápida
DO UTILIZADOR
Figura 3-4:Fluxo de trabalho geral de desbloqueio do carregador de inicialização
Uma maneira típica de automatizar o processo descrito é executando os seguintes

comandos de um computador host conectado a um dispositivo Android com
depuração USB habilitada:
adb shell mount -o remount,rw /system adb
adb push su /system/xbin/su adb shell chown
0.0 /system/xbin/su adb shell chmod 06755 /
system/xbin/su adb shell mount -o
remount,ro /system adb install Superuser.apk
Outra maneira de manter o acesso root persistente é gravar uma recuperação personalizada
na partição de recuperação usando oddcomando no dispositivo Android. Isso é equivalente a
exibir uma recuperação personalizada via fastboot ou modo de download, conforme descrito na
seção “Enraizando com um carregador de inicialização desbloqueado” anteriormente neste
capítulo.
Primeiro, você precisa identificar a localização da partição de recuperação no dispositivo. Por
exemplo:
shell@android :/ #ls -l /dev/block/platform/*/by-name/recovery lrwxrwxrwx root root

2012-11-20 14:53 recovery -> /dev/block/mmcblk0p7
A saída anterior mostra que a partição de recuperação neste caso está localizada em
/dev/block/mmcblk0p7.
Agora você pode enviar uma imagem de recuperação personalizada para o cartão SD e gravá-la na
partição de recuperação:
adb shell push custom-recovery.img /sdcard/

adb shell dd if=/sdcard/custom-recovery.img of=/dev/block/mmcblk0p7
Finalmente, você precisa reiniciar na recuperação personalizada e aplicar osupacote de

atualização.
recuperação de reinicialização adb
Histórico de ataques conhecidos
O restante desta seção discute vários métodos conhecidos anteriormente para obter
acesso root a dispositivos Android. Ao apresentar esses problemas, esperamos fornecer
informações sobre as possíveis maneiras de obter acesso root a dispositivos Android.
Embora alguns desses problemas afetem o ecossistema Linux maior, a maioria é
específica do Android. Muitos desses problemas não podem ser explorados sem acesso ao
shell ADB. Em cada caso, discutimos a causa raiz da vulnerabilidade e os principais
detalhes de como a exploração a aproveitou.
NOTAO leitor astuto pode notar que vários dos seguintes problemas foram descobertos
sem saber por várias partes separadas. Embora isso não seja uma ocorrência comum,
acontece de vez em quando.
Alguns dos detalhes de exploração fornecidos nesta seção são bastante técnicos. Se eles são
esmagadores, ou você já está intimamente familiarizado com o funcionamento interno dessas
façanhas, sinta-se à vontade para ignorá-los. De qualquer forma, esta seção serve para
documentar essas explorações em detalhes moderados. O Capítulo 8 cobre algumas dessas
façanhas com mais detalhes.
Kernel: Wunderbar/asroot
Este bug foi descoberto por Tavis Ormandy e Julien Tinnes da equipe de
segurança do Google e foi atribuído a CVE-2009-2692:
O kernel do Linux 2.6.0 a 2.6.30.4 e 2.4.4 a 2.4.37.4, não inicializa todos os ponteiros de
função para operações de soquete em estruturas proto_ops, o que permite que
usuários locais acionem uma referência de ponteiro NULL e ganhem privilégios
usando mmap para mapear página zero, colocando código arbitrário nesta página e,
em seguida, invocando uma operação indisponível, conforme demonstrado pela
operação sendpage (função sock_sendpage) em um soquete PF_PPPOX.
Brad Spengler (gastador) escreveu o exploit do empório Wunderbar para x86/

x86_64, que é onde esse bug ganhou seu famoso nome. No entanto, o exploit para
Android (Linux na arquitetura ARM) foi lançado por Christopher Lais (Zinx), é
nomeado como root e está publicado emhttp://g1files.webs.com/Zinx/android-
root-20090816.tar.gz.Essa exploração funcionou em todas as versões do Android que
usavam um kernel vulnerável.
O exploit asroot introduz um novo arquivo “.NULO"seção no endereço 0 com o tamanho
exato de uma página. Esta seção contém o código que define o identificador de usuário atual
(UID) e o identificador de grupo (GID) como root. Em seguida, as chamadas de exploraçãoEnviar
arquivocausar umpágina de enviooperação em umPF_BLUETOOTHsocket com falta de inicialização
doproto_operaçõesestrutura. Isso faz com que o código no arquivo “.NULO"seção a ser
executada no modo kernel, produzindo um shell raiz.
Recuperação: Volez
Um erro tipográfico no verificador de assinatura usado nas imagens de recuperação do Android

2.0 e 2.0.1 fez com que a recuperação detectasse incorretamente o registro End of Central
Directory (EOCD) dentro de um arquivo zip de atualização assinado. Esse problema resultou na
capacidade de modificar o conteúdo de um pacote de recuperação OTA assinado.
O erro do verificador de assinatura foi detectado por Mike Baker ([mbm]) e foi
abusado para fazer root no Motorola Droid quando o primeiro pacote oficial OTA foi
lançado. Ao criar um arquivo zip especialmente criado, foi possível injetar umsu
binário no arquivo zip OTA assinado. Mais tarde, Christopher Lais (Zinx) escreveu Volez, um utilitário
para criar arquivos zip de atualização personalizados a partir de uma atualização assinada válida
zip, disponível emhttp://zenthought.org/content/project/volez.
Udev: Explodir
Essa vulnerabilidade afetou todas as versões do Android até 2.1. Foi originalmente
descoberto como uma vulnerabilidade noudevdaemon usado em sistemas Linux x86. Foi
atribuído CVE-2009-1185. Mais tarde, o Google reintroduziu o problema noiniciar
daemon, que lida com oudevfuncionalidade no Android.
A exploração dependeudevcódigo falhando ao verificar a origem de uma mensagem
NETLINK. Essa falha permite que um processo de espaço do usuário obtenha privilégios
enviando umudevevento alegando ser originário do kernel, que era confiável. A exploração
Exploid original lançada por Sebastian Krahmer (“The Android Exploid Crew”) teve que ser
executada a partir de um diretório gravável e executável no dispositivo.
Primeiro, o exploit criou um socket com um domínio de PF_NETLINK e uma família de
NETLINK_KOBJECT_UEEVENTO(mensagem do kernel para o evento do espaço do usuário).
Em segundo lugar, ele criou um arquivohotplugno diretório atual, contendo o caminho
para oexplodirbinário. Terceiro, criou um link simbólico chamadodadosna corrente
diretório, apontando para /proc/sys/kernel/hotplug.Finalmente, ele enviou uma mensagem

falsificada para o soquete NETLINK.
Quandoiniciarrecebeu esta mensagem, e não conseguiu validar a sua origem,
procedeu à cópia do conteúdo dahotplugarquivo para o arquivodados.Ele fez isso com
privilégios de root. Quando o próximo evento hotplug ocorreu (como desconectar e
reconectar a interface Wi-Fi), o kernel executou oexplodirbinário com privilégios de
root.
Nesse ponto, o código de exploração detectou que estava sendo executado com privilégios
de root. Ele procedeu a remontar a partição do sistema no modo de leitura/gravação e criou
um shell raiz set-uid como /sistema/bin/rootshell.
Adbd: RageAgainstTheCage
Conforme discutido na seção “Abuso do adbd para obter root”, o daemon do ADB (adbd
processo) começa a ser executado como root e descarta privilégios para oConchado utilizador.
Nas versões do Android até 2.2, o daemon ADB não verificava o valor de retorno dosetuid
chamar ao descartar privilégios. Sebastian Krahmer usou esse check-in ausente
adbdpara criar o exploit RageAgainstTheCage disponível emhttp://stealth
. openwall.net/xSports/RageAgainstTheCage.tgz.
A exploração deve ser executada através do shell ADB (sob oConchaUID). Basicamente,
bifurca processos até ogarfofalha na chamada, o que significa que o limite de processo para
esse usuário foi atingido. Este é um limite rígido imposto pelo kernel chamadoLIMITE_
NPROC, que especifica o número máximo de processos (ou threads) que podem ser
criados para o UID real do processo de chamada. Neste ponto, o exploit mataadbd,
fazendo com que ele reinicie (como root novamente). Infelizmente, desta vezadbd
não pode descartar privilégios para o shell porque o limite do processo foi atingido para
esse usuário. osetuidfalha na chamada,adbdnão detecta essa falha e, portanto, continua
executando com privilégios de root. Uma vez bem sucedido,adbdfornece um shell de raiz
atravésshell adbcomando.
Zigoto: Zimperlich e Zysploit

Lembre-se do Capítulo 2 que todos os aplicativos Android começam sendo bifurcados do
processo Zygote. Como você pode imaginar, ozigotoprocesso é executado como root. Após a
bifurcação, o novo processo descarta seus privilégios para o UID do aplicativo de destino
usando osetuidligar.
Muito semelhante ao RageAgainstTheCage, o processo Zygote nas versões do
Android até 2.2 não conseguiu verificar o valor de retorno da chamada parasetuidao
perder privilégios. Novamente, após esgotar o número máximo de processos para o
UID do aplicativo,zigotofalha ao diminuir seus privilégios e inicia o aplicativo como
root.
Essa vulnerabilidade foi explorada por Joshua Wise nas primeiras versões da ferramenta de
desbloqueio não revogada. Mais tarde, quando Sebastian Krahmer fez o Zimperlich
explorar fontes públicas emhttp://c-skills.blogspot.com.es/2011/02/
zimperlich-sources.html,Joshua Wise decidiu abrir o código de seu Zysploit
implementação também, disponível emhttps://github.com/unrevoked/zysploit.
Ashmem: KillingInTheNameOf e psneuter

O subsistema Android Shared Memory (ashmem) é um alocador de memória compartilhada. É
semelhante ao POSIX Shared Memory (SHM), mas com comportamento diferente e uma interface de
programação de aplicativos (API) baseada em arquivo mais simples. A memória compartilhada pode
ser acessada viammapou arquivo de E/S.
Duas explorações de root populares usaram uma vulnerabilidade na implementação ashmem de
versões do Android anteriores à 2.3. Nas versões afetadas, o ashmem permitia a qualquer usuário
remapear a memória compartilhada pertencente aoiniciarprocesso. Essa memória compartilhada
continha o espaço de endereço das propriedades do sistema, que é um armazenamento de dados
global crítico para o sistema operacional Android. Esta vulnerabilidade tem o identificador de
Vulnerabilidades e Exposições Comuns (CVE) CVE-2011-1149.
A exploração KillingInTheNameOf por Sebastian Krahmer remapeou o espaço de
propriedades do sistema para ser gravável e definiu oro.securepropriedade para 0.
Após reiniciar ou reiniciaradbd,a mudança noro.securepropriedade habilitada o acesso
root por meio do shell ADB. Você pode baixar o exploit emhttp://
c-skills.blogspot.com.es/2011/01/adb-trickery-again.html.
A exploração psneuter de Scott Walker (scotty2), usou a mesma vulnerabilidade para
restringir permissões ao espaço de propriedades do sistema. Ao fazê-lo,adbdnão consegui
ler o valorro.securepropriedade para determinar se os privilégios devem ou não ser
descartados para oConchado utilizador. Não é possível determinar o valor dero.seguro,
assumiu quero.securevalor era 0 e não eliminou privilégios. Novamente, isso permitiu o
acesso root por meio do shell ADB. Você pode baixar o psneuter em
https://github.com/tmzt/g2root-kmod/tree/scotty2/scotty2/psneuter.
Vold: GingerBreak
Esta vulnerabilidade foi atribuída a CVE-2011-1823 e foi demonstrada pela primeira
vez por Sebastian Krahmer no exploit GingerBreak, disponível emhttp://c-skills
. blogspot.com.es/2011/04/yummy-yummy-gingerbreak.html.
O daemon do gerenciador de volume (vold) no Android 3.0 e 2.x antes do 2.3.4 confia nas
mensagens recebidas de um soquete PF_NETLINK, que permite a execução de código
arbitrário com privilégios de root por meio de um índice negativo que ignora uma
verificação de número inteiro assinado somente no máximo.
Antes de acionar a vulnerabilidade, a exploração coleta várias informações do sistema.

Primeiro, ele abre /proc/net/netlinke extrai o identificador de processo (PID) dovoldprocesso.
Em seguida, ele inspeciona a biblioteca C do sistema (libc.so) para encontrar osistemae
strcmpendereços de símbolos. Em seguida, ele analisa o cabeçalho Executable and
Linkable Format (ELF) dovoldexecutável para localizar a seção Global Offset Table (GOT).
Em seguida, analisa ovold.fstabarquivo para encontrar o dispositivo
/cartão SDponto de montagem. Finalmente, para descobrir o valor de índice negativo
correto, ele intencionalmente trava o serviço enquanto monitora a saída do logcat.
Após coletar informações, a exploração aciona a vulnerabilidade enviando
mensagens NETLINK maliciosas com o valor de índice negativo calculado. Isso faz
com quevoldalterar entradas em seu próprio GOT para apontar para osistemafunção.
Depois que uma das entradas GOT direcionadas for substituída,voldacaba executando
oGingerBreakbinário com privilégios de root.
Quando o binário de exploração detecta que foi executado com privilégios de root, ele
inicia o estágio final. Aqui, o exploit primeiro remonta /dadospara remover o nosuid
bandeira. Então faz /dados/local/tmp/shset-uid root. Finalmente, ele sai do novo processo
(executando como root) e executa o shell de root set-uid recém-criado a partir do
processo de exploração original.
Um estudo de caso mais detalhado desta vulnerabilidade é fornecido na seção
“GingerBreak” do Capítulo 8.
PowerVR: levitador
Em outubro de 2011, Jon Larimer e Jon Oberheide lançaram o exploit do levitator em
http://jon.oberheide.org/files/levitator.c.Este exploit usa dois
vulnerabilidades que afetam dispositivos Android com o chipset PowerVR SGX. O
driver PowerVR nas versões do Android até 2.3.5 continha especificamente os
seguintes problemas.
CVE-2011-1350: O driver PowerVR falha ao validar o parâmetro de comprimento fornecido

ao retornar dados de resposta para o modo de usuário de uma chamada de sistema ioctl,
fazendo com que ele vaze o conteúdo de até 1 MB de memória do kernel. CVE-2011-1352:
Uma vulnerabilidade de corrupção de memória do kernel que leva qualquer usuário com
acesso a /dev/pvrsrvkm a ter acesso de gravação à memória vazada anterior.
A exploração do levitator aproveita essas duas vulnerabilidades para corromper cirurgicamente a

memória do kernel. Depois de alcançar o escalonamento de privilégios, ele gera um shell. Um estudo
de caso mais detalhado dessa vulnerabilidade é fornecido no Capítulo 10.
Libsysutils: zergRush
A equipe revolucionária lançou o popular exploit zergRush em outubro de 2011;
fontes estão disponíveis emhttps://github.com/revolutionary/zergRush.o
vulnerabilidade explorada foi atribuído CVE-2011-3874, da seguinte forma:
Estouro de buffer baseado em pilha em libsysutils no Android 2.2.x a 2.2.2 e 2.3.x a

2.3.6 permite que invasores remotos assistidos pelo usuário executem código
arbitrário por meio de um aplicativo que chama o método FrameworkListener::
dispatchCommand com o número errado de argumentos, conforme demonstrado
por zergRush para acionar um erro use-after-free.
O exploit usa o daemon do Volume Manager para acionar a vulnerabilidade, pois está
vinculado aolibsysutils.sobiblioteca e é executado como root. Como a pilha não é executável,
o exploit constrói uma cadeia de programação orientada a retorno (ROP) usando gadgets
delibc.sobiblioteca. Em seguida, enviavoldum especialmente elaboradoComando Framework
objeto, fazendo com queComando de execuçãoapontar para a carga útil ROP do exploit. Isso
executa o payload com privilégios de root, que descarta um shell de root e altera o
ro.kernel.qemupropriedade para 1. Como mencionado anteriormente, isso faz com que o
ADB reinicie com privilégios de root.
Um estudo de caso mais detalhado dessa vulnerabilidade é fornecido no Capítulo 8.
Kernel: mempodroid
A vulnerabilidade foi descoberta por Jüri Aedla e recebeu o identificador CVE
CVE-2012-0056:
A função mem_write no kernel Linux 2.6.39 e outras versões, quando o ASLR está
desabilitado, não verifica corretamente as permissões ao gravar em /proc/<pid>/mem, o
que permite que usuários locais obtenham privilégios modificando a memória do
processo, conforme demonstrado por Mempodipper.
O /proc/<pid>/memA entrada do sistema de arquivos proc é uma interface que pode ser usada
para acessar as páginas da memória de um processo por meio de operações de arquivo POSIX,
comoabrir, ler,eeu procuro.No kernel versão 2.6.39, as proteções para acessar a memória de
outros processos foram removidas por engano.
Jay Freeman (saurik) escreveu o exploit mempodroid para Android baseado em um
exploit anterior do Linux, o mempodipper, de Jason A. Donenfeld (zx2c4). A exploração do
mempodroid usa essa vulnerabilidade para gravar diretamente no segmento de código
docorrer comoprograma. Esse binário, usado para executar comandos como um UID de
aplicativo específico, executa set-uid root no Android padrão. Porquecorrer comoestá
vinculado estaticamente no Android, o exploit precisa do endereço na memória dosetresuid
ligue e osaídafunção, para que a carga útil possa ser colocada exatamente à direita
Lugar, colocar. As fontes para a exploração do mempodroid estão disponíveis emhttps://github.

com/saurik/mempodroid.
Um estudo de caso mais detalhado dessa vulnerabilidade é fornecido no Capítulo 8.
Permissão de arquivo e ataques relacionados a links simbólicos
Há uma abundância de permissões de arquivo e ataques relacionados a links simbólicos

presentes em uma variedade de dispositivos. A maioria deles é introduzida por modificações
OEM personalizadas que não estão presentes no estoque do Android. Dan Rosenberg descobriu
muitos desses bugs e forneceu métodos de raiz muito criativos para um abrangente
lista de dispositivos em seu blog emhttp://vulnfactory.org/blog/.
As versões iniciais do Android 4.0 tinham um bug noiniciarfunções parado_chmod, mkdir,e
do_chownque aplicava a propriedade e as permissões de arquivo especificadas mesmo que
o último elemento de seu caminho de destino fosse um link simbólico. Alguns dispositivos
Android têm a seguinte linha em seusinit.rcroteiro.
mkdir /data/local/tmp 0771 shell shell
Como você pode adivinhar agora, se o /dados/localpasta é gravável pelo shell do usuário
ou grupo, você pode explorar essa falha para tornar o /dadospasta gravável substituindo /
dados/local/tmpcom um link simbólico para /dadose reinicializar o dispositivo. Após a
reinicialização, você pode criar ou modificar o /data/local.proparquivo para definir a
propriedadero.kernel.qemupara 1.
Os comandos para explorar esta falha são os seguintes:
adb shell rm -r /data/local/tmp adb shell ln -s /

data/ /data/local/tmp adb reboot
shell adb "echo 'ro.kernel.qemu=1' > /data/local.prop" reinicialização

adb
Outra variante popular desta vulnerabilidade links /dados/local/tmppara a

partição do sistema e, em seguida, usa debugfs para gravar osubinário e torná-lo
setuid root. Por exemplo, o ASUS Transformer Prime rodando o Android 4.0.3 é
vulnerável a esta variante.
Os scripts de inicialização no Android 4.2 se aplicamO_NÃO SIGAsemântica para evitar essa
classe de ataques de link simbólico.
Condição de corrida de restauração do Adb
O Android 4.0 introduziu a capacidade de fazer backups completos de dispositivos por

meio dobackup adbcomando. Este comando faz backup de todos os dados e aplicativos no
arquivobackup.ab,que é um arquivo TAR compactado com um cabeçalho anexado. o
restauração adbcomando é usado para restaurar os dados.
Houve dois problemas de segurança na implementação inicial do processo de restauração
que foram corrigidos no Android 4.1.1. O primeiro problema permitia a criação de arquivos e
diretórios acessíveis por outros aplicativos. O segundo problema permitia restaurar conjuntos
de arquivos de pacotes executados sob um UID especial, comosistema, sem um agente de
backup especial para lidar com o processo de restauração.
Para explorar esses problemas, Andreas Makris (Bin4ry) criou um arquivo de
backup especialmente criado com um diretório legível/gravável/executável contendo
100 arquivos com o conteúdoro.kernel.qemu=1ero.secure=0dentro dele. Quando o
conteúdo deste arquivo é gravado em /data/local.prop,fazadbdexecute com privilégios
de root na inicialização. O exploit original pode ser baixado emhttp://
forum.xda-developers.com/showthread.php?t=1886460.
O seguinte one-liner, se executado enquanto orestauração adbcomando está em execução,
causa uma corrida entre o processo de restauração no serviço do gerenciador de backup e o
enquantoloop executado peloConchado utilizador:
adb shell "enquanto ! ln -s /data/local.prop \

/data/data/com.android.settings/a/file99; Faz :; feito"
Se o loop cria o link simbólico emarquivo99antes que o processo de restauração o restaure, o

processo de restauração segue o link simbólico e grava as propriedades do sistema somente
leitura em /data/local.prop,fazeradbdexecute como root na próxima reinicialização.
Exynos4: abuso de exynos
Essa vulnerabilidade existe em um driver de kernel Samsung e afeta dispositivos com

processador Exynos 4. Basicamente, qualquer aplicativo pode acessar o /dev /
exynosmemdevice file, que permite mapear toda a RAM física com permissões de
leitura e gravação.
A vulnerabilidade foi descoberta por alephzain, que escreveu a exploração
exynosabuse para demonstrá-la e a relatou nos fóruns de desenvolvedores do XDA. o
postagem original está disponível emhttp://forum.xda-developers.com/showthread .
php?t=2048511.
Primeiro, o exploit mapeia a memória do kernel e altera a string de formato para a
manipulação da função /proc/kallsymspara evitar a mitigação do kernel kptr_restrict.
Então ele analisa /proc/kallsymspara encontrar o endereço dosys_setresuid
função do manipulador de chamadas do sistema. Uma vez encontrado, ele corrige a função para
remover uma verificação de permissão e executa osetresuidchamada de sistema no espaço do usuário
para se tornar root. Finalmente, ele reverte as alterações feitas na memória do kernel e executa um
shell de root.
Mais tarde, Alephzain criou umum cliqueaplicativo de root chamado Framaroot. O Framaroot
incorpora três variantes do bug original, cada uma permitindo que usuários sem privilégios
mapeiem memória física arbitrária. Este aplicativo funciona em dispositivos baseados no chipset
Exynos4 e também em dispositivos baseados no chipset TI OMAP3. Mais notavelmente,
alephzain descobriu que a Samsung não corrigiu corretamente
a questão Exynos4. Ele incorporou um novo exploit no Framaroot que explora um estouro
de inteiro presente na correção da Samsung. Isso permite ignorar a validação adicional e
novamente permite sobrescrever a memória do kernel. Essas novas façanhas foram
silenciosamente incluídas no Farmaroot por Alephzain e mais tarde descobertas e
documentado por Dan Rosenberg emhttp://blog.azimuthsecurity.com/2013/02/re-
visiting-exynos-memory-mapping-bug.html.
Diag: iluminado / diaggetroot
Esta vulnerabilidade foi descoberta pela Giantpune e foi atribuído o identificador CVE
CVE-2012-4220:
diagchar_core.c no driver de modo kernel do Qualcomm Innovation Center (QuIC)

Diagnostics (também conhecido como DIAG) para Android 2.3 a 4.2 permite que invasores
executem código arbitrário ou causem uma negação de serviço (referência incorreta de
ponteiro) por meio de um aplicativo que usa argumentos criados em uma chamada local
diagchar_ioctl.
A exploração iluminada usou essa vulnerabilidade para fazer com que o kernel
executasse código nativo da memória do espaço do usuário. Ao ler o /sys/class/leds/lcd-
backlight/regarquivo, era possível fazer com que o kernel processasse estruturas de dados
na memória do espaço do usuário. Durante esse processamento, ele chamou um ponteiro
de função de uma das estruturas, levando ao escalonamento de privilégios.
A exploração diaggetroot, para o dispositivo HTC J Butterfly, também usou essa
vulnerabilidade. No entanto, nesse dispositivo, o dispositivo de personagem vulnerável só
é acessível por usuário ou gruporádio. Para contornar essa situação, o pesquisador
abusou de um provedor de conteúdo para obter um descritor de arquivo aberto para o
dispositivo. O enraizamento por esse método só foi possível com a combinação das duas
técnicas. Você pode baixar o código de exploração emhttps://docs.google.com/
arquivo/d/0B8LDObFOpzZqQzducmxjRExXNnM/edit?pli=1.
Resumo
Fazer root em um dispositivo Android oferece controle total sobre o sistema Android. No entanto, se
você não tomar nenhuma precaução para corrigir os caminhos abertos para obter acesso root, a
segurança do sistema pode ser facilmente comprometida por um invasor.
Este capítulo descreveu os principais conceitos para entender o processo de enraizamento. Ele passou por
métodos legítimos de desbloqueio do carregador de inicialização, como os presentes em dispositivos com um
carregador de inicialização desbloqueado, bem como outros métodos que permitem obter e persistir o
acesso root em um dispositivo com um carregador de inicialização bloqueado. Finalmente,
você viu uma visão geral dos exploits de root mais famosos que foram usados durante a última
década para fazer root em muitos dispositivos Android.
O próximo capítulo mergulha na segurança de aplicativos Android. Ele aborda problemas
comuns de segurança que afetam aplicativos Android e demonstra como usar ferramentas
públicas gratuitas para realizar avaliações de segurança de aplicativos.
APÓS
CH 4
Revisando inscrição Segurança
A segurança de aplicativos tem sido um tópico importante desde antes mesmo do Android
existir. Durante o início da mania de aplicativos da Web, os desenvolvedores se reuniram
para desenvolver aplicativos rapidamente, ignorando as práticas básicas de segurança ou
usando estruturas sem controles de segurança adequados. Com o advento dos aplicativos
móveis, esse mesmo ciclo está se repetindo. Este capítulo começa discutindo alguns
problemas comuns de segurança em aplicativos Android. Ele conclui com dois estudos de
caso demonstrando a descoberta e exploração de falhas de aplicativos usando
ferramentas comuns.
Problemas comuns
Com a segurança de aplicativos tradicional, há vários problemas que surgem repetidamente na

avaliação de segurança e nos relatórios de vulnerabilidade. Os tipos de problemas variam de
vazamentos de informações confidenciais a código crítico ou vulnerabilidades de execução de
comandos. Os aplicativos Android não são imunes a essas falhas, embora os vetores para
atingir essas falhas possam diferir dos aplicativos tradicionais.
Esta seção aborda alguns dos problemas de segurança normalmente encontrados durante os
testes de segurança de aplicativos Android e pesquisas públicas. Esta não é certamente uma lista
exaustiva. À medida que as práticas seguras de desenvolvimento de aplicativos se tornam mais
comuns e as próprias interfaces de programação de aplicativos (APIs) do Android evoluem,
83
84 Capítulo 4-Revisando a segurança do aplicativo
é provável que outras falhas — talvez até novas classes de problemas — venham
à tona.
Problemas de permissão do aplicativo
Dada a granularidade do modelo de permissão do Android, há uma oportunidade para os

desenvolvedores solicitarem mais permissões para seus aplicativos do que o necessário.
Esse comportamento pode ser devido, em parte, a inconsistências na aplicação de
permissões e na documentaçã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. As equipes de pesquisa tentaram
identificar algumas dessas inconsistências de várias maneiras. Por exemplo, em 2012, os
pesquisadores Andrew Reiter e Zach Lanier tentaram mapear os requisitos de permissão
para a API do Android disponível no Android Open Source Project (AOSP). Isso levou a
algumas conclusões interessantes sobre essas lacunas.
Entre algumas das descobertas desse esforço de mapeamento, eles descobriram
inconsistências entre a documentação e a implementação de alguns métodos em
aWiFiMan
menção por
uma captura de tela
Figura 4-1:Documentação para startScan
Isso difere do código-fonte real desse método (no Android 4.2), que indica
uma chamada paraforceCallingOrSelfPermission,que verifica se o chamador tem
oACCESS_WIFI_STATEpermissão por meio de
forceChangePermission:
public void startScan(boolean forceActive) {
forceChangePermission();
mWifiStateMachine.startScan(forceActive);
noteScanStart();
}
...
private void forceChangePermission() {
mContext.enforceCallingOrSelfPermission(android.Manifest.
permission.CHANGE_WIFI_STATE,
"Serviço Wi-Fi");
}
Capítulo 4-Revisando a segurança do aplicativo 85
Outro
TelefoniaM
sion deACCE
desenvolvimento
Figura 4-2:Documentação para getNeighboringCellInfo
No entanto, se você olhar através do código-fonte doPhoneInterfaceManager

class (no Android 4.2), que implementa oTelefoniainterface, você vê o
getNeighboringCellInfométodo realmente verifica a presença doACESSO_
FINE_LOCATIONouACCESS_COARSE_LOCATIONpermissões - nenhuma das quais é
a permissão inexistente e inválida especificada na documentação:
public List<NeighboringCellInfo> getNeighboringCellInfo() {
tentar {
mApp.enforceCallingOrSelfPermission(
android.Manifest.permission.ACCESS_FINE_LOCATION, null);
} catch (SecurityException e) {
// Se tivermos permissão ACCESS_FINE_LOCATION, pule a verificação // para
ACCESS_COARSE_LOCATION
// Uma falha deve lançar o SecurityException de
// ACCESS_COARSE_LOCATION já que esta é a pré-condição mais fraca
mApp.enforceCallingOrSelfPermission(
android.Manifest.permission.ACCESS_COARSE_LOCATION, null);
}
Esses tipos de descuidos, embora aparentemente inócuos, geralmente levam a más práticas por
parte dos desenvolvedores, a sabersubconcessãoou pior,superlotaçãode permissões. No caso de
subconcessão, muitas vezes é um problema de confiabilidade ou funcionalidade, como um problema
não tratadoExceção de segurançaleva ao travamento do aplicativo. Quanto à concessão excessiva, é mais
uma questão de segurança; imagine um aplicativo cheio de bugs e com privilégios excessivos
explorado por um aplicativo malicioso, levando efetivamente ao escalonamento de privilégios.
Para obter mais informações sobre a pesquisa de mapeamento de permissões, consulte
www.slideshare.net/quineslideshare/mapping-and-evolution-of-androidpermissions.
Ao analisar aplicativos Android em busca de permissões excessivas, é

importante comparar quais permissões são solicitadas com o objetivo real do
aplicativo. Certas permissões, comoCÂMERAeENVIAR SMS,pode ser excessivo para
um aplicativo de terceiros. Para estes, a funcionalidade desejada pode ser obtida
adiando para os aplicativos Câmera ou Mensagens e deixando-os lidar com
a tarefa (com a segurança adicional da intervenção do usuário). O estudo de caso

"Aplicativo de segurança móvel", mais adiante no capítulo, demonstra como identificar
onde nos componentes do aplicativo essas permissões são realmente exercidas.
Transmissão insegura de dados confidenciais
Como ele recebe escrutínio constante, a ideia geral de segurança de transporte (por exemplo,
SSL, TLS e assim por diante) geralmente é bem compreendida. Infelizmente, isso nem sempre
se aplica ao mundo dos aplicativos móveis. Talvez devido à falta de entendimento sobre como
implementar corretamente SSL ou TLS, ou apenas a noção incorreta de que “se for pela rede da
operadora, é seguro”, os desenvolvedores de aplicativos móveis às vezes falham em proteger
dados confidenciais em trânsito.
Esse problema tende a se manifestar de uma ou mais das seguintes maneiras:
- Criptografia fraca ou falta de criptografia

- Criptografia forte, mas falta de consideração por avisos de segurança ou erros de
validação de certificado
- Uso de texto simples após falhas

- Uso inconsistente de segurança de transporte por tipo de rede (por exemplo, celular
versus Wi-Fi)
Descobrir problemas de transmissão insegura pode ser tão simples quanto capturar o tráfego
enviado do dispositivo de destino. Os detalhes sobre a construção de uma plataforma man-in-the-
middle estão fora do escopo deste livro, mas existem várias ferramentas e tutoriais para facilitar essa
tarefa. Em um piscar de olhos, o emulador do Android suporta tanto o proxy de tráfego quanto o
despejo de tráfego para um rastreamento de pacote no formato PCAP. Você pode conseguir isso
passando o -proxy HTTPou -tcpdumpopções, respectivamente.
Um exemplo público proeminente de transmissão de dados insegura foi a
implementação do protocolo de autenticação Google ClientLogin em determinados
componentes do Android 2.1 a 2.3.4. Esse protocolo permite que os aplicativos solicitem
um token de autenticação para a conta do Google do usuário, que pode ser reutilizado
para transações subsequentes na API de um determinado serviço.
Em 2011, pesquisadores da Universidade de Ulm descobriram que os aplicativos
Calendário e Contatos no Android 2.1 a 2.3.3 e o serviço Picasa Sync no Android 2.3.4
enviavam o token de autenticação Google ClientLogin por HTTP de texto simples. Depois
que um invasor obtiver esse token, ele poderá ser reutilizado para representar o usuário.
Como existem inúmeras ferramentas e técnicas para conduzir ataques man-in-the-middle
em redes Wi-Fi, a interceptação desse token seria fácil – e seria uma má notícia para um
usuário em uma rede Wi-Fi hostil ou não confiável.
Para obter mais informações sobre as descobertas do Google ClientLogin da Universidade de Ulm,
Vejowww.uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens.html.
Armazenamento de dados inseguro
O Android oferece vários recursos padrão para 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ódigo gerenciado e
nativo, ou por meio de interfaces estruturadas, como provedores de conteúdo. Os erros mais comuns
incluem armazenamento em texto simples de dados confidenciais, provedores de conteúdo
desprotegidos (discutidos posteriormente) e permissões de arquivo inseguras.
Um exemplo coeso de armazenamento de texto simples e permissões de arquivos
inseguros é o cliente Skype para Android, que apresentou esses problemas em abril de
2011. Relatado por Justin Case (jcase) viahttp://AndroidPolice.com,o aplicativo Skype criou
vários arquivos, como bancos de dados SQLite e arquivos XML, com permissões de leitura
e gravação mundial. Além disso, o conteúdo não era criptografado e incluía dados de
configuração e logs de mensagens instantâneas. A saída 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 aplicativo_152 331776 2011-04-13 00:08 main.db 119528 2011-04-13
- rw-rw-rw- app_152 aplicativo_152 00:08 main.db-journal 40960 2011-04-11 14:05
- rw-rw-rw- app_152 aplicativo_152 keyval.db 3522 2011-04-12 23:39 config.xml
- rw-rw-rw- app_152 aplicativo_152
drwxrwxrwx app_152 aplicativo_152 2011-04-11 14:05 correio de voz 0

- rw-rw-rw- app_152 aplicativo_152 2011-04-11 14:05 config.lck 61440
- rw-rw-rw- app_152 aplicativo_152 2011-04-13 00:08 bistats.db
drwxrwxrwx app_152 aplicativo_152 2011-04-12 21:49 chatsync 12824 2011-04-11
- rw-rw-rw- app_152 aplicativo_152 14:05 keyval.db-journal 33344 2011-04-13 00:08
- rw-rw-rw- app_152 aplicativo_152 bistats.db-journal
# grep Padrão /data/data/com.skype.merlin_mecha/files/shared.xml <Default>jcaseap</

Default>
Deixando de lado o aspecto de armazenamento de texto simples, as permissões de arquivo

inseguras foram o resultado de um problema anteriormente menos divulgado com a criação de
arquivos nativos no Android. Bancos de dados SQLite, arquivos de Preferências Compartilhadas e
arquivos simples criados por meio de interfaces Java usavam um modo de arquivo 0660. Isso
renderizava as permissões de leitura/gravação do arquivo para o ID do usuário proprietário e o ID do
grupo. No entanto, quando qualquer arquivo foi criado por meio de código nativo ou comandos
externos, o processo do aplicativo herdou o umask de seu processo pai, Zygote — um umask de 000,
que significa leitura/gravação do mundo. O cliente Skype usava código nativo para grande parte de
sua funcionalidade, incluindo a criação e interação com esses arquivos.
NOTAA partir do Android 4.1, o umask para Zygote foi definido para um valor mais seguro de
077. Mais informações sobre essa alteração são apresentadas no Capítulo 12.
Para obter mais informações sobre a descoberta do jcase no Skype, consultewww.androidpolice

. com/2011/04/14/exclusive-vulnerability-in-skype-for-android-is
- expondo-seu-nome-número de telefone-chat-logs-e-muito-mais/.
Vazamento de informações através de logs
O recurso de log do Android é uma ótima fonte de vazamentos de informações. Por meio do uso
gratuito de métodos de log 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 invocação de atividade. Aplicações com o
READ_LOGSpermissão pode obter acesso a essas mensagens de log (por meio
dologcatcomando).
NOTAoREAD_LOGSpermissão não está mais disponível para aplicativos de terceiros a partir do

Android 4.1. No entanto, para versões mais antigas e dispositivos com root, o acesso de terceiros
a esta permissão e aologcatcomando ainda é possível.
Como exemplo de detalhamento de log do ActivityManager, considere o seguinte

trecho de log:
I/ActivityManager(13738): START {act=android.intent.action.VIEW dat=http://
www.wiley.com/
cmp=com.google.android.browser/com.android.browser.BrowserActivity (tem extras) u=0}
do pid 11352
I/ActivityManager(13738): Iniciar proc com.google.android.browser for activity
com.google.android.browser/com.android.browser.BrowserActivity: pid=11433 uid=10017
gids={3003, 1015, 1028}
Você vê o navegador de ações sendo chamado, talvez por meio do usuário tocar em um link
em um e-mail ou mensagem SMS. Os detalhes do Intent que está sendo passado são
claramente visíveis e incluem o URL (http://www.wiley.com/)o usuário está visitando. Embora esse
exemplo trivial possa não parecer um problema 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 registro excessivo foi encontrado no navegador
Firefox para Android. Neil Bergman relatou esse problema no rastreador de bugs da
Mozilla em dezembro de 2012. O Firefox no Android registrou atividade de navegação,
incluindo URLs que foram visitados. Em alguns casos, isso inclui identificadores de sessão,
como Neil apontou em sua entrada de bug e saída associada dologcatcomando:
I/GeckoBrowserApp(17773): Favicon carregado com sucesso para URL = https://mobile.walmart.com/m/
pharmacy;jsessionid=83CB330691854B071CD172D41DC2C3 AB
I/GeckoBrowserApp(17773): Favicon é para URL atual = https://mobile.walmart.com/m/

pharmacy;jsessionid=83CB330691854B071CD172D41DC2C3
AB
E/GeckoConsole(17773): [Aviso de JavaScript: "Erro na análise do valor de 'fundo'. Declaração
descartada." {Arquivo:
"https://mobile.walmart.com/m/pharmacy;jsessionid=83CB330691854B071CD172D41DC2C 3AB?
wicket:bookmarkablePage=:com.wm.mobile.web.rx.privacy.PrivacyPractices" linha: 0}]
Nesse caso, um aplicativo malicioso (com acesso ao log) poderia coletar esses identificadores
de sessão e sequestrar a sessão da vítima no aplicativo remoto da Web. Para obter mais
detalhes sobre esse problema, consulte o rastreador de bugs da Mozilla emhttps://
bugzilla.mozilla.org/show_bug.cgi?id=825685.
Endpoints IPC não seguros

Os terminais comuns de comunicação entre processos (IPC)—Serviços, Atividades,
BroadcastReceivers e Content Providers—são frequentemente ignorados como
potenciais vetores de ataque. Como fontes e coletores de dados, a interação com eles
depende muito de sua implementação; e seu caso de abuso depende de sua
finalidade. Em seu nível mais básico, a proteção dessas interfaces geralmente é
obtida por meio de permissões de aplicativo (padrão ou personalizadas). Por
exemplo, um aplicativo pode definir um endpoint IPC que deve ser acessível apenas
por outros componentes desse aplicativo ou que deve ser acessível por outros
aplicativos que solicitem a permissão necessária.
Caso um endpoint IPC não esteja devidamente protegido ou um aplicativo mal-intencionado
solicite – e receba – a permissão necessária, há considerações específicas para cada tipo de
endpoint. Os provedores de conteúdo expõem o acesso a dados estruturados por design e,
portanto, são vulneráveis a uma série de ataques, como injeção ou passagem de diretório. As
atividades, como um componente voltado para o usuário, podem ser usadas por um aplicativo
malicioso em um ataque de correção da interface do usuário (UI).
Os receptores de transmissão são frequentemente usados para manipular mensagens de
intenção implícitas ou aquelas com critérios frouxos, como um evento de todo o sistema. Por exemplo,
a chegada de uma nova mensagem SMS faz com que o subsistema de Telefonia transmita um Intent
implícito com oSMS_RECEIVEDação. Receptores de transmissão registrados com um filtro de intenção
correspondente a essa ação recebem esta mensagem. No entanto, o atributo de prioridade dos filtros
de intenção (não exclusivo apenas para Broadcast Receivers) pode determinar a ordem em que uma
intenção implícita é entregue, levando a um possível sequestro ou interceptação dessas mensagens.
NOTAOs intents implícitos são aqueles sem um componente de destino específico, enquanto os
intents explícitos visam um aplicativo específico e um componente de aplicativo (como
“com.wiley.exampleapp.SomeActivity”).
Os serviços, conforme discutido no Capítulo 2, facilitam o processamento em segundo plano de um

aplicativo. Semelhante aos receptores e atividades de transmissão, a interação com os serviços é
realizado usando Intents. Isso inclui ações como iniciar o serviço, interromper o serviço ou
vincular-se ao serviço. Um serviço vinculado também pode expor uma camada adicional
de funcionalidade específica do aplicativo para outros aplicativos. Como essa
funcionalidade é personalizada, um desenvolvedor pode ser tão ousado a ponto de expor
um método que executa comandos arbitrários.
Um bom exemplo do efeito potencial de explorar uma interface IPC
desprotegida é a descoberta de Andre “sh4ka” Moulu no aplicativo Samsung Kies
no Galaxy S3. sh4ka descobriu que o Kies, um aplicativo de sistema altamente
privilegiado (incluindo ter oINSTALL_PACKAGESpermissão) tinha um
BroadcastReceiver que restaurava pacotes de aplicativos (APKs) do /sdcard/
restaurardiretório. O trecho a seguir é da descompilação de Kies do sh4ka:
public void onReceive(Context paramContext, Intent paramIntent) {
...
if
(paramIntent.getAction().toString().equals( "com.intent.action.KIES_START_RESTORE_APK"))
{
kies_start.m_nKiesActionEvent = 15; int i3 =
Log.w("KIES_START",
"KIES_ACTION_EVENT_SZ_START_RESTORE_APK");
byte[] arrayOfByte11 = new byte[6];
byte[] arrayOfByte12 = paramIntent.getByteArrayExtra("head"); byte[]
arrayOfByte13 = paramIntent.getByteArrayExtra("corpo"); byte[] arrayOfByte14 =
new byte[arrayOfByte13.length]; int i4 = arrayOfByte13.length;
System.arraycopy(arrayOfByte13, 0, arrayOfByte14, 0, i4);

StartKiesService(paramContext, arrayOfByte12, arrayOfByte14); Retorna;
No código você vê oao recebermétodo aceitando um Intent,paramIntent. A

chamada paragetAçãoverifica se o valor do campo de ação deparamIntenté
KIES_START_RESTORE_APK.Se isso for verdade, o método extrai alguns valores
extras, head e body, deparamIntente então invocaStartKiesService.A cadeia de
chamadas resulta em Kies iterando por meio de /sdcard/restaurar,instalando
cada APK nele.
Para colocar seu próprio APK em /sdcard/restaurarsem permissões, o sh4ka
explorou outro problema que gerou oWRITE_EXTERNAL_STORAGEprivilégio. Em seu
artigo “From 0 perm app to INSTALL_PACKAGES”, sh4ka mirou oServiço de
salvamento da área de transferênciano Samsung GS3. O trecho de código a seguir
demonstra isso:
Intent intentCreateTemp = new Intent("com.android.clipboardsaveservice.
CLIPBOARD_SAVE_SERVICE");
intentCreateTemp.putExtra("copyPath", "/data/data/"+getPackageName()+ "/files/avast.apk");
intentCreateTemp.putExtra("pastePath", "/data/data/
com.android.clipboardsaveservice/temp/");
startService(intentCreateTemp);
Aqui, o código do sh4ka cria um Intent destinado a

com.android.clipboardsaveservice.CLIPBOARD_SAVE_SERVICE,passando extras contendo o caminho fonte de
seu pacote (noarquivosdiretório do armazenamento de dados de seu aplicativo de prova de conceito) e

o caminho de destino de /sdcard/restaurar.Por fim, a chamada paraComeçar serviço
envia este Intent, eServiço de área de transferênciacopia efetivamente o APK para
/cartão SD.Tudo isso acontece sem o aplicativo de prova de conceito segurando o
WRITE_EXTERNAL_STORAGEpermissão.
No golpe de misericórdia, o Intent apropriado é enviado ao Kies para obter a instalação
arbitrária do pacote:
Intenção intentStartRestore =
new Intent("com.intent.action.KIES_START_RESTORE_APK"); intentStartRestore.putExtra("head",
new String("cocacola").getBytes()); intentStartRestore.putExtra("body", new
String("cocacola").getBytes()); sendBroadcast(intentStartRestore);
Para mais informações sobre o trabalho de sh4ka, confira sua postagem no blog emhttp://sh4ka.
fr/android/galaxys3/from_0perm_to_INSTALL_PACKAGES_on_galaxy_S3.html.
Estudo de caso: aplicativo de segurança móvel
Esta seção aborda a avaliação de um aplicativo Android de segurança/antifurto para

dispositivos móveis. Ele apresenta ferramentas e técnicas para técnicas de análise estática
e dinâmica, e você verá como realizar algumas engenharias reversas básicas. O objetivo é
que você entenda melhor como atacar componentes específicos neste aplicativo, bem
como descobrir quaisquer falhas interessantes que possam ajudar nessa empreitada.
Perfil
Na fase de criação de perfil, você reúne algumas informações superficiais sobre o
aplicativo de destino e tem uma ideia do que está enfrentando. Supondo que você tenha
pouca ou nenhuma informação sobre o aplicativo para começar (às vezes chamado de
abordagem de “conhecimento zero” ou “caixa preta”), é importante aprender um pouco
sobre o desenvolvedor, as dependências do aplicativo e quaisquer outras propriedades
notáveis pode ter. Isso ajudará a determinar quais técnicas empregar em outras fases e
pode até revelar alguns problemas por conta própria, como utilizar uma biblioteca ou
serviço da Web com vulnerabilidade conhecida.
Primeiro, tenha uma ideia do propósito do aplicativo, seu desenvolvedor e o histórico
de desenvolvimento ou revisões. Basta dizer que aplicativos com pouca segurança
histórico
Figura 4-3 sh
aplicação o
Figura 4-3:Descrição do aplicativo no Google Play
Ao examinar essa entrada um pouco mais, você percebe que ela solicita algumas
permissões. Este aplicativo, se instalado, seria bastante privilegiado no que diz
respeito aos aplicativos de terceiros. Ao clicar na guia Permissões na interface do
Play, você pode observar quais permissões estão sendo solicitadas, conforme
mostrado na Figura 4-4.
Com base na descrição e em algumas das permissões listadas, você pode tirar
algumas conclusões. Por exemplo, a descrição menciona travamento remoto,
limpeza e alerta de áudio, que, quando combinados com oLER_SMSpermissão, pode
levar você a acreditar que o SMS é usado para comunicações fora de banda, o que é
comum entre aplicativos antivírus móveis. Anote isso para mais tarde, porque
significa que você pode ter algum código de receptor de SMS para examinar.

5 en PT

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

5 en PT

Enviado por

Direitos autorais:

Formatos disponíveis

Traduzido do Inglês para o Português - www.onlinedoctranslator.

68 Capítulo 3-Enraizando seu dispositivo

Enraizamento com um carregador de inicialização bloqueado

Alguns carregadores de inicialização bloqueados apenas impõem a verificação de assinatura em partições

Ganhando root em um sistema inicializado

Abusando do adbd para obter root

pela imagem de inicialização initrd.

Bloqueios NAND, Raiz Temporária e Raiz Permanente

Figura 3-3:HTC HBOOT bloqueado e desbloqueado

Antes da HTC fornecer o procedimento oficial de desbloqueio do carregador de inicialização em agosto de

1. Primeiro o usuário deve executar o comandofastboot oem get_identifier_ token. O

2. Após enviar o token identificador, o usuário recebe umCódigo de desbloqueio

Se oUnlock_code.binarquivo é válido, o telefone permite usar o padrão

Persistindo uma raiz macia

Carregador de inicialização Desbloquear Portal Carregador de inicialização

Dispositivo bloqueado Desbloqueado

Step1 Passo 2 etapa 3 Passo 4

o desbloqueiochave e inicialização rápida

Figura 3-4:Fluxo de trabalho geral de desbloqueio do carregador de inicialização

Uma maneira típica de automatizar o processo descrito é executando os seguintes

shell@android :/ #ls -l /dev/block/platform/*/by-name/recovery lrwxrwxrwx root root

adb shell push custom-recovery.img /sdcard/

Finalmente, você precisa reiniciar na recuperação personalizada e aplicar osupacote de

recuperação de reinicialização adb

Histórico de ataques conhecidos

Brad Spengler (gastador) escreveu o exploit do empório Wunderbar para x86/

Um erro tipográfico no verificador de assinatura usado nas imagens de recuperação do Android

diretório, apontando para /proc/sys/kernel/hotplug.Finalmente, ele enviou uma mensagem

Zigoto: Zimperlich e Zysploit

Ashmem: KillingInTheNameOf e psneuter

Antes de acionar a vulnerabilidade, a exploração coleta várias informações do sistema.

CVE-2011-1350: O driver PowerVR falha ao validar o parâmetro de comprimento fornecido

A exploração do levitator aproveita essas duas vulnerabilidades para corromper cirurgicamente a

Estouro de buffer baseado em pilha em libsysutils no Android 2.2.x a 2.2.2 e 2.3.x a

Lugar, colocar. As fontes para a exploração do mempodroid estão disponíveis emhttps://github.

Permissão de arquivo e ataques relacionados a links simbólicos

Há uma abundância de permissões de arquivo e ataques relacionados a links simbólicos

mkdir /data/local/tmp 0771 shell shell

adb shell rm -r /data/local/tmp adb shell ln -s /

shell adb "echo 'ro.kernel.qemu=1' > /data/local.prop" reinicialização

Outra variante popular desta vulnerabilidade links /dados/local/tmppara a

Condição de corrida de restauração do Adb

O Android 4.0 introduziu a capacidade de fazer backups completos de dispositivos por

adb shell "enquanto ! ln -s /data/local.prop \

Se o loop cria o link simbólico emarquivo99antes que o processo de restauração o restaure, o

Exynos4: abuso de exynos

Essa vulnerabilidade existe em um driver de kernel Samsung e afeta dispositivos com

Diag: iluminado / diaggetroot

diagchar_core.c no driver de modo kernel do Qualcomm Innovation Center (QuIC)

Revisando inscrição Segurança

Com a segurança de aplicativos tradicional, há vários problemas que surgem repetidamente na

Problemas de permissão do aplicativo

Dada a granularidade do modelo de permissão do Android, há uma oportunidade para os

Figura 4-1:Documentação para startScan

Figura 4-2:Documentação para getNeighboringCellInfo

No entanto, se você olhar através do código-fonte doPhoneInterfaceManager

Ao analisar aplicativos Android em busca de permissões excessivas, é

a tarefa (com a segurança adicional da intervenção do usuário). O estudo de caso

Transmissão insegura de dados confidenciais

- Criptografia fraca ou falta de criptografia

- Uso de texto simples após falhas

Armazenamento de dados inseguro

drwxrwxrwx app_152 aplicativo_152 2011-04-11 14:05 correio de voz 0