Première édition de la conférence Hardwear.io

Début octobre se déroulait la première édition de la conférence Hardwear.io, traitant des objets connectés et de leur sécurité. Elle se déroulait sur deux jours, et proposait un ensemble de présentations intéressantes sur le thème des objets connectés, de la sécurité des systèmes embarqués et des puces électroniques.

Keynote jour 1 – Jon Callas (Silent Circle)

La keynote de l’évènement a été réalisée par Jon Callas, expert reconnu en sécurité informatique et cofondateur de PGP Corporation. Celui-ci a dressé un état des lieux de la sécurité des systèmes embarqués (ce qui inclut les objets connectés), en prenant pour exemple le Blackphone produit par sa société, Silent Circle.

Pour Callas, les bugs font partie intégrante du cycle de vie des objets connectés et ne devraient pas être un problème en soit: il y en aura toujours (notamment dans les briques logicielles sur lesquelles repose le firmware) mais ils devraient être éliminés par des mises à jour efficaces.

Et il touche là un point sensible. Les systèmes embarqués et connectés doivent impérativement permettre une mise à jour OTA (« over the air »), c’est-à-dire une mise à jour à distance réalisée au travers d’un canal de communication sécurisée. De son point de vue, c’est même la première fonctionnalité à mettre au point lors de la phase de conception du produit. De cette façon, on s’assure de pouvoir corriger tout type de problème à distance.

De plus, les possibilités de signature de firmware existent, permettant d’éviter une compromission des équipements. Cependant, il peut être judicieux dans certains cas de figure de permettre aux curieux de bidouiller le logiciel: il ne peut en ressortir que des améliorations (identification de bugs ou nouvelles fonctionnalités).

Got HW crypto ? – Gunnar Alendal and Christian Kison

La première présentation de la journée était particulièrement intéressante: Gunnar et Christian se sont intéressés de près à des disques durs chiffrés et leur sécurité. Et ce qu’ils ont trouvé n’est pas beau à voir.

Il existe deux catégories de disques durs chiffrant: ceux reposant sur un bridge USB/Sata effectuant le chiffrement (première génération), et ceux dont le disque lui-même s’occupe du chiffrement (seconde génération). Le principe de chiffrement est cependant basé sur les mêmes concepts: une clef de chiffrement (Key Encryption Key) est dérivée d’un mot de passe, puis utilisée pour déchiffrer la clef employée pour le chiffrement des données (Data Encryption Key). Cette dernière est une clef AES unique et persistante, lorsque l’on change le mot de passe seule la version chiffrée de la DEK change.

Sur les disques de première génération, c’est l’ordinateur sur lequel est connecté le disque qui dérive la KEK à partir du mot de passe saisi par l’utilisateur, et la fournit au bridge USB/Sata via la connectique USB. Le bridge récupère ensuite la version chiffrée de la DEK, stockée dans une mémoire électronique (EEPROM), et la déchiffre afin de pouvoir accéder aux données du disque. Cela signifie donc qu’une version chiffrée de la DEK est stockée dans cette mémoire, et que si l’on peut y avoir accès alors il est possible d’extraire cette donnée.

Cependant, cette DEK stockée (que nous appellerons eDEK) est chiffrée et n’est pas directement utilisable. Les chercheurs se sont alors rendus compte que lorsqu’aucun mot de passe n’est paramétré, une KEK par défaut est utilisée afin de déchiffrer l’eDEK stockée dans l’EEPROM. Si un mot de passe a été paramétré, il devient alors possible de tenter une attaque par force brute sur la KEK, mais cette approche est peu efficace.

Afin de s’éviter cette peine, ils ont cherché à identifier de possibles portes dérobées dans la phase d’authentification réalisée par certains composants des disques, et en ont trouvé. Deux des composants employés sur ces disques de première génération offrent des moyens alternatifs permettant de récupérer la KEK. Le premier d’entre eux conserve une copie de la KEK chiffrée avec une clef fixe présente dans le firmware, tandis que le second valide la KEK fournie par l’utilisateur à l’aide d’une simple comparaison octet par octet avec une version déchiffrée de celle-ci, offrant la possibilité de contourner le besoin de KEK via un patch du firmware.

En ce qui concerne les disques intégrant le chiffrement en leur sein, ils reposent pour la grande majorité sur la fonctionnalité de sécurité fournie par le standard ATA (ATA Security feature set). L’un de ces disques implémente une commande cachée permettant de récupérer la KEK, ce qui permet de la lire et de déverrouiller l’accès au contenu du disque.

A ce stade de leur présentation, 4 disques sur les 6 testés ont montré au moins une faiblesse permettant de récupérer les données chiffrées stockées sur ceux-ci.

La dernière partie de la présentation abordait la création de la DEK côté constructeur: celle-ci est générée une fois pour toute lors de la fabrication du disque, et écrite dans la mémoire de certains composants.

