L’IdO a été piraté ? En tant qu’entreprise de cybersécurité, nous organisons régulièrement des concours internes à des fins ludiques et éducatives. Le dernier en date portait sur le piratage d’une application IoT. Cet article – rédigé par l’un de nos consultants en cybersécurité – peut vous intéresser, en particulier si vous êtes curieux de la cybersécurité ou si vous êtes en train de développer une application sécurisée.
Introduction
Ici, à Approach, nous avons la chance d’avoir des personnes compétentes qui aiment partager leurs connaissances, notamment lors de ce que nous appelons notre « Knowledge Lunch ». Les sujets abordés peuvent aller de la cybersécurité au codage sécurisé en passant par les tests de pénétration du Web.
Le dernier sujet en date a été présenté par notre consultant principal en cybersécurité, David Bloom. David nous a présenté quelques techniques de piratage web qui sont faciles à mettre en œuvre, mais dont le résultat final a un impact dévastateur.
L’objectif de cette session était de démontrer à quel point il est facile de compromettre un serveur ou d’infecter le navigateur d’un client si l’application web n’applique pas une validation d’entrée correcte ou si le serveur web n’est pas correctement renforcé.
Le défi : « Pirater un boîtier de streaming musical bon marché, ancien et sans marque » – contexte et règles
Après cette présentation instructive, David avait un autre cadeau pour nous : un défi. David a apporté un vieux boîtier de streaming musical bon marché et sans marque qu’il a emprunté à son frère et nous a confié une mission : obtenir un accès administrateur et trouver le drapeau qu’il a placé sur le boîtier, quelque part dans les fichiers du boîtier de streaming.
Il n’y avait que deux règles pour ce défi :
RÈGLE 1 – Pas de dégradation/destruction/altération qui pourrait empêcher d’autres personnes de participer (et éventuellement mettre son frère en colère).
RÈGLE 2 – Pas de connexion de la boîte sur notre propre réseau ou sur Internet pour éviter d’insérer un objet vulnérable dans l’environnement de notre bureau.
Les fonctionnalités du boîtier sont assez basiques. Il crée un réseau Wi-Fi sur lequel vous pouvez vous connecter pour diffuser de la musique et partager des fichiers. Il présente un portail web limité avec les fonctionnalités suivantes :
– Un gestionnaire de fichiers pour gérer les fichiers présents sur une clé USB ou un disque dur USB.
-Configuration du point d’accès Wi-Fi.
-Un moyen de se connecter à Internet et à votre réseau par l’intermédiaire d’une autre antenne Wi-Fi.
-Configurez le service audio.
-Configuration d’un dossier partagé.
– Mettez à jour le micrologiciel.
Le test de pénétration
En tant que consultant en cybersécurité, j’étais curieux de voir à quel point l’application était sûre et s’il était difficile de la tester en boîte noire. À première vue, la sécurité n’est pas l’objectif principal de ce produit. Les services non cryptés (HTTP, telnet…), les cookies très permissifs et, plus important encore, la faible validation des champs étaient les faiblesses facilement perceptibles. De plus, certains champs ne supprimaient les crochets d’angle « <> » que côté client via JavaScript (protection faible qui peut être contournée avec un simple proxy), certains champs ne validaient rien, d’autres se contentaient de l’encodage des caractères.
Cette quantité de vulnérabilités potentiellement exploitables sur une si petite application m’a rendu difficile de deviner laquelle serait la meilleure à exploiter. Je me suis rapidement lassé d’essayer chaque champ et chaque paramètre d’URL. Plus important encore, je voulais trouver le drapeau en premier.
Clé de piratage
Pourtant, la clé du piratage de ce dispositif se trouvait dans l’extension des pages : shtml. SHTML est une extension spéciale qui permet au serveur web d’exécuter, s’il le permet, des instructions Server Side Includes (SSI) si elles sont présentées dans une page statique. SSI est un langage interprété simple qui permet d’exécuter certaines commandes côté serveur.
Il est donc clair que SSI était le langage d’exploitation à rechercher. Mais comment l’injecter dans la boîte ?
J’aurais pu essayer l’injection SSI, ou créer un fichier shtml sur le serveur par injection de commande, ou même par injection de code. Mais cela pourrait prendre beaucoup de temps pour trouver comment exploiter les morceaux de code qui permettraient l’injection, alors j’ai pris un raccourci à la place.
J’ai créé ma propre page shtml contenant un code SSI très simple : 
J’ai copié le fichier sur une clé USB, je me suis approché discrètement de la boîte pour l’insérer dans le port USB de la boîte, puis je suis revenu à mon bureau, en faisant semblant d’aller prendre un café.
Je suis ensuite allé sur la page de gestion des fichiers et j’ai ouvert le document shtml à partir de là :
Sans surprise, la page shtml a été exécutée côté serveur. La raison en est simple : pour pouvoir afficher le contenu de la clé USB, celle-ci a été montée dans le répertoire de travail de l’application web.
Résultat
La page résultante donne :
La première partie du défi a été gagnée. Je suis devenu root ! Remote File Inclusion en branchant simplement une clé USB. C’est très bien !
Je pouvais donc faire tout ce que je voulais sur la boîte. Tout ce que j’avais à faire, c’était de créer d’autres fichiers pour parcourir et ouvrir le fichier drapeau.
Après avoir fait part de mes découvertes, j’ai été informé qu’il ne s’agissait que de l’une des vulnérabilités, et qu’il y en avait d’autres, impliquant en effet l’injection de commandes/codes/fichiers.
En conclusion, quel était le degré de sécurité ?
Cette boîte était un excellent exemple de système non sécurisé, car elle illustrait différents types de failles :
– Faille logicielle : champ(s) permettant l’injection.
– Défaut de configuration : le serveur web fonctionnant en tant que root.
– Défaut de protection physique : la boîte était physiquement accessible.
– Défaut de conception : il exécute n’importe quel fichier provenant d’un support amovible USB, alors qu’il ne devrait autoriser que les fichiers connus.
Cette boîte est un cas extrême d’appareil IoT qui n’a pas été conçu avec la sécurité à l’esprit. Mais qu’aurait-on pu faire pour sécuriser l’application ?
Quelques conseils pour les développeurs d’applications IoT similaires
En dehors de la sécurité physique de l’appareil qui m’a facilité la tâche et sur laquelle les vendeurs n’ont aucune influence, les développeurs de cette boîte auraient pu avoir :
– N’exécutez pas le serveur web en tant que root.
– Limitez le répertoire de travail du serveur web.
– Limitez l’exécution des fichiers shtml à un seul répertoire connu par le biais de la configuration du serveur web ou des fichiers .htaccess.
– Ne pas donner la permission d’écrire dans le répertoire de travail et les sous-répertoires (pour éviter la génération de nouvelles pages shtml par un attaquant).
– Configurez le serveur web pour qu’il n’autorise pas la commande SSI « exec ». Par exemple, sur Apache, l’option IncludesNOEXEC.
– Meilleure validation des champs.
Vous souhaitez réaliser des tests de pénétration pour vos applications IoT ? Consultez notre page pentest
Vous souhaitez développer des applications sécurisées ? Consultez notre page sur ledéveloppement sécurisé
Conseils aux acheteurs finaux de dispositifs IdO
Si vous envisagez d’acheter un nouvel appareil qui pourrait être branché sur votre réseau et/ou sur l’internet, vous devez tenir compte du fait qu’il est moins puissant et moins intelligent qu’un ordinateur, et donc plus vulnérable. En ce qui concerne votre sécurité et votre vie privée, vous devez prendre en compte le risque d’avoir un tel appareil à un saut de puce de votre ordinateur et/ou de votre smartphone,
Pour limiter les risques, vous devriez viser des marques renommées ayant une bonne réputation en matière de sécurité et éviter les marques moins connues ou inconnues. Ces dernières, qui n’ont pas de réputation à perdre, peuvent être tentées de rogner sur les coûts de développement.
Une fois acheté, la première chose à faire avec un nouvel IoT est de remplacer le mot de passe administrateur par défaut par un mot de passe fort !
En outre :
– Veillez à ce qu’il ne soit pas accessible physiquement par un attaquant. Par exemple, ne le laissez pas sans surveillance dans le couloir de votre immeuble.
– Éteignez-le lorsque vous ne l’utilisez pas.
– Utilisez un mot de passe pour le Wi-Fi s’il fait office de routeur.
– Maintenez l’appareil à jour.
Vous voulez rester au courant des dernières menaces ? Abonnez-vous à notre lettre d’information SOC.
