Skip to content

Teste de Segurança Android

Neste capítulo, mergulharemos na configuração de um ambiente de teste de segurança e apresentaremos alguns processos e técnicas práticas para testar a segurança de aplicativos Android. Estes são os blocos fundamentais para os casos de teste do MASTG.

Configuração de Teste Android

Você pode configurar um ambiente de teste totalmente funcional em praticamente qualquer máquina com Windows, Linux ou macOS.

Dispositivo Host

No mínimo, você precisará do Android Studio (que vem com as platform tools Android SDK), um emulador e um aplicativo para gerenciar as várias versões do SDK e componentes do framework. O Android Studio também vem com um aplicativo Android Virtual Device (AVD) Manager para criar imagens de emulador. Certifique-se de que os pacotes mais recentes de SDK tools e platform tools estejam instalados em seu sistema.

Além disso, você pode querer completar sua configuração host instalando Android NDK se planeja trabalhar com aplicativos contendo bibliotecas nativas.

Às vezes pode ser útil exibir ou controlar dispositivos a partir do computador. Para conseguir isso, você pode usar Scrcpy.

Dispositivo de Teste

Para dynamic analysis, você precisará de um dispositivo Android para executar o target app. Em princípio, você pode testar sem um dispositivo Android real e usar apenas o emulador. No entanto, os aplicativos executam bastante lentamente em um emulador, e simuladores podem não dar resultados realistas. Testar em um dispositivo real torna o processo mais suave e o ambiente mais realista. Por outro lado, emuladores permitem que você altere facilmente as SDK versions ou crie múltiplos dispositivos. Uma visão completa dos prós e contras de cada abordagem está listada na tabela abaixo.

Propriedade Físico Emulador/Simulador
Capacidade de restauração Softbricks são sempre possíveis, mas normalmente ainda é possível instalar um novo firmware. Hardbricks são muito raros. Emuladores podem travar ou corromper, mas um novo pode ser criado ou um snapshot pode ser restaurado.
Reset Pode ser restaurado para configurações de fábrica ou reinstalado. Emuladores podem ser excluídos e recriados.
Snapshots Não é possível. Suportado, excelente para malware analysis.
Velocidade Muito mais rápido que emuladores. Tipicamente lento, mas melhorias estão sendo feitas.
Custo Normalmente começam em $200 para um dispositivo utilizável. Você pode precisar de dispositivos diferentes, como um com ou sem biometric sensor. Existem soluções gratuitas e comerciais.
Facilidade de rooting Altamente dependente do dispositivo. Normalmente rooted por padrão.
Facilidade de detecção de emulador Não é um emulador, então emulator checks não se aplicam. Muitos artefacts existirão, facilitando detectar que o aplicativo está rodando em um emulador.
Facilidade de detecção de root Mais fácil esconder root, pois muitos root detection algorithms verificam propriedades de emulador. Com Magisk Systemless root é quase impossível detectar. Emuladores quase sempre acionam root detection algorithms devido ao fato de serem construídos para teste com muitos artefacts que podem ser encontrados.
Interação com hardware Interação fácil através de Bluetooth, NFC, 4G, Wi-Fi, biometrics, camera, GPS, gyroscope, ... Normalmente bastante limitada, com entrada de hardware emulada (ex: GPS coordinates aleatórias)
Suporte a nível de API Depende do dispositivo e da comunidade. Comunidades ativas continuarão distribuindo versões atualizadas (ex: LineageOS), enquanto dispositivos menos populares podem receber apenas algumas atualizações. Alternar entre versões requer reinstalar o dispositivo, um processo tedioso. Sempre suporta as versões mais recentes, incluindo beta releases. Emuladores contendo níveis específicos de API level podem ser facilmente baixados e iniciados.
Suporte a bibliotecas nativas Native libraries normalmente são construídas para dispositivos ARM, então funcionarão em um dispositivo físico. Alguns emuladores rodam em x86 CPUs, então podem não conseguir executar native libraries empacotadas.
Perigo de malware Amostras de malware podem infectar um dispositivo, mas se você conseguir limpar o armazenamento do dispositivo e instalar um firmware limpo, restaurando-o assim para as configurações de fábrica, isso não deve ser um problema. Esteja ciente de que existem amostras de malware que tentam explorar a USB bridge. Amostras de malware podem infectar um emulador, mas o emulador pode simplesmente ser removido e recriado. Também é possível criar snapshots e comparar diferentes snapshots para auxiliar na malware analysis. Esteja ciente de que existem proofs of concept de malware que tentam atacar o hypervisor.

