Sécurité embarquée : et si on essayait de hacker un capteur du commerce?

Analyse mémoire d’un capteur

Le monde de l’IOT connaît une croissance exponentielle. Le nombre d’objets disponibles sur le marché est de plus en plus important et cela n’est pas passé inaperçu auprès des hackers.

Les systèmes embarqués peuvent être des points d’entrées vers un système plus global. Ils peuvent aussi permettre d’accéder à des données plus ou moins sensibles dans le but de soutirer des informations.

Des normes se mettent en place afin de donner des préconisations dans la conception des systèmes embarqués. La norme IEC62443 est maintenant plébiscitée pour couvrir ce besoin. Le paragraphe 4.2 de la norme couvre des points qui concernent les systèmes embarqués. Des articles intéressants sont disponibles sur la toile (IECC62443).

L’ANSI fournit aussi un guide avec des préconisations concernant la sécurité (Guide ANSI).

Nous ne serons pas étonnés si de futurs normes émergent et obligent les constructeurs à respecter un certain niveau de sécurité sur les objets connectés…

Qu’est qu’on hacke aujourd’hui?

Les constructeurs de microcontrôleurs sont de plus en plus vigilants et fournissent des sécurités de plus en plus complexes afin de protéger des informations sensibles.

C’est le cas de ST Microélectronics qui au fur et à mesure des nouvelles versions ajoute des fonctionnalités de plus en plus complexes (trust zone, firewall, etc…) (STM32 securities)

Malgré toutes les protections mises en place, la charge reste aussi aux architectes et aux développeurs de fournir des solutions sécurisées de bout en bout, d’appliquer des méthodes de travail qui assurent que la sécurité du système sera garantie.

Dans notre analyse, nous avons essayé de récupérer des informations sensibles sur un capteur de température Lorawan disponible à l’achat.

Nous opérons donc une attaque physique sur le capteur.

Pour cela nous avons développé un outil permettant d’accéder aux mémoires du stm32.

Nous allons essayer d’analyser le comportement d’un produit LORAWAN afin de déterminer si des failles de sécurité sont visibles sur le matériel. Une des informations importantes dans le protocole LORAWAN est la clé applicative (appkey). Cette clé permet de chiffrer les informations et n’est pas censée être accessible. (lorawan security)

Découverte du produit

Le produit est tout d’abord déballé afin de regarder ce qu’il contient.

Il est alimenté par une pile en 3.6V. Le composant principal est un stm32l052.

La sortie SWD, qui nous sert à connecter le debugger, est visible (nous avons juste soudé un connecteur pour faciliter le debug). Les signaux sont même notés sur le PCB.

Le capteur possède une interface de configuration (via cable usb) qui fonctionne avec un outil PC. Dans notre étude, nous n’allons pas exploiter de potentielles failles de sécurité sur cette interface.

Produit à tester

Début de l’investigation

La première étape consiste à accéder au système via le debugger afin de vérifier les types de protections appliqués. Sur un système non protégé, il sera facile de lire la mémoire flash afin de récupérer son contenu.

Malheureusement, la mémoire flash est protégée en RDP level 1 (RDP c’est quoi) Il ne sera donc pas possible de lire la Flash…

Ce niveau de protection est un des plus simples à appliquer sur un stm32. Il garantit une protection minimum sur la mémoire et évite tout simplement qu’un concurrent vienne copier le firmware du produit afin de faire une simple copie ou de désassembler le code pour récupérer des informations intéressantes.

En revanche, en RDP level 1, l’accès à la SRAM est toujours possible. Le seul souci que nous notons est que le système se freeze dès qu’il détecte que le connecteur SWD tente de se connecter au STM32. Nous sommes donc capables de visualiser l’état de la RAM à un instant donné. Nous remarquons aussi que le connecteur SWD est désactivé par le logiciel embarqué au démarrage du système. Il ne nous est donc pas possible d’aller lire la mémoire RAM à n’importe quel moment…

Toutefois, il existe une petite faille à ce système. Le contenu de la RAM est disponible pendant environ 300ms pendant que le système démarre. Si nous arrivons à accéder au SWD pendant ce laps de temps, il nous est possible de visualiser l’état de la RAM pendant ce laps de temps. Cela doit sûrement correspondre aux étapes d’initialisation du système (bootloader, démarrage du firmware).

L’utilisation de la sonde SWD via l’outil ST ne nous permettant pas d’avoir les niveaux de réactivité requis, nous avons développé un outil basé sur une nucléo qui nous permet de piloter l’alimentation de la carte à tester, le reset ainsi que le SWD. Le logiciel développé sur cette carte permet au final de récupérer le contenu de la RAM à un instant T suite au démarrage de la carte à tester. Cela peut-être très intéressant si nous souhaitons analyser la pile d’exécution de notre système en mode pas à pas.

