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

Le but de ce module est de tester la sécurité d'objets connectés en exploitant les différentes failles possibles, qu'elles soient logicielles ou matérielles.

Partie Infrastructure WiFi

Création d'un serveur d'authentification sur capbreton

Afin de mettre en place une infrastructure WiFi, il faut un serveur d'authentification pour les éventuels utilisateurs qui tenteront de se connecter au point d'accès WiFi.

Après m'être connecté au serveur capbreton par ssh, j'ai configuré une nouvelle machine virtuelle xen appelée SE5-ling qui servira de serveur.

J'utilise la commande suivante pour me connecter à la VM :

 xen console SE5-ling

Configuration réseau

Cette machine virtuelle possède deux interfaces, une première dans dans le commutateur virtuel bridgeStudents et une autre dans le VLAN 406.

Dans le fichier /etc/network/interfaces, je configure la première interface eth0 avec l'adresse 172.26.145.106 (binôme 6) pour qu'elle soit dans le sous réseau 172.26.145.0/24.

Du côté du point d'accès Cisco, j'ai configuré et déployé le SSID VM_binome_6 dans le VLAN 406 avec comme protocole de sécurité WPA2-EAP.

Du côté du serveur, avec FreeRadius j'ai créé un utilisateur pour moi et j'ai pu ensuite me connecter en tant qu'utilisateur depuis mon téléphone .

Partie sécurité d'objets connectés

Attaque sur le Catalent TempTale

Le Catalent TempTale est un objet connecté utilisé dans la livraison de médicaments. Il suit l'évolution de la température dans les colis pendant le trajet. Cet outil permet de garantir que les produits n'ont pas été exposés à des températures inappropriées et demeurent sûrs pour la consommation. Elle possède un système de fichiers et contient un rapport des mesures enregistrées pendant la livraison.

Je vais essayer de voir ses failles au niveau logiciel puis au niveau matériel.

Partie 1 : accès logiciel par voie USB

En le branchant simplement par voie USB, la commande suivante permet de monter l'objet sur un ordinateur :

sudo mount /dev/sdb /tmp

Dans /tmp, j'ai accès aux fichiers contenu dans le Temptale. L'un d'eux correspond au rapport de température en PDF que j'ai pu visualiser. Je peux supprimer des fichier et en créer de nouveaux, il s'agit donc d'une faille possible pour cet objet. Cependant, je ne peux pas modifier le contenu original car il est protégé.

Partie 2: extraction du firmware

Dans cette seconde partie, je vais tenter d'extraire le firmware directement en utilisant un Raspberry Pi 4. Cette méthode consiste à se servir de la communication SPI pour lire et copier le firmware contenu dans la mémoire du Temptale. Un guide détaillé pour réaliser cette opération peut-être trouvé au lien suivant : https://hacklido.com/blog/379-firmware-extraction-from-spi-flash

J'ai d'abord ouvert l'appareil pour pouvoir ensuite dé souder la mémoire flash, je l'ai repérée sur la carte :

La mémoire flash sur la carte du Temptale

D'après la référence sur le composant, il s'agit d'une mémoire flash W25X40CL, construite par Winbond, dont la datasheet peut-être obtenue ici : https://www.winbond.com/resource-files/w25x40cl_f%2020140325.pdf

J'ai pu récupérer la configuration des pins afin de connaître le branchement pour l'extraction du firmware.

J'ai effectué le branchement utilisé dans le guide d'extraction du firmware que j'ai mentionné plus haut.

J'ai ensuite connecté au port SPI de la raspberry

Extraction du firmware de la flash

J'ai pu faire l'extraction du firmware à l'aide de cette commande :

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

Le fichier backup.bin est une image du contenu de la flash, en analysant le fichier obtenu avec la commande file, j'ai pu déterminer qu'il s'agissait d'un système de fichier. Cela signifie que je peux le monter avec la commande mount :

sudo mount /dev/loop0 /mnt/backup

Je retrouve les données originelles, de la partie 1 mais cette fois-ci, je peux modifier les données librement. J'ai copié les données sur une clé USB pour traiter l'information sur mon ordinateur. Ensuite, j'ai modifié le rapport PDF pour y insérer des données éronnées comme une température trop élevée :

fichier PDF modifié avec des valeurs fausses.

Pour finir, j'ai créé une autre image modifiée avec mes données et j'ai pu les téléverser dans la mémoire flash avec la commande suivante  :

sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -w modified_backup

Modifier le contenu de la flash a fonctionné car lorsque je refait une extraction de firmware sur la flash, je retrouve bien mon fichier PDF modifié.

Afin de vérifier que ce type d'attaque fonctionne, il faudrait souder à nouveau la flash sur la clé TempTale et regarder si le contenu du rapport de température est toujours modifié.

Attaque sur un interrupteur connecté

Je vais maintenant tenter d'attaquer un objet connecté de mon choix. J'ai choisi l'interrupteur mural Wi-Fi intelligent, il permet de commander à distance un interrupteur (connecté à une lampe par exemple) depuis un téléphone à partir du moment qu'on est connecté au Wifi sur les deux appareils.

Dans un premier temps, j'ai réalisé un boîtier pour faire fonctionner l'interrupteur en le branchant à une simple prise. Grâce aux outils du Fabricarium, j'ai modifié une boîte en plastique pour qu'elle puisse contenir les parties électriques haute tension de l'objet. Ce boîtier permet ainsi d'utiliser et d'étudier l'objet connecté en toute sécurité.

Boîtier final

Cet objet peut être commandé à distance par l'application mobile Nedis Smart Life et je peux allumer et éteindre l'interrupteur.

