Como o Android Dockerizado Funciona em Diferentes Sistemas Operativos

:::info Autores:

(1) Daniele Capone, SecSI srl, Nápoles, Itália ([email protected]);

(2) Francesco Caturano, Dept. de Engenharia Elétrica e Informação, Universidade de Tecnologia de Nápoles Federico II, Nápoles, Itália ([email protected])

(3) Angelo Delicato, SecSI srl, Nápoles, Itália ([email protected]);

(4) Gaetano Perrone, Dept. de Engenharia Elétrica e Tecnologia da Informação, Universidade de Nápoles Federico II, Nápoles, Itália ([email protected])

(5) Simon Pietro Romano, Dept. de Engenharia Elétrica e Tecnologia da Informação, Universidade de Nápoles Federico II, Nápoles, Itália ([email protected]).

:::

Tabela de Links

Resumo e I. Introdução

II. Trabalhos Relacionados

III. Dockerized Android: Design

IV. Arquitetura Dockerized Android

V. Avaliação

VI. Conclusão e Desenvolvimentos Futuros, e Referências

V. AVALIAÇÃO

Esta secção avalia a plataforma Dockerized Android examinando vários aspetos. Primeiro, enfatizamos as diferenças entre os componentes Core para Emulador e Core para Dispositivo Real em termos de funcionalidades e destacamos a compatibilidade com os três Sistemas Operativos mais utilizados. Em seguida, fornecemos exemplos práticos de utilização do Dockerized Android e discutimos a cobertura dos requisitos definidos na Secção III.

\

\ A. Diferenças entre Core para Emulador e Core para Dispositivo Real

\ Mesmo que um esforço significativo tenha sido feito para criar um sistema que tenha as mesmas funcionalidades para ambos os tipos de dispositivos, existem limitações quando a emulação é utilizada:

\ • Funcionalidade de envio/receção de SMS ADB: em dispositivos emulados, é possível automatizar o envio e receção de mensagens SMS através do software ADB. Obviamente, isto não é nativamente possível para dispositivos reais. Portanto, o utilizador deve enviar e receber manualmente mensagens SMS para implementar cenários de ataque por SMS. Uma solução para resolver este problema poderia ser a realização de uma aplicação Android personalizada que pudesse ser instalada num dispositivo real e pudesse ser instrumentada para enviar e receber mensagens automaticamente.

\ • Rede: a rede é bastante diferente entre as versões do Emulador e do Dispositivo Real. Na versão do emulador, o AVD é criado dentro do contentor Docker e, portanto, partilha o endereço IP do contentor. Em vez disso, o dispositivo real está fisicamente conectado à máquina que executa o contentor e mantém o seu próprio endereço IP.

\ • Virtualização de hardware: para os componentes de hardware, a situação também é bastante diferente: alguns dispositivos de hardware como o GPS e o microfone podem ser emulados. Em particular, a localização GPS do dispositivo pode ser definida através do ADB, e o microfone da máquina host pode ser partilhado com o emulador. Existem outros componentes de hardware que atualmente não podem ser emulados, como, por exemplo, o Bluetooth.

\ B. Avaliação do host para compatibilidade multiplataforma

\ O requisito não funcional NF04 (Compatibilidade multiplataforma) afirma que o sistema resultante deve ser utilizável a partir de qualquer SO host. Isto refere-se ao SO da máquina que executa os contentores Docker. A Tabela III fornece um resumo da compatibilidade com Linux, Windows e OS X.

\

\ O problema com o Windows é que, atualmente, a melhor maneira de usar o Docker é através do framework Windows Subsystem for Linux (WSL). Infelizmente, o WSL ainda não suporta virtualização aninhada, e esta funcionalidade é necessária para executar o emulador Android dentro de um contentor Docker. No entanto, a funcionalidade estará disponível nas próximas versões do WSL. Pode ser possível executar o Core para Emulador no Windows usando uma máquina virtual, embora perdendo todos os benefícios de desempenho associados à conteinerização. Um problema semelhante existe com o OS X, com o qual atualmente não há como executar o Core para Emulador. Além disso, o OS X não permite partilhar o dispositivo USB com um contentor Docker. Por esta razão, as únicas maneiras de usar o Core para Dispositivo Real são executar o ADB via Wi-Fi ou conectar-se ao ADB do host a partir do contentor Docker.

\ No restante desta secção, mostramos a eficácia do Dockerized Android na reprodução de cadeias de ataque de segurança usando tanto o Core para Emulador quanto o Core para Dispositivo Real.

\ C. Reprodução de ataque de segurança no emulador

\ Aqui focamos num cenário de vulnerabilidade de amostra associado ao CVE-2018-7661[1]. Este CVE está relacionado com a versão gratuita da aplicação "Wi-Fi Baby Monitor". Esta aplicação deve ser instalada em dois dispositivos para atuar como um chamado monitor de bebé (um sistema de rádio usado para ouvir remotamente sons emitidos por um bebé). Conforme relatado na Base de Dados Nacional de Vulnerabilidades, "Wi-Fi Baby Monitor Free & Lite" antes da versão 2.02.2 permite que atacantes remotos obtenham dados de áudio através de certas solicitações específicas para os números de porta TCP 8258 e 8257".

\

\ A versão premium desta aplicação oferece aos utilizadores a capacidade de especificar uma senha para usar no processo de emparelhamento. Ao monitorizar o tráfego de rede, é possível observar que:

\ • a conexão inicial ocorre na porta 8257;

\ • a mesma sequência é sempre enviada para iniciar o processo de emparelhamento;

\ • no final do processo de emparelhamento, uma nova conexão é iniciada na porta 8258. Esta porta é usada para transmitir os dados de áudio;

