Ingénierie inverse d'une caméra IP (partie 3): Force-la à parler ma langue
Un jour tu te réveilles, vous regardez un vieil appareil qui est resté dans un tiroir pendant de nombreuses années – dans mon cas, une caméra IP avec une puce HiSilicon glorieuse mais tenace hi3510 – et décider que le moment est venu de bien faire les choses. Tu te dis: “Fini les cloud propriétaires, fini les applications louches sur votre smartphone. Aujourd'hui, j'ai configuré l'enregistrement de vidéos via FTP directement sur mon ordinateur local.”. Un peu de choix’ obligatoire, aussi parce que la prise en charge de ces appareils cesse souvent “nuage” quelques mois après leur lancement sur le marché.
Dans mon cas, au lieu d'utiliser mon PC Linux, j'utiliserai mon serveur Linux. Ouvrir le coffre-fort multimédia (OMV) est une distribution basée sur Debian qui me permet de gérer mes fichiers et partages aussi facilement qu'avec un NAS. J'ai également la possibilité de démarrer Docker et tout service qu'il prend en charge… et puis c'est Linux: J'ai à ma disposition tous les outils que je connais.
Il n'y a qu'un seul petit, énorme problème: dans les paramètres de cette caméra il n'y a aucune entrée relative à FTP. Une voix dans ma tête me suggère: “Hé, un instant… Je n'avais pas trouvé ma voix FTP dans les fichiers de configuration?” En fait c'est comme ça, mais dans l'interface cam, vous ne pouvez pas saisir de serveur de destination, vous ne pouvez pas changer de nom d'utilisateur, mot de passe ou porte.
“Ok, cette cam a l'adresse d'un serveur FTP dans un de ses fichiers de configuration, un port FTP et une paire d'identifiants, mais rien n'est visible dans l'interface. Donc cette caméra utilise FTP ou pas? Et il l'utilise… ce qu'il véhicule? Où il diffuse? Comment il se transmet?”
L'appareil est une boîte noire et le FTP est probablement programmé par le constructeur chinois pour conditionner les vidéos et les envoyer directement et uniquement à leurs serveurs distants via une application propriétaire..
Merveilleux! Ainsi commence une de ces aventures nocturnes classiques faites de terminaux ouverts, paquets réseau capturés à la volée et heures passées à créer ingénierie inverse sur un firmware qui ne voulait pas collaborer. Si vous aussi êtes coincé dans les limbes des codes d’erreur des caméras chinoises, c'est comme ça que je suis sorti vivant.
Premier obstacle: La grande tromperie du DNS (L'erreur -2)
La première chose à faire lorsqu'un appareil ne se connecte pas est de vérifier les fichiers de configuration. En téléchargeant le fichier config_action.ini de la caméra, le premier détail ridicule est apparu: le micrologiciel complètement ignoré l'IP locale du NAS que j'avais renseignée à l'écran. C'était écrit dans son code, raide comme du marbre, que pour effectuer des tests, la caméra devait d'abord contacter le serveur de la société mère: www.myidoorbell.com. Inutile de préciser que ce site n'existe plus… mais la caméra ne le sait pas.
Jusqu'à ce que la caméra reçoive une réponse de cette adresse Web, le test FTP n'a même pas démarré, cracher une erreur générique -2 (hôte inaccessible), ou du moins c'est ce que je pensais.
Comment résoudre? j'ai utilisé Accueil AdGuard (un DNS local comme les autres) pour créer une règle de réécriture DNS personnalisée. J'ai dit à mon routeur: “Sentir, quand la caméra recherche www.myidoorbell.com, Ne l'envoyez pas sur Internet. Donne-lui l'IP de mon OMV (192.168.5.10)”.
À ce moment-là, la caméra a mordu à l'hameçon. Mais l'erreur est devenue une autre.
Deuxième obstacle: Syntaxe sale et journaux silencieux (L'erreur -3)
DNS fixe, le code d'erreur de la came est passé -2 une -3. Un pas en avant, certains, mais il y avait un problème frustrant: le serveur FTP OpenMediaVault (ProFTPD) ça ne s'est pas montré absolument rien ici, connectez-vous. Le désert total.
Rechercher dans les profondeurs du firmware HiSilicon, il s'avère que ces puces envoient des commandes FTP avec une syntaxe “sale”, ajouter des espaces aléatoires à la fin des chaînes. Pour digérer ce truc, J'ai dû créer un fichier de configuration personnalisé pour ProFTPD (/etc/proftpd/conf.d/cam_fix.conf) insertion de directives de tolérance, y compris:
MultilineRFC2228 on
ServerIdent on "Ready"Cela a nettoyé les messages, mais le test échouait avec une erreur -3 et ProFTPD rimaneva ostinatamente muto. Pourquoi?
Le “Finale du patron”: Interception avec tcpdump
Quand les journaux de logiciels vous mentent ou se taisent, il n'y a qu'une chose à faire: écouter directement les câbles réseau. J'ai ouvert le terminal OMV et lancé la commande de diagnostic finale pour intercepter le trafic des caméras:
sudo tcpdump -ni any host 192.168.5.125J'ai refait le test et la scène du crime est apparue en temps réel. La caméra frappait à la porte 21 (FTP), le serveur a répondu en disant qu'il était prêt, la caméra a envoyé le nom d'utilisateur et à ce moment-là, le serveur lui a claqué la porte au nez avec ce message:
FTP: 550 Richiesto SSL/TLS sul canale di controllo
Mystère révélé! Par défaut, les versions récentes d'OpenMediaVault sont (justement) configuré pour s'attendre à des connexions FTP cryptées et sécurisées (FTPS). Mais l'ancienne puce de l'appareil photo, être rudimentaire, il ne prenait pas du tout en charge le cryptage et ne parlait que du FTP classique en texte clair. Sentir la connexion rejetée en raison du manque de TLS, la caméra a fermé la session instantanément, empêchant même la connexion d'être enregistrée dans les journaux système.
Il suffisait d'aller au tableau de bord OMV, désactiver l'exigence TLS/SSL dans les paramètres du service FTP (autoriser le trafic non crypté sur le réseau local) et redémarrez le démon.
À la fin, une dernière touche: à partir du dump du paquet, j'ai remarqué que la caméra avait tronqué le mot de passe en soli 8 caractères, ignorant les espaces ultérieurs générés par le bug de son propre panneau Web. J'ai aligné le mot de passe de l'utilisateur Linux sur OMV sur ceux 8 caractères exacts avec sudo chpasswd et…
HTTP/1.1 200 OK -> result="0"
Vittoria! La caméra est connectée, a écrit son fichier de test dans le dossier partagé et fermé la session. Le contrôle était enfin le mien.
Une réflexion nécessaire: À qui appartiennent nos données?
Ce violon nocturne, ainsi que la satisfaction d'avoir plié le matériel à ma volonté, ça m'a laissé un profond sentiment de malaise.
Vous vous souvenez des trois questions initiales? Ils étaient “Ce qu'il véhicule?”, “Où il diffuse?” et “Comment il se transmet?”.
Réfléchissez bien. Nous achetons des appareils électroniques brillants, souvent attirés par les prix défiant toute concurrence et les boîtes au design épuré. Nous les jetons, nous les connectons à la prise de courant et installons une application qui nous demande de créer un autre compte cloud. A ce moment précis, nous nous faufilons dans nos maisons, dans nos chambres, devant notre intimité familiale, un œil électronique actionné par le “M. Personne”.
Au cours de cette analyse nous avons découvert deux choses effrayantes sur cet appareil à l'origine douteuse:
- Zéro consensus, zéro transparence: Même si vous configurez la caméra pour qu'elle fonctionne localement, le firmware est programmé pour contourner vos choix et envoyer des données à un serveur distant (
www.myidoorbell.com) situé on ne sait où, sans que l'utilisateur n'ait jamais signé ou compris son consentement réel pour la gestion de ce trafic. - L'absence totale de sécurité: La caméra prétendait envoyer des flux vidéo et des informations de connexion via une connexion FTP. complètement clair, non crypté. Cela signifie n'importe qui, le long de la chaîne de nœuds Internet entre notre maison et le serveur chinois, aurait pu intercepter, regardez et sauvegardez nos vidéos sans aucun effort.
La souveraineté des données n'est pas un concept abstrait pour les philosophes du Web; c'est la décision consciente de reprendre les clés de votre propre maison. Passez une heure à configurer un serveur local, forcer un morceau de silicium capricieux à fonctionner selon nos règles et à l'isoler d'Internet m'a amusé, mais ce n'est pas qu'un passe-temps de nerd. C'est le seul moyen qui reste de tracer une frontière infranchissable entre notre vie privée et l'opacité d'un marché technologique qui veut que nous soyons constamment transparents., traqué et vulnérable.
Lorsque vous achetez votre prochain élément technologique, réfléchissez bien à ce qui pourrait se cacher derrière celui-ci., parce qu'aujourd'hui il n'y a pas que des caméras de surveillance, mais des judas intelligents, caméras intégrées aux ampoules sous le porche, caméras sur les voitures, caméras sur les robots aspirateurs. Nous faisons vraiment confiance à tous ces fabricants?
0 commentaires