Pour tester la sécurité, je vais tenter de sniffer les paquets envoyés sur le réseau à l'aide de Wireshark. Si cela fonctionne, je vais essayer de forger mon propre paquet qui permet d'allumer/éteindre l'interrupteur sans passer par l'application.

Tout de suite, l'un des premiers problèmes rencontrés a été que je ne puisse pas voir les paquets échangés entre mon téléphone et l'objet. J'ai tenté d'utiliser les modes Promiscuous et Monitor sur wireshark mais cela pas suffit.

Partie 1: Identification des cibles avec nmap

Après avoir mis mon ordinateur sur le même réseau auquel sont connectés le téléphone et l'interrupteur, j'ai voulu utiliser Ettercap afin de faire une attaque de type Man In The Middle, le ARP poisoning. Cependant, il faut d'abord connaître l'adresse IP des deux cibles.

Afin d'identifier l'interrupteur connecté sur le réseau, j'ai utilisé l'utilitaire nmap. Celui-ci va scanner tous les appareils sur le sous-réseau et obtenir des informations sur leur système d'exploitation avec l'option -O.

La commande suivante a permis de scanner le sous-réseau :

sudo nmap -O 192.168.1.0/24

Ci-dessous, la sortie de la commmande nmap, En analysant les différents appareils relevés et en éliminant les adresses que je connaissais, j'ai pu identifier l'objet connecté ainsi que son adresse IP  :

Nmap scan report for wlan0.home (192.168.1.40)
Host is up (0.21s latency).
Not shown: 999 closed tcp ports (reset)
PORT     STATE SERVICE
6668/tcp open  irc
MAC Address: D8:1F:12:98:93:58 (Tuya Smart)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).

D'après mes recherches, Tuya Smart est une entreprise spécialisée dans les appareils connectés, c'est donc un indice pour facilement repérer ce genre d'appareils IoT.

On peut voir que l'interrupteur utilise le port 6668 pour communiquer et que sont adresse sur le sous-réseau est 192.168.1.140.

J'ai également pu retrouver l'adresse IP de mon téléphone (192.168.1.33) à l'aide de nmap et vérifier cette information en regardant dans mes paramètres réseau.

Partie 2 : Attaque MITM avec Ettercap

Avec l'adresse IP des deux cibles, je peux maintenant utiliser Ettercap.

Pour ouvrir l'interface d'Ettercap, il faut faire :

sudo ettercap -G

Les étapes pour utiliser Ettercap sont :

• Faire scanner les hôtes avec le bouton avec l'icône de loupe.
• Sélectionner les cibles d'intérêt (192.168.1.133 et 192.168.1.140) et faire "add to target 1" puis "add to target 2"
• Lancer l'attaque ARP poisonning (MITM) sur les deux cibles avec le bouton avec l'icône planète et sélectionner le type d'attaque.

Interface d'Ettercap avec attaque MITM sur les deux adresses cibles

Avec cette attaque mise en place, j'ai maintenant le trafic réseau des deux cibles (téléphone et interrupteur ) qui passe sur mon ordinateur.

Partie 3 : Capture des paquets sur Wireshark

Sur Wireshark, je peux maintenant capturer les paquets échangés lorsque j'envoie des commande de type allumer puis éteindre avec l'application mobile Nedis Smart Life :

paquets TCP capturés sur wireshark

En parcourant les différents paquets échangés, J'ai tenté de repérer les paquets avec la commande allumer/éteindre. Certains possèdent le flag PSH ou PUSH qui signifie que les données doivent être transmises à l'application le plus rapidement possible. En analysant ces paquets, J'ai remarqué que le payload reste identique lorsqu'il s'agit d'allumer ou d'éteindre.

Je fait donc l'hypothèse que les commandes pour contrôler l'interrupteur sont les suivantes :

Allumer l'interrupteur :

00 00 55 aa 00 00 05 63 00 00

00 0d 00 00 00 37 33 2e 33 00 00 00 00 00 00 00

20 00 00 a0 59 4c 9c 38 f8 59 8d ee 14 f8 22 b6

c8 5e e2 7a 1a 51 f4 4a 4f aa d1 89 86 ee bf 20

d3 b2 5d 59 10 94 70 34 00 00 00 aa 55

Éteindre l'interrupteur :

00 00 55 aa 00 00 00 00 00 00

00 09 00 00 00 08 65 93 0c 22 00 00 aa 55

D'après mes recherches, 55 aa est le header fixé par le protocole de communication qu'utilise Tuya Smart :https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb.

J'ai essayé de forger mes propres paquets avec le module scapy sur python. Cela n'a pas fonctionné car il faut pouvoir prédire le sequence number (ISN) de l'ACK TCP. Après des tests successifs, je n'ai pas trouvé de suite logique qui aurait pu me permettre de déterminer les prochains sequence numbers.

Etant donné que j'ai déterminé le port utilisé (6668) et l'adresse IP de l'objet, j'ai tenté d'utiliser netcat pour envoyer les séquences d'allumage ou d'extinction de l'interrupteur. sequence.txt contient les octets de la commande.

 netcat 192.168.1.140 6668 < sequence.txt

Malheureusement, cela n'a pas fonctionné, l'interrupteur ne réagit pas aux données envoyées. Mon hypothèse est que l'objet connecté utilise la technologie cloud. En effet, le téléphone peut ne pas être sur le même réseau et commander l'objet à partir du moment qu'ils sont tous les deux connectés à internet. Si c'est le cas alors il est probable que la sécurité du serveur cloud empêche la commande de l'interrupteur par simple renvoi des paquets.

Monôme 6: LING Dylan