Utilisation de systèmes « hardware » pour les audits de sécurité : une autre voie ? (sous estimée?)

Le monde de la sécurité informatique renoue-t-il avec ses origines : les systèmes électroniques ?

Peu de « spécialistes » du domaine de la SSI s’intéressent aux couches basses qui forment le socle technique de tous les systèmes informatiques : l’électronique, les systèmes embarqués, etc…

Pourtant, les technologies évoluant, il est de plus en plus facile « d’accéder au hard » : voir l’écosystème Arduino, la multitude de carte de développement FPGA « à bas coûts », les nombreuses interfaces d’interaction avec le hard : JTAG, SPI, I2C, …

Techniquement, les systèmes embarqués sont de plus en plus efficients : Leur taille se réduit (= discrétion), leur utilisation est simplifiée (besoin de quelques connaissances en développement), leur prix reste très abordable (les cartes Arduino = moins de 30 euros pour certains modèles). Malgré cela, il existe quelques inconvénients comme une faible mémoire de travail qui nécessite un développement (plus) optimisé et une vitesse d’exécution (parfois) plus lente.

Est-il possible d’utiliser ces systèmes « hardware » (ou plus généralement, n’importe quels systèmes embarqués) dans le cadre d’activités liées à la sécurité des SI, notamment les audits?

Nous allons voir comment. Débutons cette série d’article par quelques exemples:

Simuler un clavier USB pour « bruteforcer » des écrans de login (type Windows par exemple)

Afin d’illustrer cet exemple, nous avons effectué un test avec une carte Teensy USB Development Board .

The Teensy is a complete USB-based microcontroller development system, in a very small footprint, capable of implementing many types of projects. All programming is done via the USB port. No special programmer is needed, only a standard « Mini-B » USB cable and a PC or Macintosh with a USB port “ (source : http://www.pjrc.com/teensy/)

Avec quelques lignes de code qui simulent un clavier USB, il est possible de créer un outil électronique simple (et donc parfaitement limité !) dont la seule fonction est de tenter de « brute forcer » un écran de login d’ordinateur. Notre proof of concept matériel permet d’ouvrir une session sur un poste de travail sans aucune interaction et sans (a priori) déclencher une quelconque alerte de sécurité.

Ce type d’outil possède bien sur des limites mais peut aussi s’adapter à certaines situations : L’implémentation d’une politique de sécurité peut bloquer ou refuser le démarrage sur clé USB ( de type « support de fichier ») ou CD-ROM. Cependant, il est très rare que le branchement d’un clavier USB soit interdit (fusse-t-il malveillant !)

Autre exemple :

Le Bus Pirate : couteau suisse de l’interfaçage avec le « hardware »

(Ou comment interagir avec les éléments hardware depuis un ordinateur sans (trop) avoir à souder ni à développer du code…)

Les caractéristiques publiées sur le site http://www.seeedstudio.com/depot/bus-pirate-v3-assembled-p-609.html?cPath=61_68 permettent de se faire une bonne opinion de ces capacités : « The BusPirate v3 is a universal bus interface that talks to electronics from a PC serial terminal. Get to know a chip without writing code. Eliminates a ton of early prototyping effort with new or unknown chips”… Il permet aussi de sniffer des protocoles de communications utilisés par les composants hardware (SPI, I2C,…)

Cet outil peut donc servir à analyser des signaux, faire du “Reverse engineering” (Dump mémoire d’un composant de la carte électronique auditée -> Nécessite les autorisations adéquates 😉 bien sûre), à se connecter à une carte (dont la documentation est) inconnue…

Quelques exemples d’utilisation du bus Pirate :

 Comment limiter les impacts de sécurité liés à l’utilisation malveillante de ces outils ?

Les fournisseurs de systèmes et/ou de produits électroniques ou de systèmes embarqués peuvent limiter les impacts de sécurité en intégrant dans leurs analyses de risques les points suivants :

  • Il devient de plus en plus facile d’accéder puis de récupérer des informations sensibles sur des éléments hardware (sans être un spécialiste de l’électronique !)
  • Une fois l’accès obtenu, le code et les données peuvent être modifiés aisément

De ce constat , il est possible de lister quelques bonnes pratiques de sécurité (liste non exhaustive…)

  • Former et sensibiliser les concepteurs à la sécurisation de leurs systèmes embarqués (formation@opale-security.com)
  • Ne pas sous-estimer les possibilités d’attaque physique des systèmes embarqués
  • (Tenter) de sécuriser les échanges entre chaque périphérique
  • L’utilisation de système autonome (tout sur la même puce ! CPU, Mémoire, Conversion Analogique/Numérique,…) peut limiter ces accès frauduleux aux composants et échanges internes (voir les System On Chip)
  • Eliminer les possibilités d’accès via les interfaces classiques type JTAG
  • Dans le cas de système sensibles, prévoir des systèmes anti effraction (anti tampering) qui peuvent, par exemple, supprimer les données critiques en cas d’ouverture malicieuses (suppression des clés de chiffrement…)
  • Planifier des contrôles de sécurité récurrents (Pentest Hardware, audit de sécurité hardware…)

A suivre…

Publicités