SE5 IdO sécurité des objets 2024/2025 b2

Infrastructure WiFi

VM SE5-cruchet-deryckere : 172.26.145.102

Connexion au point d'accès ap_SE5 : ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc 172.26.145.1

Nous avons finis la configuration WIFI avec le WPA2-EAP (VM_binome_2). Notre Vlan est le VLAN402 et notre bridge sur capbreton est bridgeSL.

Lots d'identifiants pour notre accès WiFi

Identifiant	Mot de passe
simon	simon!
louis	louis!
pifou	********

Malheureusement, nous ne pourrons pas utiliser notre point d'accès dans cette configuration car les lampes que nous utiliserons plus tard fonctionnent uniquement en WPA-PSK. Nous verrons peut-être plus tard pour modifier la configuration mais en attendons, nous passerons par un point d'accès généré par l'un de nos PC.

Cassage des objets connectés

Enregistreur de données de température TEMPTALE 4 USB

En E304 (sur les Zabeth 02, 03 et 04), l'objet n'a pas été reconnu, mais il l'a été sur Zabeth 15.

Nous aimerions pouvoir récupérer le firmware et le modifier pour "HACKER" l'objet.

Pour accéder aux fichiers de l'objet, il suffit de le connecter et d'attendre quelques secondes. Par la suite on peut le monter avec la commande suivante :

sudo mount /dev/sdb /dossier_au_choix

Une fois monté, on peut avoir accès aux fichiers générés. Il est possible de mettre un fichier dans l'objet, montrant une première vulnérabilité.

Nous avons également démonté l'objet pour voir sa carte, sur laquelle on peut voir différents composants électronique :

• le microcontrôleur (ARM de chez Atmel)
• une mémoire flash SPI W25X40
• l'écran (non soudé, seulement maintenu mécaniquement) et son driver

On peut également déchiffrer la référence du microcontrôleur : AT91SAM7S256 (dont la datasheet, sur laquelle nous nous sommes basés, est disponible ici).

Pour extraire le firmware, nous avons :

• démonté la pile pour alimenter nous même la carte ;
• câblé les entrées/sorties de la flash pour récupérer ses informations via la Raspberry PI 4 ;
• câblé les entrées/sorties du microcontrôleur nécessaire à sa programmation (SWDIO, SWCLK, NRST et UART (UTXD et URXD) sur les pads suivants.

• 

  Emplacement des pads UTXD et URXD

• 

  Emplacement du pad RESET

• 

  Emplacement des pads SWCLK et SWDIO

Malheureusement, il n'existe pas d'utilitaire STM32 pour lire la mémoire flash de cette carte. Nous utiliserons donc le software flashrom de la Raspberry PI 4. Après avoir déssoudé la ROM de la carte et avoir branché ses pins sur la Raspberry comme décrit dans le tableau suivant, nous avons récupérer le fichier backup.bin qui contient les données de la mémoire flash.

Pin de la mémoire	Nom du pin	Pin de la Raspberry	Nom du pin
4	GND	39	Ground
1	/CS	24	GPIO 8
6	CLK	23	SCLK
2	DO	21	MISO
5	DI	19	MOSI
8	VCC	1	3V3 power
7	/HOLD	7	GPIO 4
3	/WP	3	GPIO 2

La commande que nous avons utilisée est

flashrom -p linux_spi:dev=/dev/spidev0.0 -r backup.bin

Commande de flashrom

Nous avons réussi à obtenir un fichier "backup.bin". Nous avons utilisé l'utilitaire photorec pour analyser le fichier pour rechercher un possible système de fichier. Nous avons trouvé un fichier PDF (celui disponible via USB).Le système de fichier trouvé est un vfat. En montant le système de fichier nous trouvons 2 fichiers (le PDF ainsi que qu'un fichier texte). Il serait possible de modifier le PDF afin de changer les données de température. En modifiant le fichier PDF dans le fichier backup.bin, il nous a été impossible de téléverser le code dans la flash. Il semblerait que les données de la flash ont une checksum qui nous permet pas de transvaser les données.

