« SE5 IdO sécurité des objets 2024/2025 b5 » : différence entre les versions
Aucun résumé des modifications |
|||
| (2 versions intermédiaires par un autre utilisateur non affichées) | |||
| Ligne 81 : | Ligne 81 : | ||
Nous obtenons le résultat suivant : | Nous obtenons le résultat suivant : | ||
[[Fichier:Resultat_roombapy_discover.png|Résultat de roombapy discover]] | [[Fichier:Resultat_roombapy_discover.png|Résultat de roombapy discover]] | ||
* '''Roomba_j7 :''' le modèle le plus récent, probablement le plus complexe à compromettre. | * '''Roomba_j7 :''' le modèle le plus récent, probablement le plus complexe à compromettre. | ||
| Ligne 93 : | Ligne 90 : | ||
Cependant, le mot de passe reste une énigme, car aucun n’a été spécifié lors de la configuration sur l’application iRobot. | Cependant, le mot de passe reste une énigme, car aucun n’a été spécifié lors de la configuration sur l’application iRobot. | ||
Nous supposons qu'il est généré et échangé durant l’installation, afin de sécuriser les communications entre l’application et le Roomba. | Nous supposons qu'il est généré et échangé durant l’installation, afin de sécuriser les communications entre l’application et le Roomba. | ||
Nous avons ensuite essayé de lire les paquets envoyer par l'aplication iRobot vers le Roomba et inversement. | |||
Alors, nous utilisons ettercap pour capturer les paquets entre les deux ip des deux objets. | |||
<pre> | |||
sudo ettercap -T -M /ip_roomba// /ip_Téléphone// -w capture.pcap | |||
</pre> | |||
Cela nous donne des paquets vierge sans présentations des headers donc ilisible. | |||
On étudie ensuite le paquet en important le fichier dans wireshark pour voir les entetes. | |||
Version actuelle datée du 13 novembre 2024 à 17:03
Infrastructure WIFI
Pour déployer notre infrastructure WIFI nous aurons besoin d'un serveur d'authentification. Nous utiliserons pour cela une machine virtuelle Xen.
Après avoir créer notre machine nous devons nous assurer que celle-ci possède deux interfaces:
- Une interface dans le bridge student connecté en DHCP sur le réseau info 172.26.145.0/24 avec une adresse statique 172.26.145.105 (servant également à ssh).
- Une interface dans un nouveau bridge bridge405 dans le Vlan405 avec une addresse statique 172.16.5.105 (Pour avoir notre propre réseau 172.16.5.0/24.
Nous configurons cela sur capbreton et également sur notre VM.
Nous nous tournons maintenant sur la configuration de l'access point CISCO pour du WPA2-EAP.
Nous le déployons sous le ssid VM_binome_5.
Il nous reste maintenant à spécialiser notre VM.
Nous ajoutons le service freeradius permettant de déployer un serveur d'authentification.
Après avoir spécifier l'utilisation de EAP nous ajoutons donc 2 utilisateurs:
- romain -> mdp: glopglop
- amaury -> mdp: glopglop
Pour finir après avoir tester le service d'authentification.
Nous ajoutons le service isc-dhcp-server.
Nous renseignons la plage d'adresse disponible 172.16.5.110 - 17.2.16.5.200.
Notre infrastructure WIFI est fonctionnelle. Sur notre téléphone nous retrouvons notre SSID nous pouvons nous connecter avec nos identifiants et avoir accès à internet.
Craquage Elpro Libero (medical)
Le petit appareil USB qui nous a été donné sert à enregistrer des données, notamment la température lors du transport de ressources médicales. À la fin du transport, ces données peuvent être récupérées dans un PDF transmis par le protocole USB.
sudo mount -o rw /dev/sda1 /mnt
Nous parvenons à monter le système de fichiers de ce petit appareil, mais il possède une protection qui le fait se monter en lecture seule, même en tentant de le forcer au montage. Si nous souhaitons modifier les données, il faudra retirer cette protection dans le firmware.
Après démontage de l'appareil nous découvrons le microp qui gère ce dernier. C'est un STM32L073
Nous avons lu la datasheet pour en extraire les pins SWDIO, SWCLK, RST, VSS et VDD. Et ce afin de brancher des fils sur ceux-ci pour tenter de reprogrammer le firmware à l'aide d'un ST-link.
En utilisant une board Nucleo-F401RE nous pouvons à l'aide des fils soudés brancher la carte à notre ordinateur personnel grâce au protocole de stm (stlink).
Par chance Stm ont développés un software permettant la lecture de la mémoire flash SMT32CubeProgrammer. On récupère donc le binaire et on s'attaque à la décompilation.
Le binaire apparait bien comme un firmware cortex-M avec la commande file.
file libero.bin libero.bin: ARM Cortex-M firmware, initial SP at 0x20018000, reset at 0x08003fc8, NMI at 0x080012e4, HardFault at 0x080012e6, SVCall at 0x080012ee, PendSV at 0x080012f2
Craquage Roomba
Nous avons configuré les robots sur l'application iRobot (Nous les connectons à un point d'accès wifi personnel qui est realme).
Nous supposons maintenant que l'attaquant a réussi à infiltrer le wifi personnel. Avec cet accès nous utilisons un script python Roombapy qui permet de récupérer plus d'informations sur nos Roombas.
roombapy discover
Nous obtenons le résultat suivant :
- Roomba_j7 : le modèle le plus récent, probablement le plus complexe à compromettre.
- Roomba_e5 : une version plus ancienne, que nous mettons d'abord à l'épreuve.
Ainsi, nous avons accès au nom, IP, MAC et blid de chaque appareil. Cependant, le mot de passe reste une énigme, car aucun n’a été spécifié lors de la configuration sur l’application iRobot. Nous supposons qu'il est généré et échangé durant l’installation, afin de sécuriser les communications entre l’application et le Roomba.
Nous avons ensuite essayé de lire les paquets envoyer par l'aplication iRobot vers le Roomba et inversement.
Alors, nous utilisons ettercap pour capturer les paquets entre les deux ip des deux objets.
sudo ettercap -T -M /ip_roomba// /ip_Téléphone// -w capture.pcap
Cela nous donne des paquets vierge sans présentations des headers donc ilisible.
On étudie ensuite le paquet en important le fichier dans wireshark pour voir les entetes.