Analyse des composants d'un téléphone IP professionnel
Étude complète des composants d’un téléphone VoIP : analyse du système et méthodes d’exécution de code pour évaluer la sécurité des appareils IP
Ce projet présente l’analyse et la rétro‑ingénierie du firmware, des formats de fichiers et de la cryptographie d’un téléphone IP professionnel. De nombreux composants logiciels sont spécifiques au fabricant. Cette particularité rend l’étude du dispositif à la fois complexe et instructive.
Des outils ont été développés pour générer des images de mise à jour personnalisées, permettant l’installation de logiciels arbitraires sur le téléphone.
Analyse matérielle
Le téléphone contient trois circuits imprimés (PCB) :
Deux PCB pour les boutons en façade.
Un PCB central pour le CPU principal, la DRAM et une mémoire NAND flash.
Ce PCB central intègre également un microcontrôleur OTP 8 bits fabriqué par Holtek, utilisé comme coprocesseur pour les tâches temps réel.
Connectivité
Le téléphone offre :
Un port USB (dongles Bluetooth possibles),
Deux prises Ethernet (« PC » et « Internet »),
Un port téléphonique « EXT »,
Deux connecteurs analogiques pour casque et combiné,
Un header trois broches non soudé pouvant servir de port série.
L’analyse du log de démarrage montre que le téléphone utilise un processeur ARM, emploie U-Boot comme bootloader et fonctionne sous Linux 2.6.27. L’accès à la console U-Boot permet de flasher de nouvelles images ou modifier la ligne de commande du noyau. La mention « holtek » dans le log confirme l’existence du microcontrôleur secondaire.
Analyse du firmware
Les fichiers de mise à jour sont disponibles via le site du fabricant et peuvent être transmis via l’interface web, USB ou TFTP. Cependant, ces fichiers sont chiffrés à plusieurs niveaux, ce qui complique leur analyse.
Des travaux antérieurs de Tristan Pourcelot (Synacktiv) ont montré que certains fichiers firmware ne sont pas signés et utilisent des chiffrements faibles avec clés codées en dur.
En utilisant ces recherches, l’image firmware .rom a été dépaquetée en deux fichiers : app.bin et version.bin. Ces fichiers restaient partiellement chiffrés, nécessitant une rétro‑ingénierie du schéma de chiffrement.
Firmware auto‑déchiffrant
Le fichier version.bin est un binaire ELF majoritairement chiffré ou compressé. Il agit comme décrypteur pour la charge utile, incluant uptool et libupgrade.so, chiffrés en AES-CBC-256.
Pendant la mise à jour, version.bin se déchiffre lui-même, permettant la mise à jour de la bibliothèque de mise à jour et le traitement du chiffrement dans app.bin.
La clé AES est dérivée de l’identifiant matériel via un algorithme interne, en coopération avec le microcontrôleur Holtek. L’analyse du bus série a permis de récupérer la clé complète et de déchiffrer version.bin ainsi que libupgrade.so.
Déchiffrement du système de fichiers racine
La rétro-ingénierie de libupgrade.so a montré que app.bin est chiffré en AES-ECB-128 avec une clé codée en dur, préalablement encodée via un chiffrement simple.
L’extraction et l’application de ce chiffrement ont permis de :
Obtenir la clé AES effective,
Déchiffrer app.bin,
Extraire le noyau Linux et le système de fichiers YAFFS racine.
Repackaging et mise à jour
Avec le firmware déchiffré, il est possible d’ajouter des binaires supplémentaires et de repacker l’image pour l’installation.
Une erreur initiale a bloqué le téléphone en affectant la partition UBL du bootloader. L’analyse du dump NAND a permis de restaurer cette partition et de corriger l’octet manquant, assurant une mise à jour correcte.
Exécution de code
Différentes méthodes ont été testées pour exécuter du code sur le téléphone. La modification de l’ELF déchiffreur a permis d’exécuter un reverse shell ou du shellcode.
Finalement, un appel à system() dans le binaire déchiffreur a lancé un serveur Telnet root, offrant un accès persistant à la console.
Grâce à cet accès root, les partitions peuvent être montées en lecture-écriture et des scripts au démarrage exécutent automatiquement les binaires.
Persistance et démonstration
Pour démontrer le potentiel du système, le jeu DOOM a été porté sur le framebuffer du téléphone via fbdoom. L’écran a été adapté pour l’orientation et la résolution couleur du téléphone.
Le binaire final est conservé sur une clé USB et lancé automatiquement au démarrage via un script shell.
Source : stefan-gloor.ch
Réseaux Télécoms
Cloud Infrastructure
Cyber Sécurité
Ressources
©Tous droits réservés CDX Telecom 2021 | Mentions légales | Conditions générales | Blog