Il semblerait que la taille souhaitée (524288 B) est différente de la taille du fichier une fois modifié (521473 B), ce qui nous empêche de téléverser le fichier dans la flash. On pourrait attendre cette taille en remplissant les octets restants de caractères.

Lampes connectées NEDIS WIFILRW30E27

La finalité de ce module est de contrôler de façon malfaisante les lampes connectées par le biais du réseau WiFi mis en place précédemment.

Fonctionnement

Ces lampes, de la marque Nedis, sont contrôlables à distance par WiFi depuis l'application mobile Nedis Smart Life.

Après démontage d'une des trois lamps, on remarque qu'elles sont constituées de deux cartes reliés par un connecteur 2x4 :

• la carte qui gère l'éclairage constituée de 8 LEDs dite "cold" (éclairage froid, tah l'hiver) et 8 LEDs dites "warm" (éclairage chaud, ambiance tamisée) avec son driver
• la carte qui gère l'alimentation (et sûrement le WiFi et son antenne) avec sa puce BK7231N

• 

  Carte d'alimentation et de contrôle

• 

  Carte d'éclairage

Hacking

Test n°1 : Mot de passe WiFi

La lampe se connectant au téléphone et à l'application par WiFi exige, lors de la première connexion, d'entrer en clair le mot de passe du susdit réseau. Nous allons donc objectiver de récupérer ce rempart électronique qu'est le mot de passe, qui sera sûrement stockée quelque part dans la mémoire de la lampe, avec ou sans chiffrement, nous le découvrirons bientôt...

Pour ce faire, nous allons utiliser l'application BK7231 Uart flasher (v 1.60) (recommandé sur ce forum, accessible dans ce git) nous permettra de récupérer une backup du software de notre carte BK7231N dans lequel réside sûrement le mot de passe. Pour ce faire, nous récupérons les pads VCC, GND, RX1, TX1 pour assurer la liaison UART. Il est également nécessaire de court circuiter le pad CEN avec le GND pendant 1/4 de seconde comme expliqué dans notre source (soudure d'un bouton). C'est un succès : on récupère un fichier .bin que nous pouvons désormais exploiter !

En passant ce fichier sous Photorec, nous espérions trouver un système de fichiers, ce qui n'est visiblement pas le cas, le test étant un échec.

En exploitant les données, nous avons réussi à trouver le SSID et le mot de passe en clair !!!

Dans notre cas, nous connaissions le SSID ainsi que le mot de passe, ce n'est pas très intéressant mais nous allons chercher si le SSID ainsi que le mot de passe sont stockés à des endroits fixes dans la mémoire.

Nous allons maintenant changer le mot de passe chargé dans la lampe et répéter l'étape précédente pour essayer de trouver s'il y a ou non une redondance dans la manière de noter les identifiants et mots de passe.

On remarque qu'à chaque fois, le SSID du réseau est stocké dans le firmware de la ROM à partir du 774013e caractère de la 7321e ligne et le mot de passe de ce même réseau est stocké à partir du 774119e caractère, à la même ligne. En sachant cela, on peut aisément retrouver n'importe quel SSID et son mot de passe stocké sur la ROM de la lampe !!! On pourrait même extraire le firmware et récupérer les infos automatiquement avec un petit programme.

Nous avons également essayé de téléverser un firmware modifié (le mot de passe et le ssid modifiés) pour voir si la lampe peut se reconnecter à un autre wifi. Malheureusement, avec l'utilitaire utilisé, nous n'avons pas réussi à effectuer cette manipulation. Le logiciel ne reconnaissait pas le firmware modifié comme un firmware téléversable.

Lors de la recherche dans le firmware, un fichier json contenant des variables a été trouvé.

