SecurityInsider
Le blog des experts sécurité Wavestone

Bring Summer Back ! Compte-rendu des conférences de cet été - HARDWEAR.IO



 

 


Nous terminons ce flash-back sur les conférences de cet été par un compte-rendu de Hardwear.io . Des conférences différentes et passionnantes sur les sujets du hardware hacking, dans la très belle et chaleureuse ville de La Haye (voir photo ci-dessus).

Keynote d'ouverture


La Keynote d'ouverture fût donnée par Kate Temkin, une hardware-hacker notamment connue pour avoir réussi à craquer la Nintendo Switch.

Introduction

L'état de la sécurité hardware est déplorable. Kate estime que le niveau de sécurité hardware dans les produits actuels est équivalent à l'état de la sécurité software d'il y a dix à quinze ans : la notion de sécurité n'est pas du tout prise en compte dans les projets. Des failles béantes sont présentes dans les produits mais ne sont pas corrigées et ne peuvent souvent pas être corrigées. Ceci est dû à une ignorance et une absence d'investissement de la part des industriels.

Le grand public ne comprend pas le hardware (encore moins que l'informatique classique), les publicités peuvent donc être mensongères sans aucune conséquence pour les industriels; comme par exemple Bitfi qui prônait être impossible à hacker (cf : Bitfi: you wouldn't steal my cloins). Les industriels et le public ne portent pas grande attention aux risques des attaques physiques car ces attaques sont définies comme des attaques locales et donc les prérequis perçus comme trop forts.

Kate soulève la problématique du cloisonnement des majeures dans le système éducatif. En effet, les étudiants dans chaque majeure ne prêtent pas attention aux autres majeures et estiment que les autres sont des détails d'implémentation. Par exemple ceux qui créent le hardware ne souhaitent pas coder et les développeurs estime qu'ils n'ont pas à souder.
Les électroniciens, le génie logiciel, les ingénieurs informatiques sont séparés et ne travaillent pas ensemble. Ce cloisonnement est d'autant plus problématique car les systèmes sont de plus en plus unitaires et les différentes disciplines sont de plus en plus liées, les microcontrôleurs sont livrés avec une première couche logicielle par exemple. De plus, le logiciel aura beau être sécurisé, si des failles hardware existent, toute la sécurité du produit est remise en cause. La Nintendo Switch par exemple est durcie au niveau logiciel: il n'est pas possible d'installer un micrologiciel interne d'une version antérieure, mais il a été possible de contourner cette protection grâce à l'accès direct au matériel.

Nintendo Switch

Kate explique par la suite comment elle a pu exploiter la Nintendo Switch grâce aux failles présentes dans les MCU Tegra de Nvidia. Elle soulève les incohérences des tentatives d'application de la sécurité sur les produits et notamment de la politique de la sécurité par l'obscurité.

En effet lorsque un microcontrôleur tel que le Tegra est vendu, un bootloader ainsi qu'une HAL sont présents en ROM. Ces codes ne sont pas vérifiés car les constructeurs appliquent la politique du don't look, don't touch (ne pas regarder, ne pas toucher). L'incohérence provient de la protection apportée sur la bootROM sur les produits en production (la Nintendo Switch) mais ne l'est pas sur les cartes de développement, de plus son code est disponible sur internet car elle est open source. L'intérêt d'une telle protection peut être questionné. Cela provient du fait que les différents cœurs de métier ne discutent pas entre eux, qu'aucune personne n'a de vision globale sur le matériel et le logiciel et qu'aucun audit interne ou externe n'a été effectué sur le produit. Enfin le problème culturel prônant la mentalité "qui va s'intéresser à mon produit?" est encore trop présente chez les constructeurs de systèmes embarqués, à tord, comme a pu le démontrer le botnet Mirai.

Le hack de la Nintendo Switch a été possible grâce à la présence d'un memcopy dans la bootROM, dont la longueur était contrôlée par l'utilisateur (CVE-6242 Fusée Gelée : https://nvd.nist.gov/vuln/detail/CVE-2018-6242) qui a été trouvé grâce à l'accès au code source et qui a pu alors être exploité sur la Nintendo Switch.

Conclusion et conseils


Cet évènement n'est qu'une mauvaise situation parmi de nombreuses situations catastrophiques dans les systèmes embarqués. Il y a un réel besoin de changer les mentalités et de faire avancer la maturité sur la sécurité hardware. Pour cela, Kate donne plusieurs recommandations pour faire évoluer et grandir la sécurité
  • La sécurité hardware est facile à apprendre, les mêmes mécanismes d'apprentissage de la sécurité software s'appliquent. D'autant plus que les outils sont accessibles et faciles d'utilisation.
  • Il d'autant plus nécessaire d'établir ou de rétablir le dialogue entre spécialisations pour améliorer l'état de la sécurité hardware. Il faut combler l'écart entre les ingénieurs logiciel et matériel et travailler ensemble pour faire progresser le niveau global de la sécurité.
  • "Il est grand temps de tuer nos héros", par là Kate entend  que chacun peut apporter sa pierre à l'édifice. La sécurité hardware est accessible et plus facile que ce qu'il n'y paraît.
  • Il est nécessaire de produire des formations et des supports pour les personnes voulant apprendre. Des tutoriels, des outils open source ou à faible coût comme le chip-whisperer lite par exemple.
  • Plus il y aura de personnes s'intéressant et se penchant sur la sécurité matérielle, le mieux cela sera pour tout le monde. En effet, le niveau de sécurité globale augmentera et les connaissances aussi tout comme avec la sécurité software il y a 10 ans. Il est impératif que la communauté soit accueillante pour le plus grand nombre.
  • Les vendeurs doivent cesser de cacher leur production et de procéder à la sécurité par l'obscurité. Le hardware n'est pas un détail d'implémentation.
  • Le fait de souder sur un circuit n'est en aucun cas une protection. Le matériel ne protège pas le système "magiquement".
  • L'autonomie, la fréquence, l'espace et le coût ont toujours été les contraintes des systèmes embarqués. La sécurité n'a que très peu de chance d'en devenir une de plus.

There Goes Your PIN - Exploiting Smartphone Sensor Fusion Under Single and Cross User Setting


David Berend a étudié et analysé les mouvements produits sur le téléphone par les actions de frappe sur un clavier de déverrouillage.

En effet tous les téléphones intelligents possèdent un gyroscope, un magnétomètre (boussole) et un accéléromètre. C'est trois éléments permettent de déterminer précisément la position, l'orientation et la géolocalisation du téléphone. C'est ce qui permet notamment de tourner l'écran lorsque l'utilisateur pivote son appareil.

Lorsqu'un utilisateur tape son code pin afin de déverrouiller son téléphone il effectue des mouvements qui pivotent légèrement le téléphone. C'est mouvements peuvent être enregistrés. Ces mouvements sont uniques pour chaque numéro et son spécifiques à chaque enchaînement de deux numéros. En effet le mouvement de 1 vers 2 ne sera pas le même que le mouvement de 4 vers 9.

Afin de pouvoir généraliser cette analyse et donc les données. Un corpus d'enregistrements de frappes de code pin avec la correspondance des codes a été créé. Il a ensuite été possible de procéder à une apprentissage et de déterminer le code pin à partir d'un enregistrement inconnu.

Le présentateur a explicité que les données de l'accéléromètre sont disponibles pour une application installée sur le téléphone mais également pour tout site Web demandant l'autorisation. Comme les utilisateurs vont au plus simple il arrive bien souvent que ces derniers cliquent sur "valider" lorsque une fenêtre de demande apparaît.

Ces éléments ont été testés sur deux téléphones Android uniquement qui permettent pas de représenter la moyenne des terminaux (un Samsung Galaxy S7 et un Google Nexus 5) et par 3 utilisateurs différents. Cependant les résultats d'identification du pin sur des données provenant d'une autre personne que celles qui ont constituées le corpus tombent à 6% de détection alors que les données provenant de la même personne sont détectées à plus de 70%.
La détection est donc possible mais pas sûre.


Bitfi : you wouldn't steal my cloins


Le Bitfi (https://bitfi.com/) est un portefeuille de crypto-monnaies qui a été décrit par ses créateurs comme impossible à pirater ou cracker. Andrew Tierney (aka Cybergibbons) démontre, non sans humour, que le Bitfi contient plusieurs failles matérielles et logicielles et qu'il est possible de récupérer la clef privée du compte de l'utilisateur. Tout au long de l'exposé, les échanges de Tweet entre John McAfee et Cybergibbons étaient présentés dont le fameux "I invented F***ing Security" de John. Les auditeurs ont minutieusement relevé tous les défauts de sécurité et prouvé que toutes les affirmations faites par John McAfee ou Bitfi étaient fausses : le coût du matériel soi-disant important alors que le Bitfi est fabriqué à partir des plans d'un smartphone d'entrée de gamme dont la plupart des composants ne sont pas présents, l'impossibilité de voir l'écran lorsque l'utilisateur n'est pas en face, la différence du numéro de de série sur l'appareil et sur la boite le contenant, l'absence de FCC ID et de certification associée malgré la présence d'une puce Wi-Fi…
Plusieurs attaques sur le matériel et le logiciels ont permis entre autres d'exécuter Doom sur le Bitfi ou de récupérer en mémoire la clef privée du compte ainsi que le sel du hash. En effet, ces éléments sont présents à plusieurs endroits en mémoire même après plusieurs semaines malgré les infirmations de Bitfi.

L'enregistrement vidéo de la présentation est disponible sur YouTube : hardwear.io 2018: Bitfi - You Wouldn't Steal My Cloins by Andrew Tierney (@cybergibbons)


Smart car forensics and Sensor warfare


Les voitures connectées, avenir de l'industrie automobile, embarquent un bon nombre de capteurs ainsi qu'un ordinateur de bord. Les présentateurs expliquent avoir pris le contrôle de l'ordinateur de bord d'une voiture grâce à une faille connue sur l'exécution automatique de fichiers présents sur clef USB lors du branchement. Il leur a été possible par exemple d'installer leur propres applications sur l'ordinateur de bord et ainsi de lister tous les réseau Wi-Fi présents autour de la voiture pour les corréler avec les données GPS. Cette pratique permet de localiser des Wi-Fi ouvert ou vulnérables. Le fait que du code arbitraire soit exécutable sur une voiture soulève les problématiques de virus et notamment de rançongiciels.

Grâce à la pratique d'analyses forensiques les présentateurs on pu analyser la mémoire de l'ordinateur de bord. Il y ont trouvé non seulement la liste des contacts des téléphones qui s'étaient connectés en Bluetooth mais également la liste des appels et la liste des dossiers présents sur les téléphones. Ce dernier point est problématique car certaines applications créent des dossiers portant leur nom :  récupérer la liste des dossiers permet d'obtenir des indices sur les applications installées sur le téléphone. De plus l'historique des destinations favorites est enregistré dans l'ordinateur de bord alors que la voiture fût achetée sans l'option GPS. Il semble que le constructeur puisse l'activer après la vente si l'utilisateur souhaite l'option malgré tout.

Cela pose de vrais problèmes quant à la collecte de données sur les utilisateurs et leur utilisation par les constructeurs. Mais ce problème prend une toute autre dimension lorsqu'il s'agit de voitures de prêt ou de systèmes de partage de voiture. En effet, un attaquant utilisant une voiture de location, pourra récupérer les données personnelles de tous les conducteurs avant lui et installer des programmes ou des virus sur l'ordinateur de bord.

Fault injection on automotive diagnosis protocols


Les hackers s'intéressent de plus en plus aux voitures  et les voitures sont de plus en plus connectées. Elles comportent plusieurs éléments qui peuvent représenter une porte d'entrée sur le système : les services cloud, l'accès au réseau et Internet, la Gateway présente dans la voiture les ECUs (Electronical Control Unit) qui comportent des microcontrôleurs…
Les deux présentateurs expliquent comment ils ont pu accéder au mode privilégié d'un ECU par l'injection de fautes. Pour cela ils se sont munis d'un tableau de bord de voiture contenant un ECU et ont étudié les points faibles de ce dernier. Ils expliquent qu'un microcontrôleur possède une zone de tension d'alimentation et de fréquence de fonctionnement qui lui permettent de fonctionner correctement. Cependant en dehors de cette zone, le comportement n'est pas défini. Si la fréquence ou l'alimentation baissent, le MCU ralentira son fonctionnement jusqu'à s'arrêter dans certains cas. Si la fréquence ou la tension sont trop élevées, le MCU risque de brûler et donc d'être détruit. Cependant, ces comportements ne s'appliquent que pour un maintient de ces conditions extrêmes. En effet, si l'on injecte une surtension mais sur une durée de quelques millisecondes, le MCU ne brûlera pas. Et cela permet de générer des fautes ou des comportements aléatoires.
Pour générer ce type de glitch plusieurs éléments sont à prendre en compte : la durée du glitch, la tension du glitch et le délais entre le déclencheur et le glitch. Comme l'ECU exécute un ordonnanceur, le délais de la réponse varie. Après plusieurs essais, il est possible d'envoyer un glitch au moment ou le Branch entre l'autorisation ou le refus d'accès au mode privilégié  est effectué. Le glitch résulte en l'accès au mode privilégié.
À partir de là, il a été possible de récupérer le firmware en quelques jours pour ensuite en faire la rétro-ingéniérie.

Note de Clôture : Product Security for IoT - mission impossible?


Un top 10 des vulnérabilités trouvées dans les systèmes embarqués a été effectué par Payatu :
  1. Données sensibles codées en dur;
  2. Ports de débogage hardware activés;
  3. Firmware vulnérable;
  4. Stockage des données non sécurisé;
  5. Authentification insuffisante;
  6. Communications non sécurisées;
  7. Configuration non durcie;
  8. Entrées utilisateurs non suffisamment filtrées
  9. Interface avec l'application mobile non sécurisée;
  10. Interface avec le web/cloud non sécurisée.

Les produits embarqués deviennent de plus en plus complexes. L'IoT combine désormais le système embarqué, le cloud, des bases de données contenant des données utilisateurs et leurs analyse grâce au big data.
L'IoT est principalement influencé par les start-ups, ce qui engendre le problème suivant : le time-to-market est une contrainte bien plus importante que la finition ou la qualité du produit et par conséquent que la sécurité. Les start-ups veulent produire un IoT rapidement pour le vendre rapidement et ainsi avoir des retours sur investissement au plus vite. La sécurité est ainsi la dernière préoccupation des start-ups; elles manquent d'expertise et de concentration car chaque personne et multi-tâche et remplit plusieurs rôles. Les grandes entreprises, quant à elles, n'aiment pas le risque et son prêtes à garder un système approximatif plutôt que d'innover.

La sécurité est complexe à quantifier. Comment mesurer le niveau de sécurité d'un produit ?

Connaitre sa position sur la courbe risques/coûts permet d'évaluer la rentabilité de l'investissement de ressources dans l'augmentation du niveau de sécurité

Enfin, ça n'est pas parce qu'aucune vulnérabilité n'a encore été trouvée sur le produit qu'il n'est pas vulnérable; Le temps est le principal facteur qui influe la découverte de failles.

Qu'est ce que les utilisateurs sont près à accepter comme entrave à l'expérience utilisateur pour un gain de sécurité ? En effet les utilisateurs veulent du face-unlock ou du smart-unlock, ils veulent des appareil pratiques et utilisables.

Les optimisations permettant des gains de performances sont généralement la cause qui permet d'effectuer des attaques par side-channel : par exemple les cache ou les prédictions de Branch à l'origine de spectre et meltdown.
Et les correction de ces failles donnent lieu aux pires cas en terme de performances.
Sommes-nous prêts à perdre 50% de performance pour nous débarrasser des caches ?
Le problème est également que les pertes de performance ne sont pas proportionnelles au gains de sécurité engendré par les actions.

Le présentateur finit par donner des conseils pour les différent intervenants dans le milieux de la sécurité et notamment les suivants :

Pour les hackers :
    • Continuez à rechercher des failles et publiez de manière responsable car cela permet de :
        ○ générer de la pression auprès des industriels ;
        ○ révéler le coût du manque de sécurité ;
        ○ créer de la transparence entre votre travail et les industriels mais aussi entre les utilisateurs et les produits ;
    • Comprenez les contraintes des industriels et des ingénieurs : évaluez si la publication de faille rendra le monde plus ou moins sécurisé ;
    • Publiez vos outils en open source :
        ○ Produisez  des outils simples d'utilisation avec des tutoriels, des supports, des exemples…
        ○ Si vous voulez rendre le monde plus sûr, visez les néophytes et non pas les experts.
   
Pour les ingénieurs :
    • Demandez à votre manager de procéder à des audits de sécurité par des tierces parties ;
    • Demandez au moins deux revues ainsi que des retours sur l'intégration ;
    • Considérez les retours comme des remarques constructives et non comme des critiques de votre travail ;
    • Utilisez les ressources en ligne pour vous former et progresser techniquement et ainsi qu'en sécurité.

Perceval ARENOU

Aucun commentaire:

Enregistrer un commentaire