Hacker's Cookbook : Exploiter les appareils électroménagers connectés à l'IoT avec WHIDBOARD

AVIDES DE HACKING MATÉRIEL

J'ai récemment terminé la R&D d'un nouveau jouet appelé WHIDBOARD et, pour le tester, j'ai décidé de jeter un œil à un appareil de cuisine IoT que j'ai acheté d'occasion sur Amazon. Le résultat a été étonnamment hilarant !

La cible

Le DUT (Device Under Test) de cet article de blog est un appareil de cuisine intelligent appelé Mambo Touch, fabriqué par la société espagnole Cecotec.

Cet appareil de cuisine tout-en-un est un robot multifonction doté de 37 fonctions, d'un écran tactile de 5 pouces et pouvant être contrôlé à distance via son application mobile (comme vous pouvez le voir sur les images ci-dessous). Il se connecte via un réseau WiFi.

Comme le modèle reconditionné était moins cher... et que je ne l'utiliserai de toute façon jamais pour cuisiner... je me suis laissé tenter !

Reconditionné ≠ Réinitialisation d'usine

En général, Amazon autorise les clients à retourner certains articles qui ne leur plaisent pas ou qui ne répondent pas à leurs attentes...

Cependant, une question légitime se pose... où finissent-ils ensuite ? Comment sont-ils reconditionnés ? Qu'en est-il de la réinitialisation d'usine AVANT la revente ?

Après l'avoir allumé, je me suis connecté à mon réseau WiFi et j'ai essayé de le coupler avec l'application mobile... mais un événement surprenant s'est produit. Le DUT était déjà couplé avec un autre propriétaire (probablement l'ancien)...

Je me demande ce qu'un DPO dirait à ce sujet...

Démontage du DUT

D'après une première inspection de l'extérieur, il est possible de remarquer un premier indice... un port micro USB caché.

Cependant, rien de très intéressant ne se produit une fois branché à un ordinateur... L'étape suivante consistait à ouvrir la cible... et parmi tous les autres composants (écran tactile, commutateurs, capteurs, moteurs, alimentation électrique, etc.), j'ai été accueilli par la carte mère.

Ici, nous pouvons facilement repérer les principaux composants :

• SoC Amlogic A213Y
• KLM8G1GETF-B041 est une mémoire flash eMMC de 8 Go avec un encombrement FBGA-153
• RS256M16V0DB-107AT DDR SDRAM avec empreinte FBGA-96

Et également quelques points d'entrée intéressants pour les interfaces de débogage...

Cependant, le point d'entrée le plus intéressant se trouvait de l'autre côté... quelques pads de test étiquetés avec le brochage habituel de l'interface de débogage UART... (c'est-à-dire GND, RX, TX).

L'étape suivante était simple... souder quelques fils sur ces pads, prendre ma WHIDBOARD et vérifier avec le Logic Analyzer et le Pin Enumerator s'il s'agissait bien d'une interface de débogage UART...

Tout d'abord, j'ai connecté tous les fils au bornier de l'analyseur logique de la carte WHIDBOARD afin de récupérer certaines données... et voici ce que j'ai obtenu sur Pulseview :

Obtenir les droits root via UART

Excellent ! Nous avons facilement confirmé que les 3 pads de test à l'arrière du circuit imprimé sont effectivement une console UART fonctionnelle. Nous pouvons voir le DUT afficher la séquence de démarrage depuis le Logic Analyzer. Ensuite, essayons de connecter directement le WHIDBOARD et le Pin Enumerator.

La fonctionnalité Pin Enumerator de WHIDBOARD est basée sur le JTAGulator (malheureusement en fin de vie) créé par Joe Grand. Elle vous permet de découvrir les broches des interfaces de débogage telles que UART, JTAG et SWD. Cependant, dans mon cas, j'ai principalement utilisé sa fonction Passthrough pour communiquer avec la cible connectée à son bornier (et bien sûr confirmer la bonne combinaison de broches UART).

Une fois confirmé avec le Pin Enumerator que j'étais bien face à un port de débogage UART, j'ai utilisé la fonction Passthrough et j'ai été accueilli par une charmante console terminale avec accès root.

Et maintenant ?

À ce stade, nous voyons clairement que l'appareil peut être facilement compromis. Cependant, je souhaitais continuer à explorer et vérifier comment fonctionne la connexion à distance...

Tout d'abord, j'ai activé la connexion à distance ADB via WiFi à l'aide des commandes suivantes :

Et j'ai vérifié que tout fonctionnait parfaitement :

Nous disposons désormais d'une connexion persistante à distance (c'est-à-dire sur le même réseau local) avec le DUT. Le démon du serveur ADB persistera même après le démarrage.

L'étape suivante consistait à effectuer une reconnaissance et à rechercher des informations intéressantes... J'ai d'abord répertorié les applications installées afin de vérifier deux éléments : quelle version d'Android est utilisée et quelles sont les principales applications du fournisseur (à savoir Cecotec).

Les deux applications les plus intéressantes sont :

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

