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.

Si vous voyez ceci dans une vitrine d’un magasin, passez votre chemin…

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 :

  1. Exportez la configuration de la caméra et ouvrez le fichier dans un éditeur de texte
  2. Cherchez la ligne contenant acounts1_name=guest (ligne 514 chez moi) et remplacez la par acounts1_name=.
  3. Faites la même chose à la ligne suivante (acounts1_passwd=).
  4. 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.

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.

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.

La vie privée, Android, les caméras wifi et moi

Je fais un rapide article pour annoncer une nouvelle qui me fait très plaisir : je viens de finir mon travail de fin d’études. À quelques formalités près, je suis désormais (presque) diplômé d’un master en informatique, elle est pas belle la vie (potentiel employeur, tu peux me contacter par mail). Bon, on est pas là pour parler de moi mais du papier que j’ai pondu et dont je suis suffisamment fier que pour vouloir en parler.

Privacy concerns with everyday technologies: case study of Android phones and wireless cameras

Pour résumer, cela concerne toute la problématique de la vie privée, largement sous-estimée lorsque l’on utilise des technologies devenues très courantes. On considère ces technologies pour une fonction et non comme un système informatique (sur lesquelles on ne va pas faire de mise à jour par exemple), ici en particulier, Android et les caméras wifi personnelles.

Pour mon étude de cas Android, je me suis concentré sur les capacités de localisation avec les abus de permissions. C’est-à-dire voir comment une application peut, sans utiliser aucun bug ou faille de sécurité, avoir des comportements assez dérangeants. Pour l’exemple, j’ai créé une application DroidWatcher qui enregistre la position de l’utilisateur toutes les 15 minutes et les envoie sur un serveur, le tout avec un système de commande par SMS.

Pour les caméras, la méthode était un peu différente mais le résultat similaire. Ces caméras que l’on utilise pour protéger notre vie privée, est-ce qu’elles sont bien sécurisées et empêchent les abus ? Pour ça, j’ai utilisé une caméra D-Link dont j’avais récupéré le code source (tant bien que mal) et puis fait une petite analyse complète de la sécurité. Spoiler alerte : elle est très mauvaise par défaut (c’est-à-dire pour 99% des caméras). Et si un voleur utilisait votre caméra pour faciliter son vol ? Un comble…

Bien entendu, le tout est publié sous licence libre (CC BY-SA pour le texte, GPL pour le code) et est disponible sur gitorious.

Des articles plus approfondis (au moins sur la caméra) devraient voir bientôt le jour mais vous pouvez déjà lire tout ça via le pdf. J’espère que ça va intéresser certains et n’hésitez pas à me faire part de vos retours.

DLink viole la GPL ?

Dans le cadre de mon travail de fin d’études, j’étudie la sécurité des caméras de surveillance. Pour le coté pratique, j’ai choisi de travailler sur la DCS-2130 de DLink, une caméra wifi d’entrée de gamme remplie de fonctionnalités sympa.

Lors de mon étude, je me suis rendu compte que DLink offrait le code source de ses firmware sous GPL. Offrait ça sous-entend : a été obligé car puise allègrement dans les programmes sous GPL et y est donc plutôt contraint…

Ils ont donc mit en place un joli site avec le code disponible pour la version 1 de leur firmware. Bon on va faire l’impasse sur le fait que l’on est à la version 1.1 maintenant parce qu’il y a pire.

Que faire quand vous êtes un constructeur obligé de distribuer son code alors qu’on a pas envie ? Faire un site qui marche pas. Et oui, DLink a gentiment mit en place un site tout foireux qui permet de télécharger à une vitesse bridée variant de 1Kb/s à 60 Kb/s (sur une archive de 1.6Gb, faites le calcul) et qui arrive toujours à un timeout à un moment ou un autre (une fois, j’ai réussi à aller jusque 200Mb, j’y croyais presque). Évidement évitez les liens directs ou ftp, ça permettrait de reprendre le téléchargement.

Attendez ! Il y a une adresse email pour contacter l’admin. « Delivery Status Notification (Failure) » Ah ben mince, c’est con ça… Le formulaire de contact ? J’attends toujours la réponse à mon message…

Bien sûr cela pourrait tout à fait être une coïncidence expliquée par le fait que DLink ne sait pas administrer un site et que les migrations de licornes sont perturbées par les éruptions solaires. D’ailleurs par le passé, DLink s’est toujours montré comme un exemple en matière de respect de la GPL.

Allez une petite citation des avocats de DLink en 2006 pour la fin :

Regardless of the repeatedly-quoted judgement of the district court of Munich I, we do not consider the GPL as legally binding.

Malgré le jugement cité du tribunal de Munich, nous ne considérons pas la GPL comme légalement contraignante.

—-

Mise à jour 17/4: si on cherche à avoir plus d’info sur où est réellement hébergé le fichier. On voit que l’on fait une requête javascript javascript:dnn(‘AECBLCAAJC’) et soit vers http://tsd.dlink.com.tw/asp/get_file.asp?sno=AECBLCAAJC. Sauf que le code en question change à chaque session.

En analysant la requête on voit qu’on reçoit un code HTML 302 Object moved qui nous redirige vers ce site. On se rapproche du lien direct !
Ce brave serveur est donc un tomcat 5.0.19. C’est facile à savoir, c’est mit sur leur page d’accueil. Au moins, il ont pas mit admin/admin comme mot de passe. Il parait que cette version est vulnérable aux directory traversals si des curieux veulent chercher…

En attendant, j’ai utilisé ce dernier lien pour faire un wget sur mon serveur. Du 60k mais ça semble tenir, je viens de passer la moitié, on y croit ! Évidement il suffisait que je dise ça pour avoir Read error at byte 818639781 (Connection timed out)

Mise à jour 19/4: grâce à bochecha, j’ai pu récupérer l’image de la DCS2130. Elle est en cours d’upload et disponible sur ftp://ftp.mart-e.be/DLink/, faites vous plaisir.
Si vous avez d’autres fichiers que vous avez pu télécharger, contactez moi, je vous donnerai un accès au ftp pour la partager.