Les pentests matériels dans les environnements IoT

1. Introduction

Le marché de l'IoT est en plein essor avec 34 Mds d'objets connectés à l'horizon 2020 [1]. Une solution IoT se compose de capteurs/actionneurs qui communiquent via des liaisons sans fils ou filaires avec des bridges (passerelles). Ces bridges transmettent les informations vers des centres de traitement comme le Cloud ou des applications mobiles. Ces solutions peuvent être utilisées dans des domaines critiques comme la défense et la santé. Ainsi, la sécurité des données peut être très critique, ce qui constitue un frein majeur à cette expansion [1]. Pour pallier à ce problème, un certain nombre de mécanismes sont adoptés comme le chiffrement des communications et l'authentification des entités communicantes. Cependant, l'ouverture, l'interopérabilité et le déploiement dans la nature de ces solutions les rendent vulnérables à des attaques matérielles.

Dans cet article, nous nous intéressons à cet aspect important qui est la sécurité d'un point de vue matériel. Plus spécialement, nous montrerons à travers des pratiques comment dumper le contenu de mémoires (flash, EEPROM) et retrouver de l'information sensible qu'elles contiennent (firmware, clés cryptographiques) en s'attaquant physiquement aux composants de la solution IoT. Dans certains cas, il devient même possible de corrompre le firmware pour insérer du code malveillant. Nous montrerons aussi la détection et l'exploitation de ports série tels que UART et JTAG se trouvant sur des cartes-mères. Ces ports sont utilisés pour le debugage par le constructeur, mais peuvent être utilisés par des attaquants pour obtenir un accès root.

Mais auparavant, nous allons vous présenter rapidement les méthodologies de test pouvant faire référence, ainsi que quelques outils logiciels et matériels pouvant être utilisés. Même si l'accent est mis sur l'IoT, ces méthodologies et outils peuvent être appliqués dans d'autres contextes tels que les réseaux industriels et les systèmes embarqués.

2. Méthodologies de test existantes

La méthodologie de pentest doit être adaptée aux surfaces d’attaque et spécificités de l’IoT. Dans cette optique, NESCOR peut être appliquée. De plus, les propositions issues l’OWASP IoT Project peuvent également servir de référence.

2.1. La méthodologie NESCOR

La National Electric Sector Cybersecurity Organization Resource (NESCOR) a décrit une méthodologie pour les pentests dans les réseaux Smart Grid et ses aspects connexes [2]. Elle peut très bien aussi s'appliquer dans le contexte de l'IoT. Elle se base sur quatre types de tests :

- Pentest des composants électroniques : pentester les composants électroniques de la cible comme les mémoires, bus de données et ports E/S. Les tâches relatives sont : extraction de contenus, recherche d'informations sensibles, décompilation de firmwares, détection et exploitation de ports série. Il s'agit de la partie de plus grand niveau de difficulté pour laquelle un travail d'innovation important reste à faire pour la mise au point d'outils de test [2] ;

- Pentest du réseau de communication : pentester les réseaux qui interconnectent les différents blocs de l'application IoT (capteurs, bridges, Cloud). En général, des protocoles sans fils dédiés comme ZigBee, Z-Wave ou BLE. Les tests peuvent être passifs (capter les échanges, déchiffrer, extraire des informations échangées en clair) et/ou actifs (forger du trafic, man in the middle, brouillage, fuzzing) ;

- Pentests systèmes : détection et exploitation de vulnérabilités dans les systèmes d’exploitation des composants (bridges...). Il s'agit de tâches similaires à celles que l'on fait dans les SI classiques ;

- Pentests applicatifs : pentest des différentes applications reliées à la solution IoT (applications web qui se trouvent sur le bridge). Dans ce cas aussi, il s'agit de pentest comme on sait faire dans les SI classiques.

Dans cette partie-là, il y a un certain nombre de sous-tâches définies dans le document de référence [2].

2.2. Le pentest matériel dans l'IoT Top 10 de  l'OWASP