Cette génération de DEK devrait être purement aléatoire et non-biaisée, toutefois leur analyse du firmware montre qu’une source d’aléa faible a été employée (via un générateur pseudo-aléatoire présent dans le disque) combinée à un valeur dérivée du temps. Cette entropie faible les a amenés à réussir à retrouver la DEK simplement à l’aide de certaines données accessibles, qui à cause de cette entropie laissent fuiter des information sur l’état du générateur pseudo-aléatoire. Un rapide bruteforce permet ensuite de retrouver la DEK générée, et d’accéder au contenu du disque.

En conclusion, presque tous les disques chiffrés ont été en totalité cassés (sauf un en partie cassé), à cause de faiblesses de conception et d’implémentation cryptographique biaisée.

Advanced Attack Methodologies against Security Microcontrollers – Marcus Janke and Dr. Peter Laackmann

Marcus et Peter ont fait un état de l’art des attaques existantes sur les micro-contrôleurs: les attaques de manipulation, d’observation et semi-invasives. Ils ont initalement réalisé ces différentes attaques avec des moyens dérisoires, dans le plus pur esprit du hacking, avec un résultat bluffant.

Ainsi, ils expliquent comment ils ont réalisé il y plusieurs années une image aux rayons X d’un puce à l’aide d’un tube cathodique et de papier photo, ou encore leur méthode pour réaliser des sondes nanométriques à l’aide de tiges de sustentation de filament d’ampoules électriques.

De même, ils ont réalisé des sondes de capture de signal à l’aide de micro-bobines présentes sur les têtes de lecture de disques durs, et ont pu stocker les valeurs échantillonnées sur un disque dur de 1.4TB.

Enfin, ils ont démontré la faisabilité des attaques par injection de faute via un rayon laser issu d’un lecteur de disque laser d’époque.

Cette présentation était une bonne piqûre de rappel des attaques existantes, mais aussi la démonstration que des outils amateurs abordables peuvent permettre la réalisation de telles attaques, bien que du matériel professionnel (très cher) fasse bien mieux et soit plus efficace.

Beaglebone (Bl|H)ack – Joe Fitzpatrick

Encore une fois, une présentation très intéressante sur les manières de transformer un Beaglebone Black en PirateBus amélioré.

Joe Fitzpatrick a ainsi présenté les différents ports présents sur le Beaglebone Black, et des outils développés afin d’offrir les fonctionnalités du PirateBus si ce n’est plus avec un coût moindre.

Le module complémentaire (cape) BeagleLogic pour le Beaglebone permet de réaliser à bas coût un analyseur logique 14 voies, permettant un échantillonnage à 100M samples/sec., basé sur sigrok.

Une couche logicielle a été développée afin de récupérer facilement les échantillons, et une interface web permet d’analyser ceux-ci.

Joe a aussi dévoilé un prototype de cape permettant de s’interfacer avec divers composants mémoire et supportant différents voltages (typiquement 3.3V et 5V) avec une adaptation automatique de ceux-ci.

Le support du protocole JTAG est aussi en cours, compatible avec OpenOCD.

Keynote Jour 2 – Harald Welte

La keynote de la seconde journée de conférence traitait de la sécurité des réseaux téléphoniques mobiles, et de la faible inertie des opérateurs.

Harald a démontré au travers de plusieurs exemples flagrants que non seulement les technologies employées étaient vulnérables, mais que leurs remplaçantes existaient déjà mais n’ont été adoptés que bien trop tard.

Il a aussi insisté sur le fait qu’une partie seulement des infrastructures a été auditée, à cause notamment de pressions exercées par les fabricants de matériel afin que leurs produits ne soient pas testés. De plus, les procédures suivies par certains opérateurs ne sont pas sécurisées: certains d’entre eux transmettent par exemple des listings d’IMSI et les clefs associées dans des fichiers CSV par courriel.

Enfin, la réponse à incident et aux problématiques de sécurité de la part des fabricants de matériel est inexistante, et aucun suivi de vulnérabilités n’est en place.

1 guy looking at iLo 2 and 3 for 4 days and finding more than 5 bugs – Veysel Özer

Cette présentation de Veysel Özer traitait des problèmes de sécurité de serveurs iLo du constructeur Hewlett Packard. Ce type de serveur est notamment utilisé pour sa fiabilité annoncée par le constructeur.

Veysel démontre au travers de ses recherches que non-seulement cette fiabilité est facilement mise à mal, mais que des impacts plus dommageables sont possibles sur différentes versions de ce système.

Des bugs variés ont ainsi pu être identifiés, de la simple possibilité de bruteforce du formulaire d’authentification de l’interface web à l’exploitation de dépassement de zone mémoire (buffer overflow) ou encore de bogue de format (format string).

Plus étonnant encore, la gestion des caractères non-imprimables est purement et simplement inexistante, permettant de provoquer des bips intempestifs sur l’interface d’administration console, voire même de créer des utilisateurs invisibles qui n’apparaîtront aucunement dans la liste des utilisateurs !

Enfin, la fiabilité du serveur est mise à mal par la possibilité de le rendre complètement inopérant via l’envoi d’une simple requête HTTP. Bref, en partant de différentes versions du firmware proposées par HP, Veysel a démontré les différentes faiblesses des versions 1 à 5 de iLo.

Attacking hardware for software reversers: Analysis of an encrypted HDD – Raphaël Rigo & Joffrey Czarny

