Les pentests matériels dans les environnements IoT

Magazine
Marque
MISC
Numéro
84
Mois de parution
mars 2016
Domaines


Résumé
Le pentest de matériels qui a pour objectif la récupération/modification d'informations sensibles via des accès physiques, est sans doute un aspect crucial dans le monde de l'IoT. Dans cet article, nous présentons des outils logiciels et matériels et leur utilisation à travers des cas pratiques pour dumper le contenu de circuits mémoire (EEPROM, flash) et rechercher des informations sensibles qu'ils contiennent, ainsi que la détection et l'exploitation de ports série (JTAG, UART).

Body

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 P: 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.

$ goodfet.avr

Usage: goodfet.avr verb [objects]

goodfet.avr test

goodfet.avr info

goodfet.avr lockbits [value]

goodfet.avr dumpflash $foo.hex [0x$start 0x$stop]

goodfet.avr erase

goodfet.avr peekeeprom 0x$start [0x$stop]

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).

$ goodfet.avr dumpflash dump_Flash.hex 0x00 0x7FFF

$ cat dumped_falsh.hex |more

:100000000C9490000C94B8000C94B8000C94B800B8
:100030000C94B8000C94B8000C94B8000C94B80060
:100040000C948B010C94B8000C94A0030C94D20374
:100050000C94B8000C94B8000C94B8000C94B80040
:100060000C94B8000C94B8004B45593A203030300D
:10007000323030303130423634303130343030305C
:10008000323030303130423634303130340A00547E
:10009000484953205448494E472043414E20414C43
:1000A000534F20424520534F4D455448494E472019
:1000B000454C53450A0050505050505050505050ED

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.

Dump

Figure 1 : Exemple de dump d'une mémoire EEPROM SPI avec un Arduino.

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 :

$ hexdump -C dump_Flash.ascii |more

0000000  0c 94 35 00 0c 94 5d 00  0c 94 5d 00 0c 94 5d 00  |..5...]...]...].|

0000010  0c 94 5d 00 0c 94 5d 00  0c 94 5d 00 0c 94 5d 00  |..]...]...]...].|

*

00005c0  ed 91 fc 91 51 97 80 81  85 ff f1 cf c6 01 69 83  |....Q.........i.|

00005d0  0e 94 6d 02 69 81 eb cf  83 8d e8 0f f1 1d e3 5a  |..m.i..........Z|

00005e0  ff 4f 60 83 d6 01 5b 96  0c 93 5b 97 52 96 ed 91  |.O`...[...[.R...|

00005f0  fc 91 53 97 80 81 80 62  0c c0 d6 01 56 96 ed 91  |..S....b....V...|

0000600  fc 91 57 97 60 83 50 96  ed 91 fc 91 51 97 80 81  |..W.`.P.....Q...|

0000610  80 64 80 83 81 e0 90 e0  0f 90 df 91 cf 91 1f 91  |.d..............|

0000620  0f 91 ff 90 df 90 cf 90  08 95 ee 0f ff 1f 05 90  |................|

0000630  f4 91 e0 2d 09 94 f8 94  ff cf 54 68 65 72 65 20  |...-......There |

0000640  69 73 20 61 20 68 69 64  64 65 6e 74 20 6b 65 79  |is a hiddent key|

0000650  20 69 6e 20 74 68 65 20  66 6c 61 73 68 20 6d 65  | in the flash me|

0000660  6d 6f 72 79 2c 20 66 69  6e 64 20 69 74 21 00 00  |mory, find it!..|

0000670  00 00 00 b0 02 f1 01 32  02 4b 02 3d 02 8e 02 00  |.......2.K.=....|

0000680  df 92 ef 92 ff 92 cf 93  df 93 6b 01 7c 01 0e 94  |..........k.|...|

0000690  1c 03 eb 01 c1 14 d1 04  e1 04 f1 04 89 f0 0e 94  |................|

00006a0  63 06 0e 94 1c 03 6c 1b  7d 0b 68 3e 73 40 90 f3  |c.....l.}.h>s@..|

00006b0  81 e0 c8 1a d1 08 e1 08  f1 08 c8 51 dc 4f ea cf  |...........Q.O..|

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 -E -K 512 dump_Flash.ascii

DECIMAL    HEXADECIMAL     ENTROPY

---------------------------------------

0          0x0             0.757220

512        0x200           0.706036

1024       0x400           0.790745

1536       0x600           0.785486

2048       0x800           0.783419

2560       0xA00           0.744518

3072       0xC00           0.725470

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

Entropy

Figure 2 : Exemple de résultat d'analyse d'entropie par binwalk.

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.

Hidden_key

Figure 3 : Résultat d'analyse d'entropie par binwalk d'un contenu de mémoire contenant une clé de chiffrement.

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.

$ binwalk -E -K 256 -B dump_Flash.ascii

DECIMAL   HEXADECIMAL   DESCRIPTION

----------------------------------------------------------

8183      0x1FF7        PEM RSA private key


RSA_key_extraction

Figure 4 : Résultat de découverte de contenu préformaté (clé RSA) par binwalk.

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) :

Hooking

Figure 5 : Connexion du JTAGulator avec une carte-mère 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.

Welcome to minicom 2.7

OPTIONS: I18n

Port /dev/ttyUSB0

Press CTRL-A Z for help on special keys


   Welcome to JTAGulator. Press 'H' for available commands

:h

JTAG Commands:

I   Identify JTAG pinout (IDCODE Scan)

B   Identify JTAG pinout (BYPASS Scan)

D   Get Device ID(s)

T   Test BYPASS (TDI to TDO)


UART Commands:

U   Identify UART pinout

P   UART passthrough


General Commands:

V   Set target I/O voltage (1.2V to 3.3V)

R   Read all channels (input)

W   Write all channels (output)

J   Display version information

H   Display available commands

:v

Current target I/O voltage: Undefined

Enter new target I/O voltage (1.2 - 3.3, 0 for off): 3.3

New target I/O voltage set: 3.3

Ensure VADJ is NOT connected to target!

- 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 :

:u

Enter text string to output (prefix with \x for hex) [CR]:  PRINT

Enter number of channels to use (2 - 24): 3

Ensure connections are on CH2..CH0

Possible permutations: 6

Press spacebar to begin (any other key to abort)...

JTAGulating! Press any key to abort.....


TXD: 1

RXD: 0

Baud: 57600

Data: ....I. [ F9 CA 9A E9 49 AD ]


TXD: 1

RXD: 0

Baud: 76800

Data: ..@./. [ 0B AE 40 FA 2F B5 ]


TXD: 1

RXD: 0

Baud: 115200

Data: PRINT  [ 50 52 49 4E 54 ]


TXD: 1

RXD: 0

Baud: 153600

Data: ....!. [ DA A6 F3 2E 21 FF ]


UART scan complete!

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.

:p

Enter new TXD pin [0]: 1

Enter new RXD pin [0]: 0

Enter new baud rate [0]: 115200

Enable local echo? [y/N]: N

Entering UART passthrough! Press Ctrl-X to abort...


# ls

CVS   dev   lib        mnt   sbin   var

bin   etc   linuxrc    proc  usr    webs

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é.

:i

Enter number of channels to use (3 - 24): 4

Ensure connections are on CH3..CH0.

Possible permutations: 24

Press spacebar to begin (any other key to abort)...

JTAGulating! Press any key to abort...

TDI: N/A

TDO: 1

TCK: 0

TMS: 2

TRST#: 3


IDCODE scan complete!


:d

TDI not needed to retrieve Device ID.

Enter new TDO pin [3]: 1

Enter new TCK pin [1]: 0

Enter new TMS pin [0]: 2

Enter number of devices in JTAG chain [2]: 1

All other channels set to output HIGH.


Device ID: 0001 0001111111111111 11110001111 1 (0x11FFFF1F)

-> Manufacturer ID: 0x78F

-> Part Number: 0x1FFF

-> Version: 0x1

IDCODE listing complete!

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.

:b

Enter number of channels to use (4 - 24): 6

Ensure connections are on CH5..CH0.

Possible permutations: 360

Press spacebar to begin (any other key to abort)...

JTAGulating! Press any key to abort................

TDI: 4

TDO: 1

TCK: 0

TMS: 2

TRST#: 3

Number of devices detected : 1

…..........

BYPASS scan complete!

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




Articles qui pourraient vous intéresser...

CVE-2020-3433 : élévation de privilèges sur le client VPN Cisco AnyConnect

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Cet article explique comment trois vulnérabilités supplémentaires ont été découvertes dans le client VPN Cisco AnyConnect pour Windows. Elles ont été trouvées suite au développement d’un exploit pour la CVE-2020-3153 (une élévation de privilèges, étudiée dans MISC n°111). Après un rappel du fonctionnement de ce logiciel, nous étudierons chacune de ces nouvelles vulnérabilités.

Introduction au dossier : Sécurisez vos serveurs et votre réseau local

Magazine
Marque
Linux Pratique
HS n°
Numéro
49
Mois de parution
novembre 2020
Domaines
Résumé

2020 aura été une année marquante pour nos vies et nos sociétés. Il aura fallu se réinventer, trouver des solutions à des situations exceptionnelles. Dans les entreprises, l'Éducation ou la Santé, la mobilisation des ressources informatiques aura été maximale. Nos infrastructures auront ployé, tangué, parfois presque craqué, mais au final, cela aura tenu.

Passez à nftables, le « nouveau » firewall de Linux

Magazine
Marque
Linux Pratique
Numéro
122
Mois de parution
novembre 2020
Domaines
Résumé

Le firewall est un élément important pour sécuriser un réseau. Il est prouvé que la sécurité par l’obscurantisme ne fonctionne pas. Ce n’est donc pas une bonne idée d’utiliser une boîte noire en priant pour que tout se passe bien. Un bon firewall est donc installé sur un système d’exploitation libre. Linux fait évoluer le sien d’iptables vers nftables. Nous montrons dans cet article comment débuter avec la nouvelle mouture.

Introduction au dossier : Sécurité de l’orchestrateur Kubernetes

Magazine
Marque
MISC
Numéro
112
Mois de parution
novembre 2020
Domaines
Résumé

Ce dossier s’intéresse à un système de plus en plus déployé aujourd’hui, à savoir l’orchestrateur Kubernetes. Au-delà de l’effet de mode évident dans son adoption actuelle, l’intérêt croissant pour ce projet nous amène forcément à nous poser une question essentielle : qu’en est-il de sa sécurité ? Devenu un standard de facto pour l’orchestration de conteneurs, Kubernetes, qui signifie gouvernail en grec, présente une architecture complexe et les possibilités de se tromper avec des conséquences importantes pour la sécurité d’un cluster sont nombreuses.