Objectif
Exploiter la vulnérabilité d’un Broadcast Receiver. Votre mission consiste à manipuler la fonctionnalité du Broadcast Receiver dans l’application Android « IOT Connect », ce qui vous permet d’activer l’interrupteur principal et de contrôler tous les appareils connectés. Le défi consiste à envoyer une diffusion d’une manière qui ne soit pas réalisable par l’utilisateur invité.
Outil
Installation
Pour commencer, nous allons installer l’application sur un périphérique virtuel (bien que cela fonctionne également avec les périphériques physiques), le tout grâce à ADB :
$ adb install com.mobilehackinglab.iotconnect.apk
Performing Streamed Install
SuccessL’application est installée avec succès et se lance parfaitement ! Une fois un compte créé, nous tentons de cliquer sur le bouton « Master Switch » afin d’activer l’interrupteur principal :
Néanmoins, via l’interface graphique, il n’est pas possible d’activer ce bouton. En effet, cette fonctionnalité n’est pas accessible aux « guests » (d’après la ligne 30 du fichier com.mobilehackinglab.iotconnect.MasterSwitchActivity) :
Il serait possible de contourner cette protection grâce à une modification du code Smali et une recompilation de l’application et/ou une introspection mémoire avec Frida, néanmoins, on va jouer le jeu et laisser cette vérification en l’état.
En effet, il est possible de voir que le Broadcast Receiver est exécuté ligne 37, après cette vérification lorsqu’un PIN est entré. Un Broadcast Receiver mal configuré pourrait ainsi permettre à un attaquant ou une application malveillante de contourner cette protection.
Fichier AndroidManifest.xml
Au sein du fichier AndroidManifest.xml, il est possible d’identifier un Broadcast Receiver exporté (com.mobilehackinglab.iotconnect.MasterReceiver) et donc accessible :
Lorsqu’un Broadcast Receiver est déclaré statiquement, l’intent-filter permet de déclarer quelle(s) action(s) (« MASTER_ON ») ce dernier est en mesure de recevoir, par le biais d’Intent.
Grâce à l’export, d’autres applications sont en mesure d’interagir avec le Broadcast Receiver de la manière suivante : adb shell am broadcast -a MASTER_ON
En cherchant « masterReceiver » ou bien « MASTER_ON » au sein du code source de l’application décompilé avec Jadx-gui, il est possible d’identifier le message que nous souhaitons obtenir (« All devices are turned on ») au sein du fichier com.mobilehackinglab.iotconnect.CommunicationManager :
Il est possible de constater qu’il n’y a plus de contrôle si l’utilisateur est un guest ou non.
Néanmoins, pour arriver à ce message, plusieurs contrôles sont en place :
- Ligne 25
Ce contrôle vérifie qu’un Intent existe (qu’il n’est pas null) et que l’action associée est bien « MASTER_ON ».
- Ligne 28
Ce contrôle vérifie que la clé (key) reçue sous forme d’extra (getIntExtra(‘key’, 0)) est égale à celle spécifiée au sein de la fonction check_key(). Cette fonction est accessible au sein de defpackage.Checker :
L’action précédemment spécifiée ainsi que l’extra key étant un entier permettent d’affiner la commande à exécuter pour faire appel au Broadcast Receiver en question : adb shell am broadcast -a MASTER_ON –ei key <PIN>
Tentons avec un code PIN aléatoire :
Ainsi, le message d’erreur indique bien que nous avons été en mesure de contourner la vérification du type d’utilisateur est que nous sommes directement présents en ligne 32 du fichier com.mobilehackinglab.iotconnect.CommunicationManager signifiant que la condition ligne 26 (vérification du PIN) n’est pas vérifiée.
Disposant de l’ensemble des éléments cryptographiques au sein du code source de l’application, il est possible de créer un rapide script python permettant de bruteforcer la clé de chiffrement :
Grâce à cette clé, il est alors possible de faire appel à notre Broadcast Receiver avec le bon PIN grâce à la commande suivante : adb shell am broadcast -a MASTER_ON –ei key <PIN>