Carte de hacking reliée à la carte à tester.

Notre outil de pilotage de carte est développé en python et permet de visualiser la mémoire à un temps t, t+1, t+2 etc..

Outil maison de visualisation de la SRAM

Accès aux informations sensibles

L’analyse du démarrage de la carte ne nous a pas apporté d’informations intéressantes. Nous observons des évolutions dans l’état de la RAM mais il est difficile d’en conclure quelque chose. Il semblerait toutefois qu’une copie en mémoire soit faite car une partie de la mémoire évolue avec ce qui semblerait être le contenu de la flash. Cela resterait à confirmer.

Nous avons donc étudié une autre approche. Lors du reset du STM32, le contenu de la SRAM est maintenu. Cela signifie donc que nous nous sommes capable de lire le contenu de la RAM juste avant que le système démarre, nous sommes donc capables de lire le contenu de la RAM juste avant que la carte ait été réinitialisée.

La procédure est donc la suivante :

Nous possédons la clé de chiffrement du capteur et nous allons tenter de savoir si cette dernière est accessible.

Nous allons donc nous servir de cet équipement pour déterminer l’emplacement de la clé dans la mémoire à un moment T.

Nous avons pu valider dans un premier temps le concept en lisant d’identifiant du produit. Ce dernier apparaît en mémoire à partir d’environ 1.3 secondes. Notre outil nous permet d’atteindre une précision de l’ordre de 2us. Cela nous donne donc la possibilité d’être assez précis dans la lecture de la SRAM.

Nous avançons donc petit à petit dans le temps de manière à trouver les informations qui nous intéressent.

Le capteur utilise sa clé pour s’enregistrer sur le réseau. Cette opération a lieu au début du démarrage du produit. En analysant la mémoire petit à petit, on finit par tomber sur la clé (ici ff 48 df 9e 1b 1b 33 96 33 cc 00 62 f6 5d 41 70).

Analyse mémoire et visualisation de la clé de cryptage (973/5)

La clé est visible en fin de SRAM. La fin de la SRAM est communément utilisée pour la stack ou pile. C’est une zone de la mémoire qui sert basiquement à conserver le contexte d’exécution du programme. Il semblerait donc qu’elle soit chargée dans cette zone mémoire (variable locale à une fonction) et non dans une variable “globale” qui aurait été stockée dans une autre zone mémoire (data ou bss). C’est la façon la plus sûre d’accéder à une variable afin de ne pas la laisser “trop longtemps” à la vue d’esprits malveillants.

A noter que, sur une version plus ancienne du logiciel de la cible, il était possible de retrouver la clé dans une zone “statique”. Le constructeur a donc dû prendre en considération cette faille afin de faire les corrections nécessaires.

Conclusion

Le produit que nous venons d’analyser possède un certain nombre de protections qui semble éviter la copie, la modification. Ce niveau de protection va déjà au delà de beaucoup de produits IOT commercialisés… Toutefois, une partie des informations est toujours disponible sur la SRAM. On retrouve la clé de chiffrement du système. Pour une personne malveillante, cette faille pourrait être exploitée pour se faire passer pour le dit équipement.

En travaillant un peu plus sur l’exécution du programme, il serait envisageable de déterminer d’autres informations « secrètes » (nonce… etc).

Grâce à la clé de chiffrement, en se faisant passer pour le capteur, on peut donc potentiellement avoir un impact sur le processus décisionnel qui suit l’interprétation de la donnée. Que se passerait-il si une sonde de température envoie 10 degrés au lieu des -15 degrés dans un entrepôt sous contrôle…

Cela supposerait bien entendu d’avoir un accès physique à cette sonde, mais cela reste possible.

La tache est ardue mais faisable ! Elle est rendue beaucoup plus simple avec des outils d’automatisation tel que celui que nous avons construit (carte d’adaptation avec son logiciel de pilotage et de visualisation). Tout ceci demande tout de même des compétences assez avancées sur la structure des microcontrolleurs et leur fonctionnement.

À noter que dans des versions plus récente de STM32, une sécurité garantissant le reset de la SRAM au moment du reset du système a été ajoutée. Le constructeur a dû se rendre compte qu’il avait quelques trous dans la raquette.

Comme indiqué dans cet article, un effort non négligeable dans la conception ainsi qu’une rigueur dans les développements sont primordiaux pour s’assurer que notre produit sera correctement protégé. Ce niveau d’exigence est bien entendu à mettre en perspective par rapport aux enjeux en terme sécurité que représente l’application visée par le produit.

Article rédigé par : Ludovic Charpentier (Wi6Labs)