A la différence des tests et résultats démontrés le jour précédent sur les disques chiffrés, Joffrey expose une toute autre complexité au travers de l’analyse d’un disque dur chiffré à authentification matérielle.

Le disque dur analysé, un Zalman ZM-VE400, a été le fil conducteur de cette présentation durant laquelle Joffrey a exposé non seulement les méthodes de capture et d’analyse de composants mémoire et de circuit électronique, mais aussi les différentes difficultés rencontrées.

Ainsi, la présence d’un firmware chiffré (à la différence de ceux analysés par Christian Kison et Gunnar Alendal) a rendu la rétro-ingénierie relativement difficile, car seules les interfaces de communication ont pu être analysées. De fait, des tests basiques ont été mis au point afin de déterminer via une analyse comportementale le principe de fonctionnement de ce firmware.

Leur analyse a ainsi permis de démontrer qu’une partie du disque servait au stockage de méta-données utilisées par celui-ci pour déchiffrer le contenu (et valider le mot de passe), mais ils se sont rapidement retrouvés à cours de moyens sans firmware à désassembler. Malgré cela, ils ont tout de même pu obtenir une vision assez précise du fonctionnement de ce disque chiffré, sans pour autant réussir à casser sa sécurité.

Ce que l’on retient de cette présentation, ce n’est pas le résultat de l’analyse effectuée par ses auteurs, mais bel et bien les techniques et outils employés pour y arriver: imagerie aux rayons X pour l’analyse des pistes du circuit, BusPirate pour le dump de mémoire via SPI, et analyseur logique.

NSA Playset: Bridging the Airgap without Radios – Michael Leibowitz

Suite aux révélations du lanceur d’alerte Edward Snowden, le monde entier a pu découvrir les moyens techniques que possède la NSA américaine pour espionner et notamment des systèmes miniaturisés embarqués permettant de prendre le contrôle de machines normalement déconnectées de tout réseau.

Et c’est tout aussi naturellement qu’un groupe de hackers essaie de recréer ces différents outils, et notamment un clone de BLINKERCOUGH. BLINKERCOUGH est un implant utilisant la connectique VGA pour offrir un canal de communication basé sur un réseau maillé infra-rouge. Ce système est performant, d’autant plus que les différents noeuds du réseau maillé sont situés dans la même pièce.

Le connecteur VGA ne possède pas seulement un ensemble de broches permettant de faire passer l’information relative à l’image, mais aussi un bus I²C généralement employé pour procurer à la machine des méta-données sur l’écran lui-même. L’implant utilise donc ce canal de communication pour permettre à une brique logicielle de communiquer avec un composant caché dans le câble lui-même, et donc difficilement détectable. La machine est finalement joignable via le réseau mesh, alors qu’elle ne possède initialement aucune connexion au réseau.

From off-the-shelf embedded devices to research platforms. Two case studies: a PLC and a SSD – Lucian Cojocar & Herbert Bos

La dernière présentation à laquelle j’ai assisté fut une des meilleures à mon sens. Elle traitait du recyclage d’équipements qui prennent la poussière afin de leur offrir une nouvelle vie: ils peuvent ainsi servir d’équipement permettant de tester différents composants, ou tout simplement être détournés de leur usage premier (on parle alors de re-purposing).

Deux équipements étaient abordés durant cette présentation:
– un PLC (automate industriel programmable), sur lequel les chercheurs ont réussi à intégrer un serveur gdb afin de pouvoir déboguer le système,
– un disque SSD, pour pouvoir implémenter leur propre interface de stockage.

La procédure suivie est globalement similaire, bien que les objectifs soient différents:
– identifier un moyen de récupérer le firmware, de le modifier et de le réécrire,
– identifier un canal de communication (utile pour déboguer les applications),

La première étape nécessite une reconnaissance des différents composants et connecteurs, afin dans le meilleur des cas d’identifier un composant mémoire stockant le firmware (SPI) ou un port dédié au débogage (JTAG). Une fois cet élément identifié, une extraction du firmware est effectuée, puis un firmware spécialement conçu est inséré à sa place. On teste alors la possibilité de modifier le firmware, afin par la suite de pouvoir identifier des interfaces de communication.

Ces interfaces de communication sont identifiées d’une part via une analyse de circuit imprimé, et validées par la conception d’un firmware dédié et l’envoi d’information au travers de ces interfaces. A l’aide d’un analyseur logique (ou d’un système capable de s’interfacer), on valide le fait que le code injecté est capable de communiquer avec l’environnement extérieur.

Une fois ces deux fonctionnalités opérationnelles, la réutilisation de composants présents sur le circuit imprimé est facilitée, et la conception du programme final peut être démarrée.

C’est un très bon moyen d’éviter de perdre du matériel, voire de pouvoir ressusciter du matériel « brické ».

Conclusion

Cette première édition de Hardwear.io était un franc succès, avec bon nombre de présentations variées et intéressantes. On regrettera juste que deux présentations aient été annulées à cause de pressions exercées par les fabricants de matériel, peu enclins à voir des problèmes affectant leurs produits diffusés dans ce type d’évènement.

On attend avec impatience l’édition 2016 !