Dump de mémoire
Nous avons pu voir, durant l’étude de la carte électronique, qu’il y avait une seule puce de mémoire flash.
La puce GigaDevice GD25G32C est une puce de mémoire flash de 4Mo de capacité (nous avons pu le confirmer avec une connexion à la console via le port UART). Cette puce devrait contenir le firmware du routeur et un ou des fichiers contenants des mots de passes, par exemple le fichier shadow.
Pour effectuer le dump des informations de cette puce, nous nous servirons encore une fois du Buspirate, accompagné du binaire flashrom (https://www.flashrom.org/Windows).
Il nous faudra croiser les docs du buspirate et la datasheet de la puce.
Pour faciliter le dump et éviter de souder des fils à chaque patte de la puce mémoire, nous utiliserons une pince spéciale SOC8. Celle ci permettra de clipser chaque pin. Cette puce est connectée à une nappe, puis finie par un connecteur. Chaque pin de ce connecteur est donc reliée à une patte de la puce.
Il est également à noter qu’il ne faudra pas brancher la pin VCC, car si elle est branchée nous ne pourrons pas dumper la puce. En effet, il s’agit ici d’un fonctionnement en Master/Slave. Notre buspirate est donc le master et la puce doit être le slave. Si celle ci est alimentée, elle passe en master. De ce fait le buspirate ne pourra pas lire les informations. Nous aurons également besoin d’une breadboard afin de relier les pattes 3 et 7 sur 3.3V
Une fois les connexions faites, il ne reste plus qu’à brancher le buspirate en USB. Le routeur ne doit pas être alimenté. Nous utiliserons l’exécutable flashrom avec la commande :
.\flashrom.exe –verbose –programmer buspirate_spi:dev=COMX,spispeed=1M –read « C:\PathToOutputFile »
Il faudra changer le port COM par le vôtre et le chemin du fichier de sortie.
Il est toujours préférable de dumper deux fois la rom, puis de vérifier les hash des deux fichiers. Il est assez courant qu’il y ait des erreurs lors du dump. Avoir deux fois le même fichier nous assure que nous avons bien dumpé la mémoire sans problème.
Le dump peut prendre plusieurs dizaines de minutes, pour une puce de 4Mo cela m’a pris 15mins. Donc allez prendre un café, sortez voir la nature, cela fait du bien !
Firmware
Nous nous retrouvons donc avec un binaire de 4Mo.
Pour extraire le file system de ce binaire, nous allons utiliser l’outil binwalk. Nous devrons passer par un linux (il est certainement possible d’utiliser le Windows Subsystem for Linux de Windows 10).
La commande « binwalk -e flash_dump.dump », nous permet d’extraire le file system. Il sera stocké dans le dossier « _flash_dump.dump.extracted » dans notre cas. Nous avons différentes informations données par l’outil. Notamment qu’il s’agit d’un Squashfs compressé avec lzma, qu’il s’agit d’un linux en architecture MIPS, ainsi que différents offsets.
Le dossier qui nous intéressera est le dossier squashfs, qui contient les fichiers du système.
A partir de là, il est assez facile de trouver le fichier shadow avec le hash MD5 du mot de passe. Une recherche Google nous permet de rapidement connaître le mot de passe d’origine. Sinon nous aurions pu tenter un bruteforce de hash. Une attaque par rainbow table étant peine perdu du fait de l’application d’un salt.
Apres quelques recherches dans différents fichiers d’initialisation, il semblerait que le gros du travail soit effectué par un seul binaire. Il semblerait que le fabriquant ait modifié le binaire afin d’y incorporer certaines de ses fonctionnalités.
Mais l’étude du binaire sera le sujet d’autres articles traitants du reverse engineering sur architecture MIPS.
Conclusion
Pour résumer, nous pouvons avoir un shell et nous avons le mot de passe root.
L’aventure commence réellement maintenant. Un gros travail de forensic et de reverse engineering est encore à venir pour trouver des vulnérabilités dans le firmware, allant de la partie WEB, au reverse engineering des binaires intéressants, ainsi que de l’application mobile qui permet de configurer le routeur à distance. On se retrouvera donc très bientôt pour la suite !