Selon l'OWASP, l'IoT est un domaine des plus vulnérables [5]. En effet, une solution IoT intègre plusieurs composants à différents niveaux. Elle utilise des applications web dans les composants avec des communications sans fil. De plus, elles utilisent des plateformes Cloud pour le stockage/gestion et aussi des applications mobiles pour le pilotage. Ainsi la surface d'attaque est plus large.

Dans cette optique, l'OWASP a lancé l'OWASP IoT Project  [3]. Elle définit, entre autres, la surface d'attaque et le top ten des vulnérabilités. En terme de surfaces d'attaque, en plus des applications web, réseaux et API Cloud, l'OWASP s'intéresse beaucoup aux parties matérielles comme les interfaces sur les équipements (ports série), les mémoires de stockage (informations sensibles stockées en clair), le firmware (la signature de firmwares, présence en clair d'informations sensibles dans les firmwares) des différents composants de la solution IoT. C'est cet aspect matériel auquel on s'attaque dans cet article.

3. Outils de test existants

Un certain nombre d'outils logiciels et surtout matériels sont nécessaires. Dans ce qui suit, nous présentons quelques-uns des outils les plus utilisés.

3.1. Les outils logiciels

- flashrom : permet d'extraire/écrire le contenu de mémoires flash SPI. Il supporte un certain nombre d'architectures cibles et un certain nombre de convertisseurs USB/SPI (dongles matériels). Bien que flashrom soit simple et flexible, il ne supporte pas tous les types de mémoire flash du marché ;

- openocd : utilisé pour déboguer des microcontrôleurs moyennant le protocole et interface JTAG. Il est utilisé pour interagir avec un microprocesseur pendant l'exécution pour déboguer des programmes (arrêter/reprendre, afficher le contenu des registres ou mémoires) ;

- avrdude: environnement de programmation dédié aux microcontrôleurs AVR. Il permet de programmer leurs  EEPROM/flash. Il s'utilise avec un dongle matériel tel que Bus Pirate, Shikra ou bien les gpio d'un Raspberry Pi ;

-binwalk : permet de chercher, analyser et décompresser des fichiers binaires comme les firmwares. Il intègre plusieurs options permettant de reconnaître et extraire des formats standards dans les binaires (systèmes de fichiers, kernel, fichiers compressés/archivés, headers de fichiers connus...). De plus, il dispose de fonctionnalités permettant de faire des analyses d'entropie.

- GNU Binutils: ensemble d'outils permettant de manipuler des fichiers binaires. Il contient par exemple objcopy permettant de copier des fichiers objets avec une éventuelle modification et conversion entre formats, e.g, convertir un fichier .ihex (Intel HEX) en fichier .elf, objdump permettant de visualiser des informations sur des fichiers binaires et de les désassembler, readelf permettant de lire des informations d'un fichier .elf.

3.2. Les outils matériels

Bus Pirate : il se base sur un microcontrôleur PIC24 et un FT232RL. Il offre la possibilité d’écrire des scripts pour interagir avec des cibles en 1-Wire, I2C, SPI, UART et JTAG. Il permet aussi de sniffer du trafic SPI ou I2C sur des bus en fonctionnement. Il est sans doute un des outils les plus aboutis vu la documentation qui existe et le support offert pour beaucoup d'outils logiciels tels que flashrom, avrdude et openocd. Par contre, comme cet outil utilise une partie du traitement en logiciel, il est lent et ne peut pas être utilisé pour les bus rapides.

Shikra : il permet d'interagir avec des cibles utilisant les protocoles JTAG, UART, SPI et I2C. Shikra peut être utilisé avec flashrom, avrdude et openocd pour interagir avec des cibles en SPI ou JTAG, et dispose d'un mode passthrough pour interagir avec des ports UART. Se basant sur un FT232H, il est présenté comme plus rapide que le Bus Pirate. Cependant, il est faiblement documenté.

GoodFET : inspiré par Bus Pirate, GoodFET est un autre outil permettant d’interagir avec des cibles en SPI, I2C ou encore JTAG. Il supporte un certain nombre de cibles comme des microcontrôleurs AVR, PIC ou mémoires SPI/I2C. Sa force est qu'il vient avec ses propres applications clientes et que les cibles sont explicitement testées, par contre il souffre du nombre limité de ces cibles (les travaux sont en cours pour enrichir la liste).

Hardsploit : c'est un outil matériel développé par Opale Security [6] qui dispose aussi d'une suite logicielle composée d'une interface GUI et une API open source. Il est capable de traiter les bus parallèles en plus des bus série SPI, I2C, JTAG et autres.

JTAGulator : c'est un outil matériel permettant d'identifier les pins d'une interface UART ou JTAG d'une carte-mère cible. Il dispose de 24 pins d'identification et se base sur le Propeller de Parallax et un FT232RL pour l'interface USB. Le firmware du JTAGulator dispose d'une interface console permettant de lancer des commandes. Nous présenterons plus de détails dans la suite sur ces différentes commandes.

Raspberry Pi : le Raspberry Pi dispose de pins gpio permettant de le transformer en outil matériel d'interaction utilisant les protocoles I2C, SPI et JTAG. Son avantage est que c'est un système Linux avec des accès directs aux pins gpio. Les parties logicielles sont directement exécutées dessus. Il supporte par exemple flashrom, avrdude et openocd. Il dispose aussi de bibliothèques SPI, I2C en C/C++ et Python permettant d’écrire des programmes d'interaction personnalisés. Cependant, il peut avoir des problèmes de performances.

Arduino : Arduino dispose d'une interface et de bibliothèques SPI et I2C permettant d'interagir avec les circuits (mémoires par exemple) utilisant ce même protocole. Il peut donc être utilisé pour dumper/modifier le contenu de mémoires SPI. Par contre, il est limité en termes de ressources (mémoire, vitesse de transmissions).

Il est à noter qu'il existe des outils propriétaires qui sont utilisés pour une certaine famille de microprocesseurs.

4. Dumper le contenu de mémoires flash ou EEPROM

Dans cette section, nous montrons un exemple d'extraction de contenu de la mémoire flash d'un microcontrôleur ATMega328p (Arduino Uno). Nous utilisons GoodFET ici. En particulier, goodfet.avr contient l'ensemble des fonctions pour interagir avec un microcontrôleur AVR.

Ainsi, pour dumper le contenu de la mémoire flash, on se sert de dumpflash avec comme paramètre le fichier en sortie et les adresses (ici flash de 32kB).

Le format de sortie dans ce cas est le format ihex (Intel HEX). Ainsi, une transformation simple permet d'avoir le contenu binaire des données de la flash uniquement. Plus précisément, dans chaque ligne, il faut supprimer les deux points (marque le début d'une ligne), le premier octet (Byte count), le second et troisième octet (Address), le quatrième octet (Record type) et le dernier octet (Checksum). Il est à noter qu'une bibliothèque Pyhton bincopy permet de manipuler ces fichiers ihex (https://pypi.python.org/pypi/bincopy).

