A la Une Sécurité

Les attaques de zombies IoT : comment il est possible de s’en prémunir

L’an dernier, nous avions évoqué la menace des « thingbots » — ces botnets constitués d’équipements IoT zombies. Comme l’actualité l’a récemment montré, cette menace est devenue réalité. Utilisés pour lancer des attaques DDoS sur le site d’infosécurité KrebsOnSecurity, les thingbots ont également pris pour cible Dyn, un fournisseur de DNS lors d’une attaque qui a notoirement coupé l’accès à certains des sites Internet les plus fréquentés.

Comment un objet « innocent » peut-il se transformer en thingbot ?

Prenons l’exemple du botnet Mirai, à l’origine des attaques mentionnées plus haut, pour illustrer le fonctionnement des thingbots. Actuellement composé d’environ 500 000 équipements IoT compromis à travers le monde (caméras de surveillance, routeurs et enregistreurs vidéo numériques [EVN]…), Mirai analyse et cible en permanence les appareils configurés avec les identifiants d’administration par défaut les plus courants. Le recours aux attaques par dictionnaire permettrait à Mirai de pirater les équipements visés ou d’en prendre le contrôle en 10 minutes environ.

À l’origine du problème : des pratiques d’authentification insuffisantes. Les mots de passe par défaut sont codés en dur dans les équipements lors de leur fabrication. Au vu de la taille de Mirai, ces mots de passe ne sont que très rarement remis à jour et représentent ainsi une proie idéale pour Mirai ou tout autre type de botnet.

Empêcher la formation de botnets : bonnes pratiques à l’attention des constructeurs

Étudions quelques exemples de bonnes pratiques que les fabricants de matériel pourraient adopter pour éviter que leurs équipements ne soient d’emblée transformés en thingbots.

Brider les capacités de ses équipements. L’accès à distance est-il vraiment indispensable ?

Y a-t-il vraiment besoin de pouvoir accéder à distance à ces appareils pour les gérer ? Peut-on efficacement supprimer l’authentification intégrée dans l’environnement de l’appareil ? La suppression de cette fonctionnalité permettrait de colmater la faille que Mirai essaie actuellement d’exploiter pour accéder aux équipements et en prendre le contrôle.

Si l’on a besoin de l’accès à distance, il est nécessaire d’opter pour une authentification forte

Mirai exploite les faiblesses patentes des mots de passe configurés sur les équipements. Rarement uniques, et rarement changés, les mots de passe par défaut sont souvent réutilisés sur plusieurs appareils. L’OWASP (Open Web Application Security Project) propose quelques conseils simples à l’attention des fabricants, notamment sur la politique en matière de mots de passe à mettre en place sur leurs appareils pour éviter ce type d’attaque. Nous invitons cependant les constructeurs à élargir leur réflexion à d’autres méthodes d’authentification que les mots de passe.

Pour la mise en place d’une authentification forte sur les équipements, les infrastructures PKI (Private Key Infrastructure) présentent de nombreux avantages. Tout d’abord, la technologie est très difficile, voire impossible, à pirater. L’intégration d’une PKI au processus d’authentification empêche les attaques par dictionnaire, comme dans le cas de Mirai.

La PKI permet également d’utiliser des informations d’authentification uniques pour les entités d’authentification (équipements et services confondus). Au stade de la fabrication, mieux vaut inclure des informations d’authentification uniques pour chaque appareil, plutôt que d’utiliser des informations d’authentification communes ou partagées par plusieurs appareils. L’idéal serait d’utiliser des éléments de sécurité matérielle pour protéger les clés privées sur les équipements et empêcher le vol ou la migration des identifiants à l’extérieur des appareils.

Penser à l’authentification forte pour les comptes et services administrateurs.

Si l’on pense activer l’identification directement sur l’appareil à des fins d’administration (pour un utilisateur ou un service), l’on doit également s’équiper de méthodes d’authentification renforcées. L’une des approches consiste à utiliser un modèle de confiance basé sur une infrastructure PKI. Les appareils sont fabriqués ou configurés avec l’ancre de confiance d’une autorité de certification (et potentiellement d’autres règles d’authentification comme les domaines de serveurs de confiance) qui permet aux appareils d’appliquer une méthode d’authentification plus forte qu’un simple mot de passe et identifiant pour faire fonctionner les services.

Autoriser uniquement les mises à jour de logiciels et de firmwares autorisés

Pour une couche de sécurité supplémentaire, l’idéal serait de configurer les appareils avec une logique de vérification permettant de vérifier l’ensemble des mises à jour logicielles proposées par un service. On empêcherait ainsi l’installation de logiciels douteux sur les équipements, comme avec le malware utilisé dans l’attaque de Dyn. Cette logique de validation s’appuierait sur une ancre de confiance — ou racine — que l’on pourrait configurer sur l’appareil lors de la fabrication afin de déterminer quels logiciels sont fiables avant de les exécuter ou de les installer.

L’appareil devra pouvoir utiliser ses racines de confiance pour identifier et valider les logiciels. Cet autre domaine d’application des PKI permet de renforcer la sécurité grâce à la signature numérique du code afin de le « lier » à l’identité du développeur. La signature numérique et l’identité indiquée sur le certificat numérique seraient alors vérifiées avant d’exécuter le logiciel. On peut par exemple indiquer que seuls les logiciels édités par la société XYZ et signés à l’aide d’un type de certificat donné peuvent être installés.

La PKI n’est qu’une pièce du puzzle…

La sécurité de l’IoT est un sujet à prendre au sérieux pour les constructeurs. De nombreuses approches viables permettent d’atténuer la portée de telles attaques et ce que je viens de présenter n’est qu’une partie de l’arsenal de sécurité complet. La dimension de la solution sélectionnée dépendra des risques et des problématiques de réduction de ces risques auxquels l’entreprise est confrontée.

On commence cependant à voir émerger un socle minimum de points que les fournisseurs de l’IoT sont tenus de traiter. Une partie de ces points figurent dans les orientations proposées par l’OWASP, l’OTA et l’Underwriters Lab.

JDN

ARTICLES SIMILAIRES

Laisser un Commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Ce site utilise des cookies pour améliorer votre expérience. Nous supposerons que cela vous convient. Accepter En savoir plus

NEWSLETTER

Inscrivez-vous et recevez régulièrement des arletes par mail

Vos informations ne seront pas partagées