Comment les performances d'Android dockerisé varient selon les différents systèmes d'exploitation

:::info Auteurs:

(1) Daniele Capone, SecSI srl, Naples, Italie (daniele.capone@secsi.io);

(2) Francesco Caturano, Département de génie électrique et des technologies de l'information, Université de Naples Federico II, Naples, Italie (francesco.caturano@unina.i)

(3) Angelo Delicato, SecSI srl, Naples, Italie (angelo.delicato@secsi.io);

(4) Gaetano Perrone, Département de génie électrique et des technologies de l'information, Université de Naples Federico II, Naples, Italie (gaetano.perrone@unina.it)

(5) Simon Pietro Romano, Département de génie électrique et des technologies de l'information, Université de Naples Federico II, Naples, Italie (spromano@unina.it).

:::

Table des liens

Résumé et I. Introduction

II. Travaux connexes

III. Dockerized Android : Conception

IV. Architecture Dockerized Android

V. Évaluation

VI. Conclusion et développements futurs, et références

V. ÉVALUATION

Cette section évalue la plateforme Dockerized Android en examinant plusieurs aspects. Tout d'abord, nous soulignons les différences entre les composants Core for Emulator et Core for Real Device en termes de fonctionnalités et mettons en évidence la compatibilité avec les trois systèmes d'exploitation les plus utilisés. Ensuite, nous fournissons des exemples pratiques d'utilisation de Dockerized Android et discutons de la couverture des exigences définies dans la section III.

\

\ A. Différences entre Core for Emulator et Core for Real Device

\ Même si un effort important a été consacré à la création d'un système qui possède les mêmes fonctionnalités pour les deux types d'appareils, il existe des limitations lorsque l'émulation est utilisée :

\ • Fonctionnalité d'envoi/réception SMS ADB : dans les appareils émulés, il est possible d'automatiser l'envoi et la réception de messages SMS via le logiciel ADB. Évidemment, cela n'est pas nativement possible pour les appareils réels. Par conséquent, l'utilisateur doit envoyer et recevoir manuellement des messages SMS pour mettre en œuvre des scénarios d'attaque par SMS. Une solution pour résoudre ce problème pourrait être la réalisation d'une application Android personnalisée qui pourrait être installée sur un appareil réel et pourrait être instrumentée pour envoyer et recevoir des messages automatiquement.

\ • Réseau : le réseau est assez différent entre les versions Emulator et Real device. Dans la version émulateur, l'AVD est créé à l'intérieur du conteneur Docker, et partage donc l'adresse IP du conteneur. En revanche, l'appareil réel est physiquement connecté à la machine qui exécute le conteneur et conserve sa propre adresse IP.

\ • Virtualisation matérielle : pour les composants matériels, la situation est également assez différente : certains dispositifs matériels comme le GPS et le microphone peuvent être émulés. En particulier, la localisation GPS de l'appareil peut être définie via ADB, et le microphone de la machine hôte peut être partagé avec l'émulateur. Il existe d'autres composants matériels qui ne peuvent actuellement pas être émulés, comme par exemple le Bluetooth.

\ B. Évaluation de l'hôte pour la compatibilité multiplateforme

\ L'exigence non fonctionnelle NF04 (Compatibilité multiplateforme) stipule que le système résultant devrait être utilisable depuis n'importe quel système d'exploitation hôte. Cela fait référence au système d'exploitation de la machine qui exécute les conteneurs Docker. Le tableau III fournit un résumé de la compatibilité avec Linux, Windows et OS X.

\

\ Le problème avec Windows est qu'actuellement, la meilleure façon d'utiliser Docker est via le framework Windows Subsystem for Linux (WSL). Malheureusement, WSL ne prend pas encore en charge la virtualisation imbriquée, et cette fonctionnalité est nécessaire pour exécuter l'émulateur Android dans un conteneur Docker. Cependant, cette fonctionnalité sera disponible dans les prochaines versions de WSL. Il pourrait être possible d'exécuter la version Core for Emulator sur Windows en utilisant une machine virtuelle, bien que cela fasse perdre tous les avantages de performance associés à la conteneurisation. Un problème similaire existe avec OS X, avec lequel il n'y a actuellement aucun moyen d'exécuter le Core for Emulator. De plus, OS X ne permet pas de partager le périphérique USB avec un conteneur Docker. Pour cette raison, les seules façons d'utiliser la version Core for Real Device sont soit d'exécuter ADB via Wi-Fi, soit de se connecter à l'ADB de l'hôte depuis le conteneur Docker.

\ Dans la suite de cette section, nous montrons l'efficacité de Dockerized Android pour reproduire des chaînes d'attaques de sécurité en utilisant à la fois le Core for Emulator et le Core for Real Device.

\ C. Reproduction d'attaque de sécurité sur l'émulateur

\ Nous nous concentrons ici sur un scénario de vulnérabilité associé à CVE-2018-7661[1]. Cette CVE est liée à la version gratuite de l'application "Wi-Fi Baby Monitor". Cette application doit être installée sur deux appareils afin d'agir comme un moniteur pour bébé (un système radio utilisé pour écouter à distance les sons émis par un nourrisson). Comme indiqué dans la National Vulnerability Database, "Wi-Fi Baby Monitor Free & Lite" avant la version 2.02.2 permet aux attaquants distants d'obtenir des données audio via certaines requêtes spécifiques aux numéros de port TCP 8258 et 8257".

\

\ La version premium de cette application offre aux utilisateurs la possibilité de spécifier un mot de passe à utiliser dans le processus d'appairage. En surveillant le trafic réseau, il est possible d'observer que :

\ • la connexion initiale a lieu sur le port 8257 ;

