Cómo funciona Android en Docker en diferentes sistemas operativos

:::info Autores:

(1) Daniele Capone, SecSI srl, Nápoles, Italia (daniele.capone@secsi.io);

(2) Francesco Caturano, Dept. de Ingeniería Eléctrica e Información, Universidad de Tecnología de Nápoles Federico II, Nápoles, Italia (francesco.caturano@unina.i)

(3) Angelo Delicato, SecSI srl, Nápoles, Italia (angelo.delicato@secsi.io);

(4) Gaetano Perrone, Dept. de Ingeniería Eléctrica y Tecnología de la Información, Universidad de Nápoles Federico II, Nápoles, Italia (gaetano.perrone@unina.it)

(5) Simon Pietro Romano, Dept. de Ingeniería Eléctrica y Tecnología de la Información, Universidad de Nápoles Federico II, Nápoles, Italia (spromano@unina.it).

:::

Tabla de Enlaces

Resumen e I. Introducción

II. Trabajos Relacionados

III. Dockerized Android: Diseño

IV. Arquitectura de Dockerized Android

V. Evaluación

VI. Conclusión y Desarrollos Futuros, y Referencias

V. EVALUACIÓN

Esta sección evalúa la plataforma Dockerized Android examinando varios aspectos. En primer lugar, enfatizamos las diferencias entre los componentes Core para Emulador y Core para Dispositivo Real en términos de características y destacamos la compatibilidad con los tres Sistemas Operativos más utilizados. Luego, proporcionamos ejemplos prácticos de uso de Dockerized Android y discutimos la cobertura de los requisitos definidos en la Sección III.

\

\ A. Diferencias entre Core para Emulador y Core para Dispositivo Real

\ Aunque se ha realizado un esfuerzo significativo para crear un sistema que tenga las mismas características para ambos tipos de dispositivos, existen limitaciones cuando se utiliza la emulación:

\ • Función de envío/recepción de SMS ADB: en dispositivos emulados, es posible automatizar el envío y recepción de mensajes SMS a través del software ADB. Obviamente, esto no es posible de forma nativa para dispositivos reales. Por lo tanto, el usuario debe enviar y recibir mensajes SMS manualmente para implementar escenarios de ataque SMS. Una solución para abordar este problema podría ser la realización de una aplicación Android personalizada que podría instalarse en un dispositivo real y podría ser instrumentada para enviar y recibir mensajes automáticamente.

\ • Redes: las redes son bastante diferentes entre las versiones de Emulador y Dispositivo Real. En la versión del emulador, el AVD se crea dentro del contenedor Docker, y por lo tanto comparte la dirección IP del contenedor. En cambio, el dispositivo real está físicamente conectado a la máquina que ejecuta el contenedor y mantiene su propia dirección IP.

\ • Virtualización de hardware: para los componentes de hardware, la situación también es bastante diferente: algunos dispositivos de hardware como el GPS y el micrófono pueden ser emulados. En particular, la ubicación GPS del dispositivo puede establecerse a través de ADB, y el micrófono de la máquina host puede compartirse con el emulador. Hay otros componentes de hardware que actualmente no pueden ser emulados, como, por ejemplo, Bluetooth.

\ B. Evaluación del host para compatibilidad multiplataforma

\ El requisito no funcional NF04 (Compatibilidad multiplataforma) establece que el sistema resultante debe ser utilizable desde cualquier sistema operativo host. Esto se refiere al sistema operativo de la máquina que ejecuta los contenedores Docker. La Tabla III proporciona un resumen de la compatibilidad con Linux, Windows y OS X.

\

\ El problema con Windows es que actualmente, la mejor manera de usar Docker es a través del framework Windows Subsystem for Linux (WSL). Desafortunadamente, WSL aún no admite virtualización anidada, y esta característica es necesaria para ejecutar el emulador de Android dentro de un contenedor Docker. Sin embargo, la característica estará disponible en próximas versiones de WSL. Podría ser posible ejecutar la versión Core para Emulador en Windows utilizando una máquina virtual, aunque perdiendo todos los beneficios de rendimiento asociados con la contenedorización. Un problema similar existe con OS X, con el cual actualmente no hay forma de ejecutar el Core para Emulador. Además, OS X no permite compartir el dispositivo USB con un contenedor Docker. Por esta razón, las únicas formas de utilizar la versión Core para Dispositivo Real son ejecutar ADB a través de Wi-Fi o conectarse al ADB del host desde dentro del contenedor Docker.

\ En el resto de esta sección, mostramos la efectividad de Dockerized Android en la reproducción de cadenas de ataque de seguridad utilizando tanto el Core para Emulador como el Core para Dispositivo Real.

\ C. Reproducción de ataques de seguridad en el emulador

\ Aquí nos centramos en un escenario de vulnerabilidad de muestra asociado con CVE-2018-7661[1]. Este CVE está relacionado con la versión gratuita de la aplicación "Wi-Fi Baby Monitor". Esta aplicación debe instalarse en dos dispositivos para actuar como un llamado monitor de bebé (un sistema de radio utilizado para escuchar remotamente los sonidos emitidos por un bebé). Según lo informado en la Base de Datos Nacional de Vulnerabilidades, "Wi-Fi Baby Monitor Free & Lite" antes de la versión 2.02.2 permite a atacantes remotos obtener datos de audio a través de ciertas solicitudes específicas a los números de puerto TCP 8258 y 8257".

\

\ La versión premium de esta aplicación ofrece a los usuarios la capacidad de especificar una contraseña para usar en el proceso de emparejamiento. Al monitorear el tráfico de red, es posible observar que:

\ • la conexión inicial se realiza en el puerto 8257;

\ • siempre se envía la misma secuencia para iniciar el proceso de emparejamiento;

\ • al final del proceso de emparejamiento, se inicia una nueva conexión en el puerto 8258. Este puerto se utiliza para transmitir los datos de audio;

\ • después de conectarse al puerto 8258, la otra conexión en el puerto 8257 se mantiene abierta y se utiliza como latido cardíaco para la sesión;

\ • en la conexión de latido cardíaco, el cliente envía periódicamente el byte hexadecimal 0x01 (aproximadamente una vez por segundo);

\ La prueba de concepto que permite al atacante obtener datos de audio se proporciona en [21]. Esta Prueba de Concepto (PoC) es fácilmente reproducible en Dockerized Android a través de la realización de una infraestructura compuesta por tres servicios:

\ • core-emulator: una instancia del componente Core con una aplicación Baby Monitor preinstalada que actúa como emisor;

\ • ui: el componente UI para controlar lo que está sucediendo;

\ • attacker: una versión personalizada de Kali Linux que instala automáticamente todas las dependencias necesarias para la ejecución del PoC.

\ Este es también un ejemplo perfecto para mostrar la función de Reenvío de Puertos utilizada para habilitar las comunicaciones.

\ D. Reproducción de ataques de seguridad en el dispositivo real

\ Con el dispositivo real, examinamos una vulnerabilidad adicional, conocida como BlueBorne. El término "BlueBorne" se refiere a múltiples vulnerabilidades de seguridad relacionadas con la implementación de Bluetooth. Estas vulnerabilidades fueron descubiertas por un grupo de investigadores de Armis Security, una empresa de seguridad IoT, en septiembre de 2017. Según Armis, en el momento del descubrimiento, alrededor de 8.2 mil millones de dispositivos estaban potencialmente afectados por el vector de ataque BlueBorne, que afecta a las implementaciones de Bluetooth en Android, iOS, Microsoft y Linux, impactando así casi todos los tipos de dispositivos Bluetooth como smartphones, laptops y smartwatches. BlueBorne fue analizado en detalle en un artículo publicado el 12 de septiembre de 2017 por Ben Seri y Gregor Vishnepolsk [22]. Se pueden utilizar ocho vulnerabilidades diferentes como parte del vector de ataque.

\ Con respecto a Android, todos los dispositivos y versiones (por lo tanto, versiones anteriores a Android Oreo, que se lanzó en diciembre de 2017) se ven afectados por las vulnerabilidades mencionadas anteriormente, excepto los dispositivos que admiten BLE (Bluetooth Low Energy). En general, se deben satisfacer dos requisitos para explotar la vulnerabilidad: (i) el dispositivo objetivo debe tener Bluetooth habilitado; (ii) el atacante debe estar lo suficientemente cerca del dispositivo objetivo. Como la función Bluetooth no está disponible en el Core Emulator, la cadena de ataque en cuestión solo puede reproducirse en dispositivos reales.

\ 1) Reproducción completa de BlueBorne en Dockerized Android: Para mostrar la efectividad de Dockerized Android, desarrollamos una cadena de ataque que explota dos vulnerabilidades de Ejecución Remota de Código (RCE) que afectan a Android, es decir, CVE-2017-0781 y CVE-2017-0782. Estas vulnerabilidades caen dentro del conjunto de vulnerabilidades de Bluetooth definido como "BlueBorne" y descubierto por un grupo de investigadores de seguridad de Armis Security [23].

\ El diagrama en la Fig. 4 proporciona una visión general de la cadena de ataque desarrollada:

\

1. El atacante crea un correo electrónico de phishing a través de Gophish, un software generador de phishing.

\ 2) El correo electrónico de phishing se envía al buzón de correo de una víctima.

\ 3) La víctima lee el correo electrónico de phishing y erróneamente hace clic en un enlace malicioso contenido en el cuerpo del correo electrónico.

\ 4) El enlace malicioso permite al atacante desencadenar un ataque que descarga e instala una aplicación falsa en el dispositivo móvil de la víctima.

\ 5) La información maliciosa envía información móvil relevante al atacante. Esta información es necesaria para la explotación de las dos vulnerabilidades.

\ 6) El atacante crea una carga útil maliciosa para explotar las vulnerabilidades.

\ 7) El atacante envía el ataque explotando las vulnerabilidades del componente Bluetooth y tiene acceso remoto al dispositivo de la víctima.

\

\ El escenario complejo cubre varias amenazas definidas en la Tabla I. La Tabla V muestra tales amenazas y tanto las funcionalidades de la plataforma como los componentes que permiten la reproducción del escenario. El

\

\ escenario requiere comunicaciones de red complejas (F07) e implica la utilización de Bluetooth. Por esta razón, tenemos que usar un dispositivo físico (F10). En el escenario propuesto, tenemos que simular la instalación de la aplicación maliciosa cuando el usuario recibe el correo electrónico. Esto se puede hacer manualmente (F02) o implementando scripts de utilidad ADB (F03). Para reproducir el escenario, se necesitan elementos adicionales:

\ • Gophish: una aplicación web que permite crear y enviar correos electrónicos de phishing, para la cual ya existe una versión Docker.

\ • Ghidra: una aplicación creada por la Agencia de Seguridad Nacional (NSA) para fines de ingeniería inversa. En este contexto, se utiliza para obtener información útil sobre el dispositivo objetivo. Esta aplicación se utiliza en la máquina host sin Docker.

\ • Fake Spotify: una aplicación aparentemente benigna que pretende proporcionar al usuario una versión gratuita de la conocida aplicación Spotify Premium, pero que envía al servidor del atacante archivos exfiltrados que son sometidos a ingeniería inversa en Ghidra. Además, esta aplicación fue creada sin el uso de Docker.

\

\ Está compuesto por cinco servicios, dos de los cuales son los subcomponentes de Dockerized Android. Los tres restantes se describen brevemente a continuación:

\ • attacker_phishing: contiene el componente Gophish utilizado para crear y enviar el correo electrónico de phishing que engaña al usuario para