In the dynamic world of software development and security testing, the ability to replicate environments accurately and efficiently is paramount. Docker, with its lightweight containerization technology, has revolutionized how applications are built, shipped, and run. But what happens when you combine this power with Android, a ubiquitous operating system powering billions of devices? Enter Dockerized Android – a novel approach designed to streamline Android development, testing, and security analysis.
This innovative platform promises greater agility and consistency. However, like any powerful technology, its performance and compatibility can vary significantly depending on the underlying operating system. Understanding these nuances is crucial for developers and security professionals looking to leverage Dockerized Android effectively across different host environments. Let’s delve into how this solution performs across various operating systems, uncovering its strengths and limitations.
:::info
Authors:
(1) Daniele Capone, SecSI srl, Napoli, Italy (daniele.capone@secsi.io);
(2) Francesco Caturano, Dept. of Electrical Engineering and Information, Technology University of Napoli Federico II, Napoli, Italy (francesco.caturano@unina.i)
(3) Angelo Delicato, SecSI srl, Napoli, Italy (angelo.delicato@secsi.io);
(4) Gaetano Perrone, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy (gaetano.perrone@unina.it)
(5) Simon Pietro Romano, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy (spromano@unina.it).
:::
Understanding Dockerized Android: Emulator vs. Real Devices
The Dockerized Android platform distinguishes between two core components: the Core for Emulator and the Core for Real Device. While significant effort has been invested to ensure feature parity, inherent differences in how these components interact with hardware and software introduce specific limitations, particularly when relying on emulation for Android testing scenarios.
For instance, SMS message automation via ADB (Android Debug Bridge) is seamless with emulated devices. You can easily script the sending and reception of SMS messages for automated testing. However, real physical devices require manual intervention for SMS attack scenarios, though a custom Android application could offer a workaround.
Networking also presents distinct characteristics. An Android Virtual Device (AVD) created within a Docker container shares the container’s IP address, simplifying network configuration for virtual setups. Conversely, a real device connected to the host machine retains its own IP address, which requires different networking considerations.
Hardware virtualization capabilities further differentiate the two cores. Features like GPS location and microphone input can be effectively emulated, allowing testers to manipulate GPS coordinates via ADB or share the host machine’s microphone. Yet, some hardware components, such as Bluetooth, remain challenging to emulate within a Docker container, limiting certain types of mobile security testing to physical devices.
Cross-Platform Performance: Navigating OS Compatibility
A crucial non-functional requirement for Dockerized Android is its cross-platform compatibility, ensuring usability across various host operating systems. The system aims to perform seamlessly on the three most common OS environments: Linux, Windows, and macOS (OS X). However, practical implementation reveals varying levels of support and unique challenges for each.
Linux generally offers the most robust support for Dockerized Android, benefiting from Docker’s native integration and strong virtualization capabilities. Developers and security analysts typically experience fewer hurdles when running both emulator and real-device cores on Linux-based systems, making it a preferred environment for advanced Android containerization.
Windows environments present a more complex scenario. The recommended way to run Docker on Windows is through the Windows Subsystem for Linux (WSL) framework. Unfortunately, WSL currently lacks support for nested virtualization, a feature essential for running the Android emulator inside a Docker container. This limitation means that the Core for Emulator flavor cannot run directly on Windows via WSL, though this capability is anticipated in future WSL releases. A potential workaround involves using a traditional virtual machine on Windows, but this would negate many of the performance advantages associated with containerization.
macOS faces similar challenges. Currently, there is no straightforward way to run the Core for Emulator on OS X due to architectural constraints. Furthermore, macOS restricts sharing USB devices directly with Docker containers, which complicates the use of the Core for Real Device. To circumvent this, users must either configure ADB over Wi-Fi or establish a connection to the host ADB from within the Docker container. These workarounds, while functional, introduce additional setup complexities for Mac users interested in Dockerized Android.
Practical Applications: Leveraging Dockerized Android for Security Testing
Despite the compatibility nuances across operating systems, Dockerized Android proves highly effective in reproducing complex security kill chains, demonstrating its value in mobile security research and vulnerability assessment. The platform’s flexibility allows for the creation of intricate test environments, whether utilizing an emulator or a real device.
Emulating Vulnerabilities: The Wi-Fi Baby Monitor Case
One compelling example involves reproducing a vulnerability associated with CVE-2018-7661, affecting the “Wi-Fi Baby Monitor” application. This vulnerability allows remote attackers to obtain audio data through specific requests to TCP ports 8257 and 8258. Dockerized Android facilitates the recreation of this scenario through a multi-service infrastructure.
This setup typically includes a ‘core-emulator’ instance with the vulnerable Baby Monitor app installed as the sender, a ‘ui’ component for control, and an ‘attacker’ service running a customized Kali Linux image. The Kali Linux instance automatically installs all necessary dependencies for executing the Proof of Concept (PoC) outlined in the research. This showcases Dockerized Android’s Port Forwarding feature, enabling seamless communication within the simulated attack environment.
Real-Device Exploitation: Unpacking BlueBorne
For vulnerabilities that demand direct hardware interaction, such as BlueBorne, a collection of Bluetooth-related security flaws (e.g., CVE-2017-0781 and CVE-2017-0782), Dockerized Android pivots to the Core for Real Device. Since Bluetooth emulation is not feasible within the container, a physical device is essential to demonstrate the attack vector.
A full BlueBorne kill chain involves multiple steps: an attacker crafts a phishing email using Gophish, which leads the victim to download a malicious ‘Fake Spotify’ application. This app exfiltrates crucial device information to the attacker. The attacker then uses this data, potentially after reverse engineering with Ghidra, to craft a malicious payload. Finally, the attacker exploits Bluetooth vulnerabilities to gain remote access to the victim’s device, highlighting the platform’s ability to orchestrate complex, multi-stage attacks involving external tools and real hardware.
This elaborate scenario requires several Dockerized services: ‘attacker_phishing’ for email generation, ‘attackerwebserver’ to receive exfiltrated files, and ‘attacker_blueborne’ to execute the Bluetooth exploit. The platform’s native support for complex network configurations (F07) and seamless integration with third-party tools (F09) through Docker is invaluable for such detailed security assessments.
Conclusion
Dockerized Android represents a significant step forward in streamlining Android development and security testing, offering a containerized, reproducible environment for various scenarios. While there are distinct differences between the emulator and real device cores, particularly concerning SMS, networking, and hardware virtualization, the platform generally delivers on its promise of flexibility.
Cross-platform compatibility varies, with Linux offering the most straightforward experience. Windows and macOS users currently face limitations, especially with emulator support due to virtualization constraints. However, ongoing developments in technologies like WSL promise improved integration in the future. Despite these hurdles, Dockerized Android excels in practical applications, enabling the precise reproduction of complex security vulnerabilities, from emulated Wi-Fi attacks to real-device Bluetooth exploits like BlueBorne.
By providing a consistent and isolated environment, Dockerized Android empowers developers and security researchers to innovate and secure the Android ecosystem more effectively. As containerization technology continues to evolve, so too will the capabilities of Dockerized Android, making it an indispensable tool for anyone working with the world’s most popular mobile operating system.
:::info
This paper is available on arxiv under CC by-SA 4.0 Deed (Attribution-Sahrealike 4.0 International license.
:::