{
  "rstnum": 3,
  "rstcor": "c",
  "Jsonver": "1.1.8",
  "brightmin": 10,
  "title20": 1,
  "deftemp": 100,
  "c_lv": 1,
  "wfcfg": "spcl_auto",
  "colormin": 10,
  "pmemory": 1,
  "cmod": "cw",
  "wt": 15,
  "cwtype": 0,
  "prodagain": 0,
  "rstbr": 50,
  "remdmode": 0,
  "colormax": 100,
  "cagt": 15,
  "w_lv": 1,
  "c_pin": 24,
  "notdisturb": 0,
  "module": "CBLC5",
  "cwmaxp": 100,
  "dmod": 0,
  "rgbt": 0,
  "onoffmode": 0,
  "brightmax": 100,
  "w_pin": 26,
  "wfct": 3,
  "pwmhz": 1000,
  "rsttemp": 100,
  "category": "0502",
  "defcolor": "c",
  "defbright": 100,
  "crc": 105
}

Test n°2 : Interception des communications

Nous allons, à l'aide de Wireshark, observer les paquets IP transitant entre la lampe, le routeur et l'application mobile. Nous n'avons pu voir que les signaux de vie du téléphone et de la lampe vers le serveur. Cependant, en utilisant

sudo ethercap -T /ip_mobile// /ip_bulb// -w capture.pcap

on arrive bien à voir les paquets entre la lampe et le téléphone. On peut ensuite ouvrir le fichier capture.pcap dans Wireshark pour voir les différents paquets en clair. On remarque d'ailleurs deux types de communications autour de la lampe.

• WiFi
• Bluetooth

A priori lorsqu'elle est présente, la connexion Bluetooth a l'air d'être privilégiée. Comme elle est plus difficilement hackable, nous la désactiverons et nous concentrerons sur le WiFi.

Nous avons mis en place l'architecture suivante, nous permettant de regarder les échanges entre le téléphone, les lampes et le Cloud.

Avec cette configuration, on peut espionner les paquets entre le réseau et le Cloud sur le PC n°1. On arrive d'ailleurs à intercepter quelques paquets intéressants :

• 

  Echange d'informations DNS

• 

  Handshake entre le serveur (Cloud) et le client (lampe)

• 

  Appairage de la lampe avec l'appli

On peut noter ici les adresses IP de la lampe (192.168.137.240) et du Cloud (3.122.134.146). Par ailleurs, les adresses IP appartenant au sous réseau 3.0.0.0/8 appartiennent à amazon.com en Amérique du Nord. Lors de l'appairage de la lampe, un échange entre le PC n°1 et la lampe en DHCP s'effectue, suivi d'un handshake. On a également remarqué que l'adresse du Cloud changeait. Lors d'un essai différent, les mêmes opérations sont effectuées vers 3.123.124.46.

Il y a un échange DNS qui s'effectue entre la lampe, le PC n°1 et trois serveurs Amazon (ici 3.65.95.68, 3.64.85.28 et 18.192.43.219).

On pourrait se faire passer pour l'un de ses serveurs en créant nous même un serveur HTTPS. Dans le cas où la lampe ne vérifie pas les certificats (ce qui est peu probable vu la taille des certificats comparé à la taille de la mémoire), on pourrait alors décider des actions de la lampe à sa place.

Conclusion

Etant donné que les lampes font appel à un serveur distant sécurisé, il est compliqué de récupérer quelconque information de cette communication.

De plus, la technologie Bluetooth est un moyen de communication dont nous n'avons pas le bagage théorique et le matériel nécessaire pour un travail réussi et propre.

Synthèse du module

Ce module nous a permis dans un premier temps de confirmer nos connaissances en infrastructure WiFi en créant à nouveau notre propre interface avec le cryptage WPA2-EAP, que nous n'avions pour l'instant pas utiliser.

De plus, nous avons pu utiliser multiples outils pour réussir à trouver des informations confidentielles et cachées à l'intérieur des objets ou en interceptant leurs communications, que ce soit le capteur ou les lampes.