URL: https://linuxfr.org/news/son-et-lumiere-a-l-hotel Title: Son et lumière à l’hôtel Authors: palm123 Yves Bourguignon, BAud, Nÿco, M5oul, Benoît Sibaud, Florent Zara et ʭ ☯ Date: 2016年05月23日T07:49:05+02:00 License: CC By-SA Tags: iot, sécurité et mplayer Score: 87 Deux histoires d'informatique à l'hôtel traduites en français : 1. c'est celle d'un étudiant, Gökberk Yaltıraklı, qui « aime coder, écouter de la musique et voyager » et qui nous raconte sur son blog une enquête menée lors d'un séjour à l'hôtel. Son site est http://gkbrk.com/ et nous le remercions de nous autoriser à reproduire son article traduit. 2. c'est celle d'un autre voyageur, Matthew Garrett, qui nous raconte ses découvertes dans un hôtel qui n'a, a priori, pas fini sa mutation technologique... Et nous le remercions de nous autoriser à reproduire son article traduit. ---- [Quel est ce flux en UDP sur le port 2046 ?](http://wiki.gkbrk.com/Hotel_Music.html) [Jouer avec les lumières de sa chambre d'hôtel, ou des autres chambres...](https://mjg59.dreamwidth.org/40505.html) ----  # Du son pour tout le monde # ## Faire de la rétro-ingénierie sur un mystérieux flux UDP à l'hôtel ## Salut tout le monde. Je me suis retrouvé à l'hôtel pendant quelques temps. Un de ces hôtels modernes avec smart TV et autres objets connectés. Je suis curieux, je lance [[Wireshark]], comme tout bidouilleur ferait. J'ai été très surpris de voir un énorme trafic UDP sur le port 2046. J'ai regardé, mais les résultats étaient inhabituels. Ce port n'est pas dans les [ports standards](http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml), donc je dois trouver tout seul. Je suspecte d'abord un flux pour la télévision, mais la taille de paquet est trop faible, même pour une seule trame vidéo. ## Récupération des données ## Les paquets UDP ne sont pas envoyés à mon IP et je ne fais pas d'[ARP spoofing](https://fr.wikipedia.org/wiki/ARP_poisoning), donc ces paquets sont envoyés à tout le monde. En y regardant de plus près, je vois que ces paquets sont du type Multicast. Ça signifie que ces paquets sont envoyés une fois et reçus simultanément par tous les équipements connectés. Je note aussi que ces paquets sont de longueur identique (634 octets). Je décide d'écrire un script en Python pour collecter et analyser ces données. Tout d'abord, voici le code que j'ai utilisé pour collecter les paquets de type Multicast. Dans le code qui suit, 234.0.0.2 est l'adresse IP obtenue dans Wireshark. ```python import socket import struct s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(('', 2046)) mreq = struct.pack("4sl", socket.inet_aton("234.0.0.2"), socket.INADDR_ANY) s.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq) while True: data = s.recv(2048) print(data) ``` En plus de tout cela, j'ai aussi utilisé [binascii](https://docs.python.org/2/library/binascii.html) pour tout convertir en hexadécimal afin de rendre la lecture des octets plus facile. Après avoir vu des milliers de ces paquets défiler en console, je remarque que les (plus ou moins) 15 premiers caractères sont identiques. Ces octets indiquent sans doute le protocole et le _packet/command ID_ mais je reçois toujours le même donc je suis bloqué. ## Les paquets pour l'audio sont tellement mal foutus ## Cela m'a aussi pris un temps fou pour remarquer la chaîne `LAME3.91UUUUUUU` à la fin des paquets. Je soupçonne des données audio, du type MPEG compressé, mais un paquet sauvegardé en tant que test.mp3 ne peut être joué dans mplayer, et l'utilitaire `file` identifie ce fichier test.mp3 comme étant de type data. Il y a évidemment des données dans ce paquet, et l'utilitaire file devrait reconnaître des données MPEG audio, donc je décide d'écrire un autre script Python pour sauvegarder les paquets de données avec des décalages. De cette manière, il va sauvegarder le fichier test1 en sautant 1 octet du paquet, test2 en sautant 2 octets et ainsi de suite. Voici le code utilisé et le résultat. ```python data = s.recv(2048) for i in range(25): open("test{}".format(i), "wb+").write(data[i:]) ``` Après cela, je lance `file test*` et voilà ! Nous savons maintenant qu'il faut sauter 8 octets pour aller aux données de type MPEG Audio. ```python $ file test* test0: data test1: UNIF v-16624417 format NES ROM image test10: UNIF v-763093498 format NES ROM image test11: UNIF v-1093499874 format NES ROM image test12: data test13: TTComp archive, binary, 4K dictionary test14: data test15: data test16: UNIF v-1939734368 format NES ROM image test17: UNIF v-1198759424 format NES ROM image test18: UNIF v-256340894 format NES ROM image test19: UNIF v-839862132 format NES ROM image test2: UNIF v-67173804 format NES ROM image test20: data test21: data test22: data test23: DOS executable (COM, 0x8C-variant) test24: COM executable for DOS test3: UNIF v-1325662462 format NES ROM image test4: data test5: data test6: data test7: data test8: MPEG ADTS, layer III, v1, 192 kbps, 44.1 kHz, JntStereo test9: UNIF v-2078407168 format NES ROM image `̀`` Maintenant, tout ce qu'il nous faut, c'est lire les paquets en continu, sauter les 8 premiers octets, écrire le reste dans un fichier et il devrait pouvoir être lu. ```python while True: data = s.recv(2048) sys.stdout.buffer.write(data[8:]) ``` Mais quel est ce son ? Est-ce un bug sournoisement placé qui m'écoute ? Est-ce quelque chose en lien avec les téléviseurs évolués dans ma chambre ? Quelque chose en rapport avec les systèmes hôteliers ? Un seul moyen de le savoir. ```bash $ python3 listen_2046.py> test.mp3 * wait a little to get a recording * ^C ``` ```bash $ mplayer test.mp3 MPlayer (C) 2000-2016 MPlayer Team 224 audio & 451 video codecs Playing test.mp3. libavformat version 57.25.100 (external) Audio only file format detected. ===== Starting playback... A: 3.9 (03.8) of 13.0 (13.0) 0.7% ``` ## Révélation et grosse déception ## Quoi ? Je ne peux pas croire que j'ai passé tout ce temps pour ça ? Juste de la [musique d'ascenseur](https://fr.wikipedia.org/wiki/Muzak) jouée dans les couloirs et autour des ascenseurs de l'hôtel. Bon, au moins je peux l'écouter depuis ma chambre maintenant :-) ------------------------------------------- # De la lumière pour les autres # Je suis à Londres pour la conférence [Kubernetes](http://kubernetes.io/) et mon hôtel a décidé que les interrupteurs (pour allumer et éteindre la lumière) sont démodés, et les a remplacé par des tablettes sous Android.  Une tablette est encastrée dans le mur, mais les deux à côté du lit avaient des chouettes câbles Ethernet dans le mur. Je réussis à emprunter 2 adaptateurs USB Ethernet, crée un bridge transparent ```brctl addbr br0; brctl addif br0 enp0s20f0u1; brctl addif br0 enp0s20f0u2; ifconfig br0 up``` et je branche mon portable entre la tablette et le mur. ```tcpdump -i br0``` montre du trafic, et wireshark a montré que c'est du [Modbus](https://fr.wikipedia.org/wiki/Modbus) over TCP. Modbus est un protocole assez trivial, entre autres choses, il n'a pas de mécanisme d'authentification. tcpdump montre que le trafic est envoyé à 172.16.207.14, et [pymodbus](https://pymodbus.readthedocs.io/en/latest/) me permet d'allumer ou éteindre les lumières, la TV, et même mes rideaux. Quel pied ! Et alors je remarque un truc. Mon numéro de chambre est 714, mon adresse IP est 172.16.20 **7.14** . Ils n'auraient pas osé ? Oui, évidemment, ils ont osé. C'est aussi mauvais que possible, une fois la passerelle trouvée, je peux accéder au système de contrôle de chaque étage, et interroger chaque chambre pour voir si les lumières sont allumées ou pas, ce qui sous-entend fortement que je peux aussi les contrôler. Jesus Molina a parlé de ce genre de choses [il y a deux ans](https://www.defcon.org/images/defcon-22/dc-22-presentations/Molina/DEFCON-22-Jesus-Molina-Learn-how-to-control-every-room-WP.pdf), ce n'est pas un cas isolé, les hôtels sont en train de déployer ce genre de système sans la moindre sécurité, et la probabilité que quelqu'un envoie un flux constant de « allumez la lumière » et « ouvrez les rideaux » à 3 heures du matin est élevée. Tout cela est voué à l'échec (Note : J'avais prétendu que je ne pouvais accéder qu'aux équipements de mon étage, mais en fait chaque étage est sur une zone de diffusion séparée, et je dois juste définir une autre passerelle pour accéder aux autres étages.) (Autre note : je fais exprès de ne pas nommer l'hôtel. Ils ont été réceptifs à mon retour et ont promis de régler le problème.) Dans les commentaires, une personne demande s'il est possible d'allumer le _pay-per-view_ sur la TV des autres chambres. Nous n'avons pas de réponse.