Pourquoi transformer une webcam en porte dérobée ?
Les rapports faisant état de piratages réussis contre des appareils de l'internet des objets (IoT) sont de plus en plus nombreux. La plupart de ces efforts ont consisté à démontrer comment accéder à un tel appareil ou à franchir sa barrière de sécurité. La plupart de ces attaques sont considérées comme relativement sans conséquence, car les appareils eux-mêmes ne contiennent pas de données réellement utiles (telles que des numéros de carte de crédit ou des informations confidentielles). Les appareils en question n'apportent généralement pas grand-chose au propriétaire d'un réseau de zombies, car ils ont généralement accès à une large bande passante, mais disposent de très peu d'unités centrales et de mémoire vive.
Cependant, ces dispositifs deviennent plus intéressants pour les attaquants sophistiqués lorsqu'ils peuvent être utilisés pour établir un point d'accès permanent dans un réseau. L'installation d'une porte dérobée de rappel dans une webcam, par exemple, permet à un pirate d'accéder en permanence au réseau sans avoir à infecter un ordinateur portable, un poste de travail ou un serveur, qui font tous l'objet d'une surveillance étroite et peuvent souvent faire l'objet d'un correctif. Sur un petit appareil, il n'y a pas d'antivirus ni de protection endpoint . En fait, personne ne pense que l'appareil est équipé d'un logiciel. Cela rend ces appareils potentiellement invitants pour les attaquants persistants qui s'appuient sur des canaux furtifs de commande et de contrôle pour gérer leurs attaques.
L'inconvénient pour l'attaquant est que cette catégorie d'appareils n'a généralement pas de mémoire persistante réellement utilisable. Au lieu de cela, ils utilisent le nvram pour stocker la configuration et la ROM flash pour stocker le code en cours d'exécution. L'espoir de l'attaquant de disposer d'une véritable persistance repose donc sur sa capacité à contrôler ce qui se trouve dans la flash ROM. Dans ce blog, nous allons explorer la difficulté de créer une nouvelle image flash qui pourrait contenir tous les outils dont nous avons besoin pour avoir une véritable porte dérobée persistante vers le réseau sur lequel l'appareil est installé. Une fois que nous disposons d'une telle image flash, sa mise en place pourrait impliquer la "mise à jour" d'un appareil déjà déployé ou l'installation de la porte dérobée sur l'appareil quelque part dans la chaîne de livraison - c'est-à-dire avant qu'il ne soit reçu et installé par le client final. Pour que cette expérience ait un sens, il est impératif que l'appareil continue à fonctionner normalement, sinon cela éveillerait immédiatement les soupçons ou inciterait le client à remplacer l'appareil par une version fonctionnelle.
Pour commencer
Dans ce scénario, l'équipe de Vectra Threat Labs a acheté une caméra web WiFi D-Link grand public pour environ 30 USD*. L'ouverture de ce petit boîtier en plastique a été une expérience étonnante qui nous a rappelé qu'un Leatherman n'est pas l'outil idéal pour toutes les tâches...
Un rapide coup d'œil sur le circuit imprimé permet de constater :
- Antenne WiFi
- Ralink RT5350F
- SDram M12L2561616a-6t
- Flash Rom MX25L3205
Vider la mémoire flash
Étant donné la présence de la puce de mémoire flash sur le circuit imprimé, nous supposons que c'est là que les données/codes sont probablement conservés pour la persistance. La première chose à faire est donc d'extraire le contenu de cette puce pour voir ce qui y est stocké.
Après avoir branché un Bus Pirate sur la carte, nous pouvons utiliser flashrom pour vider le contenu.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1Mflashrom v0.9.7-r1782 on Linux 4.0.0-kali1-amd64 (x86_64)flashrom est un logiciel libre, obtenez le code source, Calibration de la boucle de retard... OK. Trouvé la puce flash Macronix "MX25L3205(A)" (4096 kB, SPI) sur buspirate_spi.Trouvé la puce flash Macronix "MX25L3205D/MX25L3208D" (4096 kB, SPI) sur buspirate_spi.Trouvé la puce flash Macronix "MX25L3206E" (4096 kB, SPI) sur buspirate_spi.Plusieurs définitions de puces flash correspondent aux puces détectées : "MX25L3205(A)", "MX25L3205D/MX25L3208D", "MX25L3206E "Veuillez spécifier la définition de puce à utiliser avec l'option -c.
Nous pouvons maintenant extraire le contenu des puces flash en vue d'une analyse plus approfondie.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -c 'MX25L3205(A)' -r MX25L3205-A
Analyse du flash dump
Une fois que nous avons un bon dump de la flash, nous pouvons utiliser binwalk pour déterminer ce qu'elle contient.
#binwalk -Me MX25L3205-A DECIMAL HEXADECIMAL DESCRIPTION--------------------------------------------------------------------------------0 0x0 uImage header, header size : 64 bytes, header CRC : 0x11BEF629, created : Tue Feb 3 11:07:53 2015, taille de l'image : 111116 octets, adresse des données : 0x80200000, point d'entrée : 0x80200000, données CRC : 0xCD95F789, OS : Linux, CPU : MIPS, type d'image : Standalone Program, compression type : none, image name : "SPI Flash Image "91040 0x163A0 U-Boot version string, "U-Boot 1.1.3"105424 0x19BD0 En-tête de document HTML105777 0x19D31 Pied de page de document HTML105780 0x19D34 En-tête de document HTML105979 0x19DFB Pied de page de document HTML106140 0x19E9C En-tête de document HTML106840 0x1A158 Pied de page de document HTML210495 0x3363F Certificat PEM211671 0x33AD7 Clé privée RSA PEM327680 0x50000 En-tête uImage, taille de l'en-tête : 64 octets, CRC de l'en-tête : 0xABF213A9, créé : Tue Feb 3 11:07:48 2015, taille de l'image : 3730981 bytes, Adresse des données : 0x80000000, point d'entrée : 0x8038B000, données CRC : 0x2829F3C1, OS : Linux, CPU : MIPS, type d'image : OS Kernel Image, type de compression : lzma, nom de l'image : "Linux Kernel Image "327744 0x50040 Données compressées LZMA, propriétés : 0x5D, taille du dictionnaire : 33554432 octets, taille non compressée : 6394309 octets327744 0x50040 Données compressées LZMA, propriétés : 0x5D, taille du dictionnaire : 33554432 octets, taille non compressée : 6394309 octets
Le format de ce micrologiciel consiste donc en un u-boot et un noyau et une image Linux.
Nous aurions pu utiliser dd, lzma ou cpio pour extraire le contenu du firmware ou nous pouvons laisser binwalk faire ce travail. Nous devons encore extraire la dernière étape de l'image cpio pour voir le contenu de l'image.
#cpio -ivd --no-absolu-filenames -F. 0.cpio
Une fois cette dernière étape réalisée, nous pouvons accéder au système de fichiers de l'image Linux.
Un binaire intéressant dans le système de fichiers est /bin/upgradefw, qui semble être l'exécutable utilisé pour effectuer la vérification et la mise à jour du microprogramme.
#file ./bin/upgradefw./bin/upgradefw : ELF 32-bit LSB exécutable, MIPS, MIPS-II version 1 (SYSV), dynamiquement lié, interpréteur /lib/ld-uClibc.so.0, dépouillé
Analyse du binaire upgradefw
Pour cette section, nous allons utiliser IDA Pro comme outil de choix pour effectuer la rétro-ingénierie du binaire de mise à niveau.
IDA est capable de faire une très bonne première passe sur le binaire, ce qui le rend beaucoup plus facile à analyser. En suivant le chemin du code à partir de la fonction principale, nous arrivons assez rapidement à une fonction nommée "check" qui effectue la majeure partie du travail de vérification de la validité de l'image flash avant de l'envoyer à mtd_write.
La validation effectuée par le binaire upgradefw semble inclure quelques contrôles crc32, des contrôles memmem/strstr et une boucle qui calcule une valeur et la compare à une ou deux valeurs fixes.
Le flux logique de la fonction de contrôle entre le point d'entrée et le retour d'un succès ressemble à peu près à ceci :
1. Vérifier si le fichier s'est ouvert correctement
2. Vérifier la taille du fichier
3. Charger le fichier et vérifier que la lecture a fonctionné
4. Cochez la case "Signature : "
5. Vérifiez la case "Release : "
6. Comparer la version à la version actuelle
7. Routine de vérification Uboot/uimage
passage à x86 ici pour la somme de contrôle 55AA55AA.
Ajout d'une porte dérobée
A ce stade, l'ajout d'une porte dérobée revient à ajouter un service à l'intérieur d'un système Linux - dans notre cas, tout ce que nous voulons, c'est un simple proxy Socks connect-back. Cela peut être réalisé avec un srelay et netcat dans le script de démarrage ou un code C plus optimisé, ou on peut opter pour un simple callback backdoor avec un shell utilisant netcat et busybox qui sont déjà présents sur le système.
C'est toujours une bonne idée d'être aussi léger que possible sur les fonctionnalités ajoutées - après tout, nous n'avons pas un ordinateur portable complet pour travailler ici, mais plutôt une minuscule webcam avec 4 Mo de ROM. L'ajout d'un trop grand nombre de fonctionnalités risque donc de casser le logiciel. Pendant que nous procédons à la modification, nous pouvons également supprimer la possibilité de recharger l'appareil à l'avenir. Cela empêcherait une mise à jour du firmware initiée par l'administrateur qui supprimerait notre porte dérobée.
Reconditionnement
Après avoir passé un certain temps à construire un script de reconditionnement, nous avons trouvé un script intéressant sur le site web de Ralink qui s'est avéré très utile.
l'utiliser avec :
make -f Makefile.4M
Après cela, il suffit de corriger la somme de contrôle dans le fichier. Ceci peut être réalisé avec un utilitaire RaLink nommé addchecksum ou en corrigeant manuellement la somme de contrôle. Le décalage/plage utilisé par la somme de contrôle peut être découvert dans les binaires upgradefw ou addchecksum. Et comme d'habitude... vérifiez votre endianness.
Essai d'un raccord de retour
En utilisant telnetd / busybox / netcat, nous pouvons ramener un socket telnet vers un hôte extérieur afin d'avoir une persistance à distance de la webcam. Avec la webcam agissant comme un proxy, l'attaquant peut maintenant envoyer du trafic de contrôle dans le réseau pour faire avancer son attaque, et de la même manière utiliser la webcam pour siphonner des données volées.
Le caractère d'échappement est '^]'.(none) login : adminPassword:BusyBox v1.12.1 (2015-11-11 05:41:04 UTC) built-in shell (ash)Entrez 'help' pour une liste des commandes intégrées.# ls /biniwpriv pcmcmd nvram_daemon ntpclient sounddb ipush touch pwd ls cpov7740 switch mii_mgr mtd_write notifystream schedule sync ps login chmoduvc_stream gpio ated msmtp mydlinkevent lanconfig sleep ping kill catmail nvram_set reg mDNSResponder imagetp iperf sh mount grep ashi2c nvram_get pppoecd lld2d upgradefw inadyn sed mknod echo busyboxswing ralink_init openssl disablebonjour audiopush umount rm mkdir date alphapd
Conclusion
Cela signifie-t-il que la caméra web de D-Link présente un problème de sécurité majeur ? Pas nécessairement - nous en avons pour notre argent, et il n'est pas très réaliste de demander à un fournisseur qui vend une webcam sur Amazon pour 30 dollars de proposer des fonctions de mise à jour du micrologiciel sûres qui nécessiteraient un TPM ou une puce spécialisée pour vérifier le contenu et la signature d'une mise à jour logicielle. Le but de cette démonstration est plutôt de mettre en évidence l'impact réel des appareils IoT sur la surface d'attaque d'un réseau. Comme nous l'avons montré, les obstacles au piratage de ces appareils sont relativement faibles, et même les appareils les plus basiques peuvent fournir la tuyauterie d'un canal de commande et de contrôle persistant. Bien que ces appareils aient une faible valeur en termes de coûts matériels, ils n'en sont pas moins importants pour la sécurité du réseau, et les équipes doivent garder un œil sur eux pour détecter tout signe de comportement malveillant.
*Vectra a révélé le problème à D-LInk au début du mois de décembre 2015. En date du 7 janvier 2016, l'entreprise n'a pas fourni de solution.