De plus en plus de caméras connectées et non sécurisées ! La sécurité des objets connectés négligée ! Qui aurait pensé ?
Malheureusement, la cybersécurité semble être la dernière des priorités pour de nombreux éditeurs lorsqu’ils commencent à programmer le plus récent et le plus génial de leurs objets connectés (IoT).
Dans notre cas, les bugs en question concernent une certaine catégorie de webcams, et pas une de ces anciennes webcams, mais des caméras de sécurité !
En d’autres termes, le produit que vous avez acheté pour vous protéger des voyous dans le monde réel, et qui pillent votre entrepôt la nuit, pourrait très bien se transformer en véritable porte d’entrée pour des cybercriminels souhaitant envahir votre réseau à tout moment.
Cette histoire, publiée par des chercheurs de la société de sécurité IoT VDOO, détaille et explique toute une série de failles de sécurité dans divers produits Foscam.
Remarque : Ces bugs ont été divulgués de manière responsable par VDOO, et rapidement corrigés par Foscam, de sorte que les mises à jour étaient prêtes avant que les informations que vous allez découvrir ci-dessous ne soient rendues publiques. En d’autres termes, l’histoire peut être racontée en toute sécurité à présent, et ce à des fins éducatives : plus nous revisitons les bases de la sécurité, plus nous sommes susceptibles, collectivement, de bien les mettre en œuvre dans le futur.
Il s’agit d’un rappel des plus fascinants sur la manière avec laquelle les cybercriminels peuvent combiner des vulnérabilités, qui semblent insignifiantes ou inexploitables seules, au sein d’une “chaîne d’attaques”, leur permettant en fin de compte de prendre le contrôle intégral d’un équipement, en l’occurrence ici des caméras de sécurité.
L’article publié par VDOO contient tous les détails techniques, mais voici notre propre version, offrant une vue globale sur ce cas.
Au fait, nous avons ajouté une quatrième vulnérabilité, à laquelle nous avons donné le numéro “zéro“, une sorte de choix lors de la phase de conception qui a empiré les choses d’une manière général.
0. Aucune séparation des privilèges
Tous les services système, sur les équipements analysés par VDOO, fonctionnaient en tant que root, y compris le serveur web utilisé pour gérer l’interface administration de ces caméras de sécurité.
Ne faites jamais une telle chose !
Gardez vos services système séparés les uns des autres le plus possible, avec un identifiant utilisateur différent pour chacun, afin de les empêcher de lire les fichiers des autres ou d’interférer par erreur entre eux.
Même si les services système doivent démarrer en tant que root, par exemple pour ouvrir des connexions réseau privilégiées, réduisez leurs privilèges dès que possible, par exemple en utilisant setuid() et setgid().
Si vous pouvez exécuter chaque service système intégralement au sein de sa propre sous-arborescence dans le répertoire, par exemple en utilisant chroot(), faites-le !
L’utilisation de chroot() transforme un sous-répertoire en répertoire racine virtuel, de sorte que vous ne pouvez plus vous déplacer vers le haut.
Par conséquent, tous les fichiers situés au-dessus de votre propre répertoire et les fichiers de tous les sous-répertoires voisins, notamment les répertoires système, sont effectivement invisibles et inaccessibles, car vous êtes enfermé dans votre propre sous-répertoire “cul-de-sac“.
L’exécution en mode root rend la conception, le développement et le test de votre logiciel beaucoup plus facile, et concernant un équipement spécifique tel qu’un appareil photo, un scanner, une imprimante ou un routeur, il est facile de s’en tirer à bon compte. Par contre, c’est beaucoup moins évident pour vos utilisateurs, car ils n’ont pas de moyens faciles de se connecter et de vérifier quels processus sont en cours d’exécution, et sous quel identifiant utilisateur.
Cependant, l’approche “root-everyhere” est une pratique de programmation inacceptable en 2018, et elle finira presque certainement par vous coûter cher à vous et à vos clients à long terme.
1. Vulnérabilité de type traversée de chemin
Le serveur web utilisé au niveau de ces caméras de sécurité vulnérables disposait d’une fonction qui vous permettait de supprimer des images temporaires, même si vous n’étiez pas connecté.
Étant donné que les fichiers que vous pouviez supprimer étaient supposés être temporaires, le manque d’authentification ne semblait pas avoir d’importance ici.
Le problème est que la fonction de suppression vérifiait que le nom de fichier que vous aviez fourni avait bien un lien avec un répertoire temporaire connu, par exemple /snapPic/, mais ne se souciait pas vraiment de la suite des opérations.
Le serveur web supposait que tout nom de fichier spécifié à la fin du répertoire temporaire était, nécessairement, dans ou sous ce répertoire.
Mais un nom de fichier tel que /snapPic/../etc/passwd n’est pas sous /snapPic, mais au même niveau que celui-ci, car .. (deux points) est un raccourci pour “remonter d’un répertoire et recommencer à partir de là”.
En d’autres termes, /snapPic/.. descend de / dans le répertoire snapPic, puis revient directement à /, annulant ainsi toute référence à snapPic.
En fait, si vous ne savez pas exactement où vous vous situez dans l’arborescence, vous pouvez écrire quelque chose comme snapPic/../.. [etc] ../../etc/passwd avec autant de répétitions que vous le souhaitez des deux points suivis du nom du répertoire.
Le système d’exploitation va remonter autant que possible jusqu’à ce qu’il se heurte au répertoire racine, puis ignorera les spécificateurs “dot-dot-répertoire” inutiles. Vous verrez souvent la séquence suivante ../../../../.. [etc] dans certaines tentatives menées par des exploits, quand les cybercriminels ne savent pas vraiment où ils sont dans l’arborescence au moment de démarrer.
Par conséquent, le nom de fichier /snapPic/../etc/passwd est exactement la même syntaxe que /etc/passwd, à savoir le fichier système dans lequel les noms d’utilisateur sont stockés.
Le fichier
passwdtire son nom du fait qu’il était utilisé il y a des décennies pour stocker des mots de passe hachés, ainsi que des noms d’utilisateur, mais pour des raisons de sécurité, les systèmes d’exploitation Unix et de type Unix, tels que Linux, ne conservent plus les données de mot de passe.
Avec ce bug, et un ou plusieurs fichiers à supprimer soigneusement sélectionnés, un cybercriminel peut en principe effectuer toutes sortes de changements de configuration en supprimant les fichiers de données système critiques.
Par exemple, si vous pouvez supprimer des fichiers de configuration utilisés pour verrouiller certains composants logiciels, vous pouvez restaurer le système avec des valeurs par défaut inconnues, et ce même si vous ne pouvez pas modifier ces fichiers de configuration ligne par ligne.
2. Vulnérabilité de débordement de tampon
Les chercheurs du VDOO ont trouvé une fonction de serveur web qu’ils appellent simplement getSWFlag (peu importe le rôle de cette fonction, et en fait, nous ne pouvons pas vous le dire), et qui pourrait être appelée via un paramètre trop grand pour que le tampon de données utilisé puisse le stocker en mémoire.
Ce débordement de tampon a causé le crash du processus du serveur presque immédiatement en écrasant une adresse de retour dans la pile du programme.
Les chercheurs n’ont pas eu besoin de comprendre comment exploiter ce bug pour exécuter du code fourni à distance. En effet, ils voulaient simplement stopper le serveur web à la demande.
Pour que ce type de caméras de sécurité continue de fonctionner même si le logiciel échoue, le système d’exploitation redémarre automatiquement le service interrompu. Les chercheurs ont donc pu utiliser le bug 1 pour manipuler la configuration du serveur web, puis le bug 2 pour forcer le serveur à recharger la nouvelle configuration non sécurisée.
3. Vulnérabilité d’assainissement d’entrées
Les chercheurs ont découvert une troisième fonction du serveur web qui pouvait être contournée, en prenant simplement le texte qu’ils fournissaient à distance et en l’exécutant comme une commande système, une faille RCE (exécution de code à distance) classique.
Autrement dit, une fonction supposée prendre une entrée sous la forme d’un identifiant de serveur comme exemple.com, pouvait à la place recevoir une chaîne sous la forme exemple.com;command, laquelle serait ensuite transformée en deux commandes distinctes par le serveur web piégé.
Ceci est dû au fait que le serveur web a ajouté l’entrée externe directement à une commande existante, donc au lieu de dire au système d’exécuter ce type de commande …
ntpclient -s example.com
… le système a pu être trompé en exécutant ce qui suit, via la commande shell système pour traiter le texte de la commande :
ntpclient -s example.com;telnetd -p 9999 -l /bin sh;
Dans une commande shell, cependant, le caractère point-virgule est un séparateur de commandes, donc la commande ci-dessus est équivalente aux deux lignes suivantes :
ntpclient -s example.com telnetd -p 9999 -l /bin/sh
La deuxième de ces commandes ouvre un serveur telnet connecté au port 9999. Si vous vous connectez, alors au lieu de demander un nom d’utilisateur et un mot de passe, il ouvre tout de suite une commande shell à distance.
Pourquoi cette chaîne d’attaque ?
Vous vous demandez probablement pourquoi les chercheurs ont eu besoin des étapes 1 et 2, étant donné la gravité apparente du bug 3.
La raison est que, bien que le bug 3 soit une faille RCE critique en soi, le bug ne pouvait être déclenché que si vous étiez déjà connecté en tant qu’administrateur, après quoi vous étiez déjà en position de faire des ravages si vous le vouliez.
Il est important de garder les non-administrateurs à l’écart des fonctions pour changer l’heure et la date sur votre appareil. En effet, si des utilisateurs non authentifiés peuvent changer l’horloge à volonté, ils pourraient rendre tous vos logs inutilisables en les horodatant délibérément de manière incorrecte.
Cependant, grâce aux bugs 1 et 2, les chercheurs ont pu relancer le serveur web de manière non sécurisée, en contournant l’étape d’authentification et en rendant ainsi le bug 3 immédiatement exploitable sans avoir à saisir le mot de passe administrateur.
Et voilà, le tour est joué !
Voici un exemple de combinaison de trois types différents d’exploits, permettant une prise de contrôle totale des périphériques au niveau root : un contournement de sécurité (supprimer un fichier qui n’aurait pas dû l’être), un déni de service (crash du serveur web à la demande) et l’exécution de code à distance (exécution d’une commande choisie à volonté).
Quoi faire ?
- Lisez l’article de VDOO pour voir si vos caméras de sécurité sont affectées. Si c’est le cas, procurez-vous le correctif si vous ne l’avez pas déjà fait. Les vulnérabilités ont été divulguées de manière responsable auprès de Foscam, et des mises à jour étaient disponibles avant que VDOO ne rende publique son analyse.
- Exécutez les processus en tant que root (ou Admin sur Windows), que si vous le devez vraiment. Utilisez le compte root par nécessité, et non pour son côté pratique. Si vous n’êtes pas familier avec le processus de séparation des privilèges, prenez 15 minutes pour visionner cette vidéo de Theo de Raadt d’OpenBSD.
- Ne faites pas confiance aux données externes sans les vérifier attentivement. Les caractères dans des chaines de texte sont inoffensifs lorsque vous les imprimez. En effet, des points-virgules, guillemets, chevrons, astérisques et bien d’autres encore, ont un sens bien différent suivant qu’ils sont interprétés par des fonctions système ou par des lecteurs humains.
- Lorsque vous enregistrez des données en mémoire, vérifiez toujours que l’espace disponible est suffisant. Comme nous l’avons vu dans le cas ci-dessus, même un débordement de tampon qui bloque un programme sans effets négatifs immédiats, peut parfois être exploité pour être intégré au sein d’une chaîne d’attaques.
Ne mettez jamais de côté une vérification ou une erreur de sécurité au sein de votre logiciel, en partant du principe que la probabilité qu’un environnement propice “ne se présentera jamais”, et ce du fait de vérifications similaires effectuées ailleurs, plus tôt dans le code.
Comme le dit un vieux proverbe : Ne jamais vendre la peau de l’ours avant de l’avoir tué !
Billet inspiré de Serious Security: How three minor bugs make one major exploit, sur Sophos nakedsecurity.
Qu’en pensez-vous ? Laissez un commentaire.