Testando em um Dispositivo Real

Quase qualquer dispositivo físico pode ser usado para teste, mas há algumas considerações a serem feitas. Primeiro, o dispositivo precisa ser rootable. Isso normalmente é feito através de uma exploração ou através de um bootloader desbloqueado. Explorações nem sempre estão disponíveis, e o bootloader pode estar bloqueado permanentemente, ou pode ser desbloqueado apenas após o término do contrato com a operadora.

Os melhores candidatos são dispositivos Google Pixel flagship construídos para desenvolvedores. Esses dispositivos normalmente vêm com unlockable bootloader, firmware opensource, kernel, radio disponíveis online e OS source code oficial. As comunidades de desenvolvedores preferem dispositivos Google pois o OS é o mais próximo do Android open source project. Esses dispositivos geralmente têm as janelas de suporte mais longas com 2 anos de OS updates e 1 ano de security updates após isso.

Alternativamente, o projeto Android One do Google contém dispositivos que receberão as mesmas janelas de suporte (2 anos de OS updates, 1 ano de security updates) e têm experiências near-stock. Embora tenha começado originalmente como um projeto para dispositivos low-end, o programa evoluiu para incluir smartphones mid-range e high-end, muitos dos quais são ativamente suportados pela modding community.

Dispositivos suportados pelo projeto LineageOS também são muito bons candidatos para dispositivos de teste. Eles têm uma comunidade ativa, instruções fáceis de seguir para flashing e rooting, e as versões mais recentes do Android normalmente ficam disponíveis rapidamente como uma instalação Lineage. O LineageOS também continua dando suporte a novas versões do Android muito tempo depois que a OEM parou de distribuir atualizações.

Ao trabalhar com um dispositivo Android físico, você vai querer ativar o Developer Mode e USB debugging no dispositivo para usar a interface de depuração adb. Desde o Android 4.2 (API level 16), o submenu Developer options no aplicativo Settings está oculto por padrão. Para ativá-lo, toque na seção Build number da visualização About phone sete vezes. Observe que a localização do campo do número da compilação varia um pouco por dispositivo. Por exemplo, em LG Phones, está em About phone -> Software information. Uma vez feito isso, Developer options será mostrado na parte inferior do menu Settings. Uma vez que as developer options estejam ativadas, você pode habilitar a depuração com o switch USB debugging.

Testando em um Emulador

Existem múltiplos emuladores, mais uma vez com seus próprios pontos fortes e fracos:

Emuladores gratuitos:

Emuladores comerciais:

  • Genymotion - Emulador maduro com muitos recursos, tanto como solução local quanto cloud-based. Versão gratuita disponível para uso não comercial.
  • Corellium - Oferece virtualização de dispositivo personalizada através de uma solução cloud-based ou on-prem.

Embora existam vários emuladores Android gratuitos, recomendamos usar o AVD pois fornece recursos aprimorados apropriados para testar seu aplicativo em comparação com os outros. No restante deste guia, usaremos o AVD oficial para realizar testes.

O AVD suporta alguma emulação de hardware, como GPS ou SMS através de seus chamados Extended Controls, bem como motion sensors.

Você pode iniciar um Android Virtual Device (AVD) usando o AVD Manager no Android Studio ou iniciar o AVD manager a partir da linha de comando com o comando android, que é encontrado no diretório de tools do Android SDK:

./android avd

Várias ferramentas e VMs que podem ser usadas para testar um aplicativo dentro de um ambiente de emulador estão disponíveis:

Obtendo Acesso Privilegiado

Rooting (ou seja, modificar o OS para que você possa executar comandos como o root user) é recomendado para teste em um dispositivo real. Isso dá a você controle total sobre o sistema operacional e permite contornar restrições como app sandboxing. Esses privilégios por sua vez permitem que você use técnicas como code injection e function hooking mais facilmente.

Observe que fazer rooting é arriscado, e três consequências principais precisam ser esclarecidas antes de você prosseguir. Fazer rooting pode ter os seguintes efeitos negativos:

  • anular a garantia do dispositivo (sempre verifique a política do fabricante antes de tomar qualquer ação)
  • "bricking" o dispositivo, ou seja, torná-lo inoperante e inutilizável
  • criar riscos de segurança adicionais (porque exploit mitigations integradas são frequentemente removidas)

Você não deve fazer rooting em um dispositivo pessoal onde você armazena suas informações privadas. Recomendamos obter um dispositivo de teste dedicado e barato. Muitos dispositivos mais antigos, como a série Nexus do Google, podem executar as versões mais recentes do Android e são perfeitamente adequados para teste.

Você precisa entender que fazer rooting no seu dispositivo é, em última análise, SUA decisão e que a OWASP não deve de forma alguma ser responsabilizada por qualquer dano. Se você estiver incerto, busque aconselhamento especializado antes de iniciar o processo de rooting.

Quais Dispositivos Móveis Podem Ser Rooteados

Virtualmente qualquer dispositivo móvel Android pode ser rootado. Versões comerciais do Android OS (que são evoluções do Linux OS no nível do kernel) são otimizadas para o mundo móvel. Alguns recursos foram removidos ou desativados para essas versões, por exemplo, a capacidade de usuários não privilegiados se tornarem o usuário 'root' (que tem privilégios elevados). Fazer rooting em um telefone significa permitir que usuários se tornem o usuário root, por exemplo, adicionando um executável Linux padrão chamado su, que é usado para mudar para outra conta de usuário.

Para fazer rooting em um dispositivo móvel, primeiro desbloqueie seu boot loader. O procedimento de desbloqueio depende do fabricante do dispositivo. No entanto, por razões práticas, fazer rooting em alguns dispositivos móveis é mais popular do que em outros, particularmente quando se trata de teste de segurança: dispositivos criados pelo Google e fabricados por empresas como Samsung, LG, e Motorola estão entre os mais populares, particularmente porque são usados por muitos desenvolvedores. A garantia do dispositivo não é anulada quando o boot loader é desbloqueado e o Google fornece muitas ferramentas para suportar o root em si.

Rooting com Magisk

Magisk ("Magic Mask") é uma maneira de fazer rooting no seu dispositivo Android. Sua especialidade está na maneira como as modificações no sistema são realizadas. Enquanto outras ferramentas de root alteram os dados reais na partição do sistema, o Magisk não (o que é chamado de "systemless"). Isso permite uma maneira de esconder as modificações de root-sensitive applications (ex: para bancos ou jogos) e permite usar as Android OTA upgrades oficiais sem a necessidade de remover o root antecipadamente.

Você pode se familiarizar com o Magisk lendo a documentação oficial no GitHub. Se você não tem o Magisk instalado, pode encontrar instruções de instalação na documentação. Se você usa uma versão oficial do Android e planeja atualizá-la, o Magisk fornece um tutorial no GitHub.

Além disso, desenvolvedores podem usar o poder do Magisk para criar modules personalizados e submeter-los ao repositório oficial de Magisk Modules. Módulos submetidos podem então ser instalados dentro do aplicativo Magisk Manager. Um desses módulos instaláveis é uma versão systemless do Xposed (disponível para SDK versions até 27).

Detecção de Root

Uma lista extensa de métodos de root detection é apresentada no capítulo "Testando Defesas Anti-Reversão no Android".

Para uma mobile app security build típica, você geralmente vai querer testar uma debug build com root detection desativada. Se tal compilação não estiver disponível para teste, você pode desativar a root detection de várias maneiras que serão introduzidas mais adiante neste livro.