Cependant, avant de poursuivre mes vérifications, j'ai rapidement lancé l'application habituelle Paramètres Android (avec cette commande am start -n com.android.settings/.Settings) pour obtenir plus d'informations sur la version du système d'exploitation... et comme prévu, le DUT fonctionnait sous une ancienne version d'Android : 4.4.2.

Très bien... poursuivons nos investigations... Il est temps de reconstituer le réseau ! En examinant la sortie netstat, je constate certaines connexions avec des adresses IP Internet :

Rien de très sophistiqué, mais l'une d'entre elles a éveillé ma curiosité... Évidemment, comme il s'agit d'un backend qui ne m'appartient pas, j'ai considéré que cela ne relevait pas de ma compétence et j'ai poursuivi mes recherches...

Ensuite, j'ai commencé à rechercher les outils habituels utilisés par les hackers pour exfiltrer ou inverser les cibles IoT... un pour tous... Sa Majesté BUSYBOX :D

Et en fait, celui-ci était livré avec tout ce qu'il fallait :

Grâce à lui, je pouvais exfiltrer, télécharger, manipuler des données et également obtenir un shell inversé avec netcat. Mais continuons ! Puisque nous avons déjà un shell ADB persistant... nous n'avons pas besoin de BusyBox cette fois-ci. :P

Dans l'ensemble, avec ADB Explorer, j'ai extrait tous les fichiers intéressants que j'ai pu trouver. Cependant, rien de très intéressant... Cet appareil n'a ni microphone ni caméra... nous ne pouvons même pas espionner les gens à distance... hmm... :(

Analyse des APK

À ce stade, j'ai concentré mon attention sur les APK du fournisseur :

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

Le com.zavier.androidrk3326functiontest-1.apk semble être une suite de tests fonctionnels permettant de vérifier si tous les capteurs et les pilotes de moteur fonctionnent correctement. Il convient de noter que cet appareil de cuisine IoT est équipé d'une balance intégrée, d'un chauffage, d'un moteur pour mélanger les aliments et de divers capteurs. Apparemment, tous ces éléments sont contrôlés par ces deux applications (également à distance par l'utilisateur à l'aide de son téléphone portable...).

En ce qui concerne le com.kitchenidea.cecotec.k2501-2.apk , j'ai rapidement remarqué qu'il s'agissait d'une copie de l'autre update.apk disponible dans /sdcard/, il n'est donc pas nécessaire de vérifier les deux :

En examinant ce deuxième APK, je n'ai pas relevé d'éléments particulièrement suspects, mais cela a confirmé que l'application avait un accès complet à tous les capteurs, au chauffage, au moteur, etc. En théorie, nous pourrions créer un logiciel malveillant capable de perturber la victime à distance en envoyant des commandes arbitraires sur les ports série...

J'ai également vérifié s'il y avait d'autres URL/IP intéressantes codées en dur dans ces deux applications, mais il semble qu'il s'agisse de données sans importance habituelles :

Comme j'étais en retard et agacé, j'ai finalement lancé MobSF pour obtenir un aperçu rapide du niveau de risque de ces deux applications...

TL;DR : Rien de grave. Une application médiocre pour un produit médiocre. 8)

Dans l'ensemble, il est clair qu'il est possible de transformer cet appareil en une arme à l'aide d'un APK personnalisé qui peut être contrôlé à distance par un pirate et manipuler les fonctionnalités internes afin de causer des dommages physiques (c'est-à-dire contourner les mesures de sécurité, surchauffer la marmite, etc.).

Farces et shell inversé

En guise de dernier exercice, avant de conclure et de renvoyer ce produit à Amazon, j'ai souhaité vérifier si une reverse shell Meterpreter fonctionnerait et si, grâce à cela, je pourrais exécuter DOOM ou faire des farces à ma femme. Eh bien... :D

Préparons d'abord un APK Meterpreter prêt à être poussé avec ADB :

Ensuite, transférons-le via ADB et installons-le :

Maintenant, exécutons-le :

Entre-temps, sur la machine virtuelle WHIDOS, le listener MSF était déjà configuré :

Désormais, chaque fois que l'appareil est redémarré, il exécute automatiquement le shell inversé et rappelle le C2 de l'attaquant :

À ce stade, l'installation et l'exécution de DOOM ne prenaient que quelques secondes... :D

Conclusion

Le marché de l'IoT est généralement connu pour regorger d'appareils vulnérables. Malheureusement pour le consommateur moyen, la plupart des entreprises ne prennent pas suffisamment au sérieux la sécurité de leurs produits. La plupart du temps, un appareil IoT compromis n'a pas d'impact significatif sur la vie des consommateurs, mais dans certains cas, il peut causer des dommages physiques. Comme dans le cas présent, où le chauffage et le moteur sont contrôlés à distance par l'application, et où un attaquant potentiel pourrait également les contrôler.

De plus, il est clair que l'achat d'appareils IoT reconditionnés peut parfois ne pas être un choix judicieux.

Et si j'avais laissé une charge utile malveillante avant de renvoyer l'appareil à Amazon ? (Avertissement : non, je ne l'ai pas fait).