Dans un autre exemple, nous avons utilisé un Arduino pour extraire le contenu d'une mémoire EEPROM SPI 25LC040. Dans ce cas, il a fallu écrire le code source correspondant. De plus, en fonction de la documentation du circuit mémoire, il faut bien formater les commandes et les adresses. Pour des raisons de limitations, nous avons mis en ligne le code complet (https://github.com/aamokrane/SPI_Dump_Arduino/tree/master). Le résultat (contenu en hexa de l'EEPROM) est donné en sortie du port série de l'Arduino. Notez aussi qu'un exemple de cible EEPROM AT25HP512 est disponible dans https://www.arduino.cc/en/Tutorial/SPIEEPROM.

5. Extraction d'informations utiles depuis le contenu dumpé

5.1. Recherche de chaînes de caractères lisibles

Cette méthode consiste à rechercher des chaînes de caractères ASCII lisibles comme des mots de passe, des noms d'utilisateurs par lecture directe ou en cherchant par mot-clé (key, admin, pass). Par exemple, dans le cas de la mémoire EEPROM dumpée en utilisant l'Arduino, les chaînes de caractères sont visibles comme illustré dans la figure suivante.

 

 

Par contre, parfois le contenu dumpé est dans un format particulier. Dans ce cas, on peut passer par des transformations pour arriver à des chaînes de caractères lisibles. Dans notre exemple de ATMega328p, nous avons écrit un script Python permettant de convertir dans un format ASCII le fichier hexadécimal dumpé de la flash. Le résultat visualisé dans hexdump est :