\ • la même séquence est toujours envoyée pour démarrer le processus d'appairage ;

\ • à la fin du processus d'appairage, une nouvelle connexion est établie sur le port 8258. Ce port est utilisé pour transmettre les données audio ;

\ • après la connexion au port 8258, l'autre connexion sur le port 8257 reste ouverte et est utilisée comme battement de cœur pour la session ;

\ • sur la connexion de battement de cœur, le client envoie périodiquement l'octet hexadécimal 0x01 (environ une fois par seconde) ;

\ La preuve de concept qui permet à l'attaquant d'obtenir des données audio est donnée dans [21]. Cette preuve de concept (PoC) est facilement reproductible sur Dockerized Android grâce à la réalisation d'une infrastructure composée de trois services :

\ • core-emulator : une instance du composant Core avec une application Baby Monitor préinstallée agissant comme émetteur ;

\ • ui : le composant UI pour contrôler ce qui se passe ;

\ • attacker : une version personnalisée de Kali Linux qui installe automatiquement toutes les dépendances nécessaires à l'exécution du PoC.

\ C'est également un exemple parfait pour montrer la fonctionnalité de redirection de port utilisée pour permettre les communications.

\ D. Reproduction d'attaque de sécurité sur l'appareil réel

\ Avec l'appareil réel, nous examinons une autre vulnérabilité, connue sous le nom de BlueBorne. Le terme "BlueBorne" fait référence à plusieurs vulnérabilités de sécurité liées à l'implémentation du Bluetooth. Ces vulnérabilités ont été découvertes par un groupe de chercheurs d'Armis Security, une entreprise de sécurité IoT, en septembre 2017. Selon Armis, au moment de la découverte, environ 8,2 milliards d'appareils étaient potentiellement affectés par le vecteur d'attaque BlueBorne, qui affecte les implémentations Bluetooth dans Android, iOS, Microsoft et Linux, impactant ainsi presque tous les types d'appareils Bluetooth tels que les smartphones, les ordinateurs portables et les montres connectées. BlueBorne a été analysé en détail dans un article publié le 12 septembre 2017 par Ben Seri et Gregor Vishnepolsk [22]. Huit vulnérabilités différentes peuvent être utilisées dans le cadre du vecteur d'attaque.

\ Concernant Android, tous les appareils et versions (donc les versions antérieures à Android Oreo, qui a été publié en décembre 2017) sont affectés par les vulnérabilités mentionnées ci-dessus, à l'exception des appareils qui prennent en charge le BLE (Bluetooth Low Energy). En général, deux exigences doivent être satisfaites pour exploiter la vulnérabilité : (i) l'appareil cible doit avoir le Bluetooth activé ; (ii) l'attaquant doit être suffisamment proche de l'appareil cible. Comme la fonctionnalité Bluetooth n'est pas disponible dans le Core Emulator, la chaîne d'attaque en question ne peut être reproduite que sur des appareils réels.

\ 1) Reproduction complète de BlueBorne sur Dockerized Android : Afin de montrer l'efficacité de Dockerized Android, nous avons développé une chaîne d'attaque qui exploite deux vulnérabilités d'exécution de code à distance (RCE) qui affectent Android, à savoir CVE-2017-0781 et CVE-2017-0782. Ces vulnérabilités font partie de l'ensemble de vulnérabilités Bluetooth défini comme "BlueBorne" et découvert par un groupe de chercheurs en sécurité d'Armis Security [23].

\ Le diagramme de la Fig. 4 donne un aperçu de la chaîne d'attaque développée :

\

1. L'attaquant crée un e-mail de phishing via Gophish, un logiciel générateur de phishing.

\ 2) L'e-mail de phishing est envoyé à la boîte aux lettres d'une victime.

\ 3) La victime lit l'e-mail de phishing et clique par erreur sur un lien malveillant contenu dans le corps de l'e-mail.

\ 4) Le lien malveillant permet à l'attaquant de déclencher une attaque qui télécharge et installe une fausse application sur l'appareil mobile de la victime.

\ 5) Les informations malveillantes envoient des informations pertinentes sur le mobile à l'attaquant. Ces informations sont nécessaires pour l'exploitation des deux vulnérabilités.

\ 6) L'attaquant crée une charge utile malveillante pour exploiter les vulnérabilités.

\ 7) L'attaquant envoie l'attaque en exploitant les vulnérabilités du composant Bluetooth et a un accès à distance à l'appareil de la victime.

\

\ Le scénario complexe couvre plusieurs menaces définies dans le tableau I. Le tableau V montre ces menaces ainsi que les fonctionnalités et les composants de la plateforme qui permettent la reproduction du scénario. Le

\

\ scénario nécessite des communications réseau complexes (F07) et implique l'utilisation du Bluetooth. Pour cette raison, nous devons utiliser un appareil physique (F10). Dans le scénario proposé, nous devons simuler l'installation de l'application malveillante lorsque l'utilisateur reçoit l'e-mail. Cela peut être fait soit manuellement (F02), soit en implémentant des scripts ADB utilitaires (F03). Pour reproduire le scénario, des éléments supplémentaires sont nécessaires :

\ • Gophish : une application web qui permet de créer et d'envoyer des e-mails de phishing, pour laquelle une version Docker existe déjà.

\ • Ghidra : une application créée par la National Security Agency (NSA) à des fins de rétro-ingénierie. Dans ce contexte, elle est utilisée pour obtenir des informations utiles sur l'appareil cible. Cette application est utilisée sur la machine hôte sans Docker.

\ • Fake Spotify : une application apparemment bénigne qui prétend fournir à l'utilisateur une version grat