\ • após conectar à porta 8258, a outra conexão na porta 8257 é mantida aberta e usada como um heartbeat para a sessão;

\ • na conexão de heartbeat, o cliente envia periodicamente o byte hexadecimal 0x01 (cerca de uma vez por segundo);

\ A prova de conceito que permite ao atacante obter dados de áudio é dada em [21]. Esta Prova de Conceito (PoC) é facilmente reproduzível no Dockerized Android através da realização de uma infraestrutura composta por três serviços:

\ • core-emulator: uma instância do componente Core com uma aplicação Baby Monitor pré-instalada atuando como o remetente;

\ • ui: o componente UI para controlar o que está acontecendo;

\ • attacker: uma versão personalizada do Kali Linux que instala automaticamente todas as dependências necessárias para a execução do PoC.

\ Este é também um exemplo perfeito para mostrar a funcionalidade de Port Forwarding usada para habilitar as comunicações.

\ D. Reprodução de ataque de segurança no dispositivo real

\ Com o dispositivo real, examinamos uma vulnerabilidade adicional, conhecida como BlueBorne. O termo "BlueBorne" refere-se a múltiplas vulnerabilidades de segurança relacionadas com a implementação do Bluetooth. Estas vulnerabilidades foram descobertas por um grupo de pesquisadores da Armis Security, uma empresa de segurança IoT, em setembro de 2017. De acordo com a Armis, no momento da descoberta, cerca de 8,2 mil milhões de dispositivos foram potencialmente afetados pelo vetor de ataque BlueBorne, que afeta as implementações de Bluetooth em Android, iOS, Microsoft e Linux, impactando assim quase todos os tipos de dispositivos Bluetooth, como smartphones, laptops e smartwatches. O BlueBorne foi analisado em detalhe num artigo publicado em 12 de setembro de 2017 por Ben Seri e Gregor Vishnepolsk [22]. Oito vulnerabilidades diferentes podem ser usadas como parte do vetor de ataque.

\ Em relação ao Android, todos os dispositivos e versões (portanto, versões mais antigas que o Android Oreo, que foi lançado em dezembro de 2017) são afetados pelas vulnerabilidades acima mencionadas, exceto dispositivos que suportam BLE (Bluetooth Low Energy). Em geral, dois requisitos devem ser satisfeitos para explorar a vulnerabilidade: (i) o dispositivo alvo deve ter o Bluetooth ativado; (ii) o atacante deve estar suficientemente próximo do dispositivo alvo. Como a funcionalidade Bluetooth não está disponível no Core Emulator, a kill-chain em questão só pode ser reproduzida em dispositivos reais.

\ 1) Reprodução completa do BlueBorne no Dockerized Android: Para mostrar a eficácia do Dockerized Android, desenvolvemos uma kill chain que explora duas vulnerabilidades de Execução Remota de Código (RCE) que afetam o Android, ou seja, CVE-2017-0781 e CVE-2017-0782. Estas vulnerabilidades fazem parte do conjunto de vulnerabilidades Bluetooth definido como "BlueBorne" e descoberto por um grupo de pesquisadores de segurança da Armis Security [23].

\ O diagrama na Fig. 4 fornece uma visão geral da kill chain desenvolvida:

\

1. O atacante cria um email de phishing através do Gophish, um software gerador de phishing.

\ 2) O email de phishing é enviado para a caixa de correio de uma vítima.

\ 3) A vítima lê o email de phishing e erroneamente clica num link malicioso contido no corpo do email.

\ 4) O link malicioso permite ao atacante desencadear um ataque que descarrega e instala uma aplicação falsa no dispositivo móvel da vítima.

\ 5) A informação maliciosa envia informações móveis relevantes para o atacante. Esta informação é necessária para a exploração das duas vulnerabilidades.

\ 6) O atacante cria um payload malicioso para explorar as vulnerabilidades.

\ 7) O atacante envia o ataque explorando as vulnerabilidades do componente Bluetooth e tem acesso remoto ao dispositivo da vítima.

\

\ O cenário complexo cobre várias ameaças definidas na Tabela I. A Tabela V mostra tais ameaças e tanto as funcionalidades da plataforma quanto os componentes que permitem a reprodução do cenário. O

\

\ cenário requer comunicações de rede complexas (F07) e envolve a utilização de Bluetooth. Por esta razão, temos que usar um dispositivo físico (F10). No cenário proposto, temos que simular a instalação da aplicação maliciosa quando o utilizador recebe o email. Isto pode ser feito manualmente (F02) ou implementando scripts de utilidade ADB (F03). Para reproduzir o cenário, elementos adicionais são necessários:

\ • Gophish: uma aplicação web que permite criar e enviar emails de phishing, para a qual já existe uma versão Docker.

\ • Ghidra: uma aplicação criada pela Agência de Segurança Nacional (NSA) para fins de engenharia reversa. Neste contexto, é usada para obter algumas informações úteis sobre o dispositivo alvo. Esta aplicação é usada na máquina host sem Docker.

\ • Fake Spotify: uma aplicação aparentemente benigna que pretende fornecer ao utilizador uma versão gratuita da conhecida aplicação Spotify Premium, mas que envia para o servidor do atacante ficheiros exfiltrados que são submetidos a engenharia reversa no Ghidra. Além disso, esta aplicação foi criada sem o uso do Docker.

\

\ É composto por cinco serviços, dois dos quais são os subcomponentes do Dockerized Android. Os três restantes são brevemente descritos a seguir:

\ • attacker_phishing: contém o componente Gophish usado para criar e enviar o email de phishing que engana o utilizador a descarregar a aplicação maliciosa Fake Spotify;

\ • attackerwebserver: contém o servidor web usado para receber os ficheiros enviados pela aplicação maliciosa, que são submetidos a engenharia reversa para encontrar informações que permitam