5.2. Recherche par analyse d'entropie

L'analyse d'entropie peut être utilisée pour plusieurs objectifs. Pour les fichiers de grande taille par exemple, une analyse d'entropie permet de réduire l'espace de recherche en éliminant les parties à faible entropie qui correspondent à des zones mémoires vides (une chaîne par défaut est écrite comme 0xFF).

Pour ce faire, on a utilisé binwalk et son analyseur d'entropie (option -E) avec la possibilité de spécifier la taille des blocs (-K). Dans ce qui suit, on l'a appliqué sur le contenu ASCII de la mémoire flash dumpée précédemment :

binwalk produit aussi en sortie un graphe d'entropie comme illustré dans la figure 2.

 

 

On remarque du graphe une zone entropie nulle entre l'offset 11 et 32 kB du fichier, impliquant un contenu pas intéressant à explorer. En effet, cette zone correspond à des 0xFF.

L'analyse d'entropie pourrait être utilisée aussi pour repérer du contenu spécifique dans une mémoire. Par exemple, les clés de chiffrement aléatoires dans une mémoire peuvent présenter un niveau d'entropie différent du reste du contenu. Dans l'exemple suivant, nous présentons le cas d'une clé trouvée dans une mémoire EEPROM. Notez que le fichier dumpé est tiré de la distribution Linux SamuraiSFTU.

 

 

Dans ce cas, le contenu de la mémoire commençant à l'offset 3kB représente potentiellement une clé de chiffrement (en vérifiant le contenu).

Enfin, il faut noter que l'analyse d'entropie peut aider à guider dans la recherche du contenu. Par contre, ce n'est en aucun cas une solution complète pour retrouver du contenu.

5.3. Recherche d'informations préformatées

On peut aussi chercher des informations préformatées qui peuvent être disponibles. Par exemple, certains formats de fichiers disposent de signatures particulières que l'on peut reconnaître. Pour ce faire, on peut se servir d'outils existants comme binwalk qui dispose d'un grand nombre de signatures et qui permet d'extraire des fichiers. Dans l'exemple suivant, nous avons utilisé binwalk avec l'option -B pour repérer des clés de chiffrement dans le contenu de la mémoire flash de l'Arduino. Le résultat montre une clé privée RSA stockée en mémoire.

 

 

 

Notez que sous binwalk, on peut combiner plusieurs options pour avoir un graphe qui regroupe l'ensemble des résultats.

6. Détection et exploitation de ports série

Un autre aspect important à vérifier est la présence de ports série sur les cartes-mères des cibles. Un port série peut être par exemple un port UART ou JTAG.

6.1. Les ports UART

Dans un port UART, deux lignes TX et RX sont utilisées. Au sein du système cible, un daemon est chargé de traiter les données reçues par le port UART. Dans un environnement Linux, le daemon peut donner lieu à une interface terminal shell.

La première étape est la détection du port en question. Pour ce faire, nous utilisons le JTAGulator (un tutoriel vidéo détaillé est disponible [4]). Il faut noter qu'une identification manuelle est possible en se référant à la datasheet du microcontrôleur cible pour identifier les broches TX et RX et puis par test de connectivité définir les broches correspondantes sur le port. En résumé, le processus d'identification avec JTAGulator se déroule comme suit (nous avons utilisé une Set-Top-Box comme cible) :

 

 

- On utilise un multimètre en mode test de continuité pour identifier la broche GND du port.

- On utilise le multimètre pour trouver le voltage utilisé par la cible quand elle est alimentée en courant.

- On lance minicom ou un équivalent (une configuration 8N1 en baud rate 115200) pour interagir avec le JTAGulator. On ajuste alors le voltage de la carte cible (la commande V) à la valeur trouvée.

- On utilise la commande U pour identifier les broches TX et RX. Pour ce faire, on connecte les broches de la cible de façon aléatoire aux broches du JTAGulator (CH0-CHn). Le JTAGulator demande une chaîne de caractères et le nombre de broches à tester sur la cible. Il envoie la chaîne de caractères sur les broches deux à deux (une broche TX et une autre RX) en essayant toutes les permutations et pour plusieurs baud rates. Voici un extrait des résultats :

On remarque alors que la chaîne en entrée est retournée pour un baud rate de 115200 avec les broches CH1 et CH0 correspondant à TX et RX, respectivement.

- On passe par la suite à l'exploitation du port UART. On utilise alors le mode passthrough (commande P) avec les broches identifiées.

Dans cet exemple, nous montrons la présence d'une console shell en mode root sur le port UART de la cible !

On peut utiliser aussi le port UART pour accéder au bootloader. Ceci peut donner lieu à la possibilité de changer le firmware de la cible ou prendre le contrôle sur le système au démarrage en passant init=/bin/sh en argument au kernel (la procédure utilisée en cas de perte de mot de passe sous Linux).

Enfin, on peut utiliser le port UART pour récolter des informations sur le système cible lors du boot par exemple (traces) comme les versions utilisées ou encore pour lire le firmware contenu dans la cible ou carrément flasher un nouveau firmware.

6.2. Les ports JTAG

Un port JTAG est plus riche qu'un port UART en termes de fonctionnalités. De plus, un port JTAG dispose de plus de broches (TDI, TDO, TMS, TCK, TRST et GND). JTAGulator permet uniquement d'identifier ces broches en utilisant les commandes I et B. Notons que la procédure est similaire à celle d'un port UART (la broche GND, le voltage). Il faut noter aussi qu'il est possible d’identifier les broches en se référant à la datasheet du microcontrôleur comme dans le cas d'un port UART.

En utilisant JTAGulator, la commande I permet d'identifier les broches TDO, TMS, TCK et TRST. Pour ce faire, JTAGulator essaye de lire l'IDCODE depuis le registre de sortie du port cible en utilisant les différentes permutations des broches. De plus, la commande D permet d'avoir l'identifiant détaillé du composant interfacé.

Par la suite, la commande B est utilisée pour identifier la broche TDI (TDO, TMS, TCK sont données en entrée de la commande). JTAGulator essaye alors d'entrer des données par une broche supposée être TDI et les recevoir par la broche TDO.

Il faut noter qu'un port JTAG peut être utilisé pour interfacer plusieurs composants sur une carte-mère. Ainsi, JTAGulator permet de détecter le nombre de composants qui communiquent via ce port JTAG.

Une fois les broches identifiées, il faut utiliser d'autres outils permettant de l'exploiter (voir section 3).

Conclusion

Dans cet article, nous avons présenté des démarches, outils logiciels et matériels qui peuvent aider dans les pentests matériels comme extraire du contenu de circuits mémoire ou détecter et exploiter des ports série.

Cependant, il faut noter que des mécanismes de protection existent pour sécuriser les architectures cibles. Par exemple, activer les protections comme ReadOutProtection sur les microcontrôleurs qui empêche l'extraction du contenu, chiffrement du contenu à l'aide d'une clé protégée en ReadOut, signature des firmwares pour éviter leur altération ou encore l'intégration de HSM pour les opérations de cryptographie. De plus, les ports UART ou JTAG doivent être désactivés lors du passage en production. Enfin, une utilisation de PCB multicouche peut limiter les accès aux bus internes.

Références

[1] BII : The IoT 2015 Report, http://bit.ly/1Hpv317

[2] S. Justin, et. al NESCOR Guide to Penetration Testing for Electric Utilities V3, 2013.

[3] IoT Top 10 project, http://bit.ly/1yYQuyE

[4] JTAGulator tutorial, http://bit.ly/1STzwdR

[5] Hewlet Packard, IoT research study, http://bit.ly/1dB4x6O, 2015

[6] hardsploit.io