Caméras IP, toi aussi D-Link

Intro

Ces derniers temps, les caméras de surveillances IP n'ont pas bonne presse. On a d'abord eu en janvier Trendnet qui, possédant une faille de sécurité, laissait n'importe qui voir la vidéo. Il y a deux semaines, c'était les chipsets Hi35xx des caméras H.264 sur lesquels on découvrait une faille de sécurité majeure qui permettait de récupérer tous les mots de passes enregistrés (mails & co). Aujourd'hui parlons un peu de D-Link.

Dans le cadre de mon travail de fin d'études en informatique, j'ai étudié le cas d'une caméra D-Link, la DCS-2130, le genre de caméra bon marché que l'on peut utiliser pour surveiller sa maison pendant son absence ou s'assurer que bébé dort bien.

Cette caméra utilisant des logiciels sous licence GPL, D-Link a été contraint de publier également le code source de son firmware sous GPL. Je vous avais déjà expliqué sur ce blog mes déboires pour le récupérer ; toujours est-il qu'il est disponible ici.

Lors de mon analyse, j'ai découvert plusieurs faiblesses en terme de sécurité. Je vais détailler les deux principales ici, l'analyse complète peut être lue au chapitre 6 de mon rapport^{[pdf, 2,2 MB, en]}.

Compte invité

Depuis l'interface d'administration de la caméra (accessible à l'adresse IP de la caméra), il est possible d'exporter la configuration de la caméra. Ce fichier contient en clair tous les paramètres et mots de passes enregistrés (très moyen, imaginez qu'il y aie une faille similaire à celle des caméras H.264...). C'est en consultant ce fichier que je me suis rendu compte de la présence d'un compte avec le login et mot de passe guest.

acounts0_name=admin
acounts0_passwd=mypass
acounts1_name=guest
acounts1_passwd=guest
acounts1_authority=2

Que permet le droit d'accès 2 ? De consulter le flux vidéo !
A la configuration de la caméra, lors du premier lancement (où l'on utilise un superbe utilitaire en ActiveX), il n'est jamais mentionné la présence de ce compte. On a même un faux sentiment de sécurité vu l'obligation de spécifier un mot de passe au compte administrateur. Or tous les possesseurs d'une DCS-2130 (et surement d'autres modèles, il faudrait tester) possède un tel compte.

Pire encore : il n'est apparemment pas possible de supprimer ce compte. L'interface d'administration possède un formulaire pour la suppression de comptes ; sauf en cas du compte invité. En effet, dans le code source, j'ai trouvé ce bout de code responsable de ce comportement dans la fonction uri_user_del :

#ifdef CONFIG_BRAND_DLINK
else if(i == 1){
DBG("You can not delete the guest accunt!n");
break;
}
#endif

On a donc un code (faute d'orthographe d'origine) qui interdit la suppression d'un compte caché permettant l'accès à la vidéo. Je crierais bien à la backdoor si c'était pas aussi gros.

Est-ce exploitable ? Oui ! Des centaines de caméras D-Link sont accessibles via une adresse IP publique. (lorsque son possesseur à configuré un port forwarding). On peut le découvrir facilement via un bête scan sur un range d'IP (avec un script comme celui-ci) ou en utilisant un outil très bien foutu, ShodanHQ, moteur de recherche de routeurs, serveurs et autres appareils tel que des caméras IP. Une simple recherche à DCS-2130 liste des adresses IP auquel il y a de grande chance d'avoir un compte guest disponible. Assez dérangeant.

Capture d'une caméra — Hmm voila qui est fâcheux...

Ne jetez pas encore votre caméra (quoique), il est heureusement possible de régler cela via une petite manipulation que j'ai découverte :

Exportez la configuration de la caméra et ouvrez le fichier dans un éditeur de texte
Cherchez la ligne contenant acounts1_name=guest (ligne 514 chez moi) et remplacez la par acounts1_name=.
Faites la même chose à la ligne suivante (acounts1_passwd=).
Sauvez le fichier et importez le sur l'interface d'administration

La nouvelle configuration de votre caméra ne possèdera donc plus de compte invité et sera (partiellement) à l’abri des yeux indiscrets.

Fichier de log

Lors de l'analyse du firmware, j'ai découvert que Boa, serveur web minimaliste, hard-codais toutes les URI avec les droits d'accès et la fonction à exécuter dans un fichier request.c (le même fichier qui contenait la fonction de suppression de compte). Par exemple :

{"/ipcam/stream.cgi", uri_av_stream, AUTHORITY_VIEWER, URI_FLAG_VIRTUAL_PAGE, NULL},
{"/cgi-bin/loadconf.cgi", NULL, AUTHORITY_OPERATOR, 0, NULL},

A la première ligne, l'URI /ipcam/stream.cgi exécute la fonction uri_av_stream pour tous les utilisateurs ayant les droits AUTHORITY_VIEWER (comme le compte invité). A la deuxième, l'URI /cgi-bin/loadconf.cgi exécute directement le fichier binaire du même nom pour tous les utilisateurs avec les droits AUTHORITY_OPERATOR (comme le compte admin).

Maintenant, question subsidiaire : que se passe il lorsque qu'il existe un fichier, disons /cgi-bin/exportlog.cgi qui se trouve dans les fichiers sur le serveur mais pas dans la liste hard-codée avec les permissions ? N'importe qui peut l'exécuter, admin, invité ou même un simple visiteur. Comme son nom l'indique, ce fichier exporte le log de la caméra qui contient ce genre d'info :

2012-05-24 21:01:29 NETWORK LOST
2012-05-24 21:01:29 SD CARD SIZE 7620040 KB
2012-05-24 21:01:34 NETWORK RECONNECT
2012-05-24 21:03:15 admin LOGIN OK FROM 193.44.55.11
2012-05-25 15:40:38 IP CAMERA Received MOTION Trigger
2012-05-25 15:40:41 MOTION STOPPED

Il n'y a, heureusement, pas de mots de passe mais des informations potentiellement sensibles comme des logins, des adresses IP et surtout, des événements comme l'outil de détection de mouvements qui s'active.

Conclusion

Quelles sont les conséquences concrètement de ces deux failles ? Imaginons un voleur un peu geek voulant planifier son vol, s'il se rend compte qu'une caméra IP est accessible (soit depuis l'intérieur du réseau soit depuis une adresse IP publique), il pourra voir accès à beaucoup d'information qui lui faciliteront la tâche. Il pourrait connaître les heures de fréquentation des habitants, repérer les lieux et connaître les endroit à éviter. Un comble pour un outil supposé vous protéger.

burglar-inside — Si l'on s'introduit sur le réseau wifi

Étant donné la nature du second problème, en l'attente d'une mise à jour (si elle vient), il n'est pas possible d'empêcher ce comportement sans corriger le code manuellement, compiler le firmware (marche à suivre ici) et charger votre build. C'est possible mais c'est à vos risques et périls, je n'ai personnellement pas tenté l'expérience. Cependant, voici un fichier request.c pour le serveur Boa qui, théoriquement, devrait régler à la fois le problème de la suppression du compté invité impossible (suppression du bout de code responsable) et rendre le fichier de log inaccessible pour les non-administrateurs (ajout d'une règle). Si D-Link, qui n'a toujours pas répondu à mon email du mois de juillet, voulait l'utiliser, c'est cadeau.

burglar-outside — Si l'on connaît l'adresse IP publique du réseau

Dans cette étude, je n'ai regardé qu'a un seul modèle de caméra choisi arbitrairement. Aucune étude de sécurité n'avait été faite dessus auparavant (du moins que j'ai trouvé) et elle avait de bonne critique. Cela ne veut pas dire que toutes les caméras sont mauvaises ou que D-Link est un mauvais élève (on a vu des problèmes similaires chez d'autres marques). Je pense que cela représente bien le risque de confier des choses sensibles (des images de l'intérieur de sa maison) à des appareils sur lesquels on ne sait rien et qui n'ont pas été pensé dans une optique de sécurité. On peut espérer que la multiplication des problèmes découverts sur ce genre d'appareils va sensibiliser les constructeurs et possesseurs à faire plus attention à ces problèmes.