Wie Dockerisiertes Android auf verschiedenen Betriebssystemen funktioniert

:::info Autoren:

(1) Daniele Capone, SecSI srl, Neapel, Italien (daniele.capone@secsi.io);

(2) Francesco Caturano, Abteilung für Elektrotechnik und Information, Technische Universität Neapel Federico II, Neapel, Italien (francesco.caturano@unina.i)

(3) Angelo Delicato, SecSI srl, Neapel, Italien (angelo.delicato@secsi.io);

(4) Gaetano Perrone, Abteilung für Elektrotechnik und Informationstechnologie, Universität Neapel Federico II, Neapel, Italien (gaetano.perrone@unina.it)

(5) Simon Pietro Romano, Abteilung für Elektrotechnik und Informationstechnologie, Universität Neapel Federico II, Neapel, Italien (spromano@unina.it).

:::

Inhaltsverzeichnis

Zusammenfassung und I. Einleitung

II. Verwandte Arbeiten

III. Dockerized Android: Design

IV. Dockerized Android Architektur

V. Bewertung

VI. Fazit und zukünftige Entwicklungen sowie Referenzen

V. BEWERTUNG

Dieser Abschnitt bewertet die Dockerized Android-Plattform durch Untersuchung verschiedener Aspekte. Zunächst betonen wir die Unterschiede zwischen den Komponenten Core für Emulator und Core für reale Geräte in Bezug auf Funktionen und heben die Kompatibilität mit den drei am häufigsten verwendeten Betriebssystemen hervor. Anschließend stellen wir praktische Anwendungsbeispiele von Dockerized Android vor und diskutieren die Abdeckung der in Abschnitt III definierten Anforderungen.

\

\ A. Unterschiede zwischen Core für Emulator und Core für reale Geräte

\ Auch wenn erhebliche Anstrengungen unternommen wurden, um ein System zu schaffen, das für beide Arten von Geräten die gleichen Funktionen bietet, gibt es Einschränkungen bei der Verwendung der Emulation:

\ • SMS ADB Sende-/Empfangsfunktion: Bei emulierten Geräten ist es möglich, das Senden und Empfangen von SMS-Nachrichten über die ADB-Software zu automatisieren. Offensichtlich ist dies für reale Geräte nicht nativ möglich. Daher muss der Benutzer SMS-Nachrichten manuell senden und empfangen, um SMS-Angriffsszenarien zu implementieren. Eine Lösung für dieses Problem könnte die Realisierung einer benutzerdefinierten Android-Anwendung sein, die auf einem realen Gerät installiert werden könnte und so instrumentiert werden könnte, dass sie automatisch Nachrichten sendet und empfängt.

\ • Netzwerk: Das Netzwerk ist zwischen dem Emulator und den Varianten für reale Geräte recht unterschiedlich. In der Emulator-Version wird das AVD innerhalb des Docker-Containers erstellt und teilt daher die IP-Adresse des Containers. Stattdessen ist das reale Gerät physisch mit dem Rechner verbunden, der den Container ausführt, und behält seine eigene IP-Adresse bei.

\ • Hardware-Virtualisierung: Für die Hardware-Komponenten ist die Situation ebenfalls recht unterschiedlich: Einige Hardware-Geräte wie GPS und Mikrofon können emuliert werden. Insbesondere kann der GPS-Standort des Geräts über ADB eingestellt werden, und das Mikrofon des Host-Rechners kann mit dem Emulator geteilt werden. Es gibt andere Hardware-Komponenten, die derzeit nicht emuliert werden können, wie z.B. Bluetooth.

\ B. Host-Bewertung für plattformübergreifende Kompatibilität

\ Die nicht-funktionale Anforderung NF04 (plattformübergreifende Kompatibilität) besagt, dass das resultierende System von jedem Host-Betriebssystem aus nutzbar sein sollte. Dies bezieht sich auf das Betriebssystem des Rechners, der die Docker-Container ausführt. Tabelle III bietet eine Zusammenfassung der Kompatibilität mit Linux, Windows und OS X.

\

\ Das Problem mit Windows ist, dass derzeit der beste Weg, Docker zu nutzen, über das Windows Subsystem for Linux (WSL)-Framework führt. Leider unterstützt WSL noch keine verschachtelte Virtualisierung, und diese Funktion ist erforderlich, um den Android-Emulator innerhalb eines Docker-Containers auszuführen. Diese Funktion wird jedoch in kommenden WSL-Versionen verfügbar sein. Es könnte möglich sein, die Core für Emulator-Variante unter Windows mit einer virtuellen Maschine auszuführen, wobei jedoch alle Leistungsvorteile der Containerisierung verloren gehen. Ein ähnliches Problem besteht bei OS X, mit dem es derzeit keine Möglichkeit gibt, den Core für Emulator auszuführen. Außerdem erlaubt OS X nicht, das USB-Gerät mit einem Docker-Container zu teilen. Aus diesem Grund sind die einzigen Möglichkeiten, die Core für reale Geräte-Variante zu nutzen, entweder ADB über Wi-Fi auszuführen oder vom Docker-Container aus eine Verbindung zum Host-ADB herzustellen.

\ Im weiteren Verlauf dieses Abschnitts zeigen wir die Wirksamkeit von Dockerized Android bei der Reproduktion von Security-Kill-Chains unter Verwendung sowohl des Core für Emulator als auch des Core für reale Geräte.

\ C. Reproduktion von Sicherheitsangriffen auf dem Emulator

\ Wir konzentrieren uns hier auf ein Beispiel-Schwachstellenszenario im Zusammenhang mit CVE-2018-7661[1]. Diese CVE bezieht sich auf die kostenlose Version der Anwendung "Wi-Fi Baby Monitor". Diese Anwendung muss auf zwei Geräten installiert werden, um als sogenannter Babymonitor (ein Funksystem zur Fernüberwachung von Geräuschen eines Säuglings) zu fungieren. Wie in der National Vulnerability Database berichtet, "erlaubt 'Wi-Fi Baby Monitor Free & Lite' vor Version 2.02.2 Angreifern aus der Ferne, Audiodaten über bestimmte spezifische Anfragen an die TCP-Portnummern 8258 und 8257 zu erhalten".

\

\ Die Premium-Version dieser Anwendung bietet Benutzern die Möglichkeit, ein Passwort für den Kopplungsprozess anzugeben. Durch die Überwachung des Netzwerkverkehrs ist es möglich zu beobachten, dass:

\ • die erste Verbindung auf Port 8257 stattfindet;

\ • immer die gleiche Sequenz gesendet wird, um den Kopplungsprozess zu starten;

\ • am Ende des Kopplungsprozesses eine neue Verbindung auf Port 8258 gestartet wird. Dieser Port wird zur Übertragung der Audiodaten verwendet;

\ • nach dem Verbinden mit Port 8258 die andere Verbindung auf Port 8257 offen gehalten und als Heartbeat für die Sitzung verwendet wird;

\ • bei der Heartbeat-Verbindung der Client periodisch das hexadezimale Byte 0x01 sendet (etwa einmal pro Sekunde);

\ Der Proof of Concept, der es dem Angreifer ermöglicht, Audiodaten zu erhalten, wird in [21] gegeben. Dieser Proof of Concept (PoC) ist auf Dockerized Android leicht reproduzierbar durch die Realisierung einer Infrastruktur, die aus drei Diensten besteht:

\ • core-emulator: eine Instanz der Core-Komponente mit einer vorinstallierten Baby Monitor-App, die als Sender fungiert;

\ • ui: die UI-Komponente zur Kontrolle des Geschehens;

\ • attacker: eine angepasste Version von Kali Linux, die automatisch alle für die Ausführung des PoC benötigten Abhängigkeiten installiert.

\ Dies ist auch ein perfektes Beispiel, um die Port-Forwarding-Funktion zu zeigen, die zur Ermöglichung der Kommunikation verwendet wird.

\ D. Reproduktion von Sicherheitsangriffen auf dem realen Gerät

\ Mit dem realen Gerät untersuchen wir eine weitere Schwachstelle, bekannt als BlueBorne. Der Begriff "BlueBorne" bezieht sich auf mehrere Sicherheitslücken im Zusammenhang mit der Implementierung von Bluetooth. Diese Schwachstellen wurden im September 2017 von einer Gruppe von Forschern von Armis Security, einem IoT-Sicherheitsunternehmen, entdeckt. Laut Armis waren zum Zeitpunkt der Entdeckung rund 8,2 Milliarden Geräte potenziell vom BlueBorne-Angriffsvektor betroffen, der die Bluetooth-Implementierungen in Android, iOS, Microsoft und Linux betrifft und damit fast alle Bluetooth-Gerätetypen wie Smartphones, Laptops und Smartwatches beeinträchtigt. BlueBorne wurde in einem am 12. September 2017 von Ben Seri und Gregor Vishnepolsk [22] veröffentlichten Papier detailliert analysiert. Acht verschiedene Schwachstellen können als Teil des Angriffsvektors genutzt werden.

\ In Bezug auf Android sind alle Geräte und Versionen (daher Versionen älter als Android Oreo, das im Dezember 2017 veröffentlicht wurde) von den oben genannten Schwachstellen betroffen, mit Ausnahme von Geräten, die BLE (Bluetooth Low Energy) unterstützen. Im Allgemeinen müssen zwei Anforderungen erfüllt sein, um die Schwachstelle auszunutzen: (i) Das Zielgerät muss Bluetooth aktiviert haben; (ii) der Angreifer muss nahe genug am Zielgerät sein. Da die Bluetooth-Funktion im Core Emulator nicht verfügbar ist, kann die betreffende Kill-Chain nur auf realen Geräten reproduziert werden.

\ 1) Vollständige Reproduktion von BlueBorne auf Dockerized Android: Um die Wirksamkeit von Dockerized Android zu zeigen, haben wir eine Kill-Chain entwickelt, die zwei Remote Code Execution (RCE)-Schwachstellen ausnutzt, die Android betreffen, nämlich CVE-2017-0781 und CVE-2017-0782. Diese Schwachstellen fallen in den Bluetooth-Schwachstellensatz, der als "BlueBorne" definiert wurde und von einer Gruppe von Sicherheitsforschern von Armis Security [23] entdeckt wurde.

\ Das Diagramm in Abb. 4 gibt einen Überblick über die entwickelte Kill-Chain:

\

1. Der Angreifer erstellt eine Phishing-E-Mail über Gophish, eine Phishing-Generator-Software.

\ 2) Die Phishing-E-Mail wird an das Postfach des Opfers gesendet.

\ 3) Das Opfer liest die Phishing-E-Mail und klickt irrtümlich auf einen bösartigen Link im E-Mail-Text.

\ 4) Der bösartige Link ermöglicht es dem Angreifer, einen Angriff auszulösen, der eine gefälschte Anwendung auf das Mobilgerät des Opfers herunterlädt und installiert.

\ 5) Die bösartigen Informationen senden relevante Mobilgerätinformationen an den Angreifer. Diese Informationen sind für die Ausnutzung der beiden Schwachstellen erforderlich.

\ 6) Der Angreifer erstellt eine bösartige Nutzlast, um die Schwachstellen auszunutzen.

\ 7) Der Angreifer sendet den Angriff, indem er die Schwachstellen der Bluetooth-Komponente ausnutzt und erhält Fernzugriff auf das Gerät des Opfers.

\

\ Das komplexe Szenario deckt mehrere in Tabelle I definierte Bedrohungen ab. Tabelle V zeigt diese Bedrohungen und sowohl die Plattformfunktionalitäten als auch Komponenten, die die Szenarioreproduktion ermöglichen. Das

\

\ Szenario erfordert komplexe Netzwerkkommunikation (F07) und beinhaltet die Nutzung von Bluetooth. Aus diesem Grund müssen