« SE5 IdO sécurité des objets 2024/2025 b3 » : différence entre les versions
| (3 versions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 28 : | Ligne 28 : | ||
''<u>Utilisateurs existants (user : mdp):</u>'' | ''<u>Utilisateurs existants (user : mdp):</u>'' | ||
bilal : | bilal : g******p | ||
ayoub : | ayoub : g******p | ||
== Craquage TempTale Ultra Temperature Sensor == | == Craquage TempTale Ultra Temperature Sensor == | ||
| Ligne 51 : | Ligne 51 : | ||
On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir : | On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir : | ||
* 3.3V (câble bleu) | |||
* GND (câble noir) | |||
* SWDIO (câble blanc) | |||
* SWCLK (câble gris) | |||
* RESET (câble orange) | |||
Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité). | Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité). | ||
| Ligne 148 : | Ligne 144 : | ||
Nous avons vérifié ces deux adresses IP, et elles sont bien incluses dans les plages d’IP réservées pour AWS dans la région '''eu-central-1''' ( Francfort ). | Nous avons vérifié ces deux adresses IP, et elles sont bien incluses dans les plages d’IP réservées pour AWS dans la région '''eu-central-1''' ( Francfort ). | ||
Les deux IP adresses sont des | Les deux IP adresses sont des machines virtuelles EC2 hébergées dans la région '''eu-central-1''' (Francfort). | ||
[[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154|364x364px]] | [[Fichier:Analyse @IP1.jpg|alt=Analyse @IP1|vignette|Analyse de l'adresse 3.124.85.154|364x364px]] | ||
Version actuelle datée du 8 janvier 2025 à 14:42
Sécurisation WiFi par WPA2-EAP
Séance (25/09) :
- Serveur virtuel
Nous avons créé une MV sous le nom de SE5-elhaschaouni sur Capbreton en utilisant l'hyperviseur xen. (voir mdp : cat /var/log/xen-tools/SE5-elhaschaouni.log)
Cette dernière a 2 interfaces, avec l'adresse IP 172.26.145.103 sous eth0 et 172.26.3.103 sous eth1 dans le VLAN 403.
Pour cela, les interfaces VLAN403 et br403 ont été configurées sur capbreton (voir /etc/network/interfaces.d)
- Point d'accés WiFi
Nous avons fait la première configuration via console du point d'accès Cisco, notamment la configuration du SSH pour que les autres binômes puissent se connecter à la borne via SSH.
Par la suite, on a configuré notre SSID VM_binome_3 pour qu'il utilise le VLAN403 puis on l'a sécurisé avec WPA2-EAP.
Mascarade : Implementée avec succés (Problème du chain "DROP" corrigé le 21/09).
FreeRadius : Fonctionnel en PEAP-MSCHAPv2 (2 utilisateurs disponibles).
DNS : Configuré avec bind9.
Serveur DHCP : Configuré. Le "range" des adresses IP allant de 172.16.3.100 à 172.16.3.200
Accès Internet : OUI (On peut regarder des vidéos sur youtube)
Utilisateurs existants (user : mdp):
bilal : g******p
ayoub : g******p
Craquage TempTale Ultra Temperature Sensor
L'appareil TempTale Ultra est un enregistreur d'humidité et de température élégamment conçu avec USB intégré qui peut mesurer les températures ambiantes de -30°C à +70°C et l'humidité de 0% RH à 100% Rh (Rh). Cet appareil compact, simple ou polyvalent, crée automatiquement un fichier PDF sécurisé et un fichier de données cryptés sans avoir besoin de logiciels supplémentaires.
Il est simple d'accéder aux fichiers générés par TempTale Ultra :
sudo mount /dev/sdb TempTaleUltra/
Comme une première tentative, on a essayé de modifier directement les données dans les fichiers mais ces dernières sont protégées en lecture seule. Et le fichier TTV est crypté. La seule solution pour modifier les données est de retirer cette protection dans le firmware.
Après démontage de TempTale Ultra, on trouve que le MCU utilisé est : STM32L152RCT6.
D'après le Datasheet, on trouve les PINs SWDIO, SWDCLK, NRST et VDD qui nous permettent de reprogrammer le MCU à l'aide d'un ST-LINK et STM32CubeIDE.
Datasheet MCU STM32L152RCT6.
Séances (21/10 + 22/10) :
On s'attaque au soudage des pins JTAG, pour cela il fallait bien identifier les 5 pins dont nous avons besoin, à savoir :
- 3.3V (câble bleu)
- GND (câble noir)
- SWDIO (câble blanc)
- SWCLK (câble gris)
- RESET (câble orange)
Nous avons revérifier ces connexions entre les sorties du MCU et les pins JTAG à l'aide d'un multimètre (continuité).
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte NUCLEO-FR401RE comme intermédiaire via le canal CN4.
| VDD | CN4-1 |
|---|---|
| GND | CN4-3 |
| SWDIO | CN4-4 |
| SWCLK | CN4-2 |
| RST | CN4-5 |
En alimentant que la carte NUCLEO-FR401RE, notre carte TempTale se trouve sans alimentation. Du coup, nous l'avons alimenté séparement via USB.
Par la suite, nous avons essayé de se connecter à la carte via le logiciel STM32 ST-LINK Utility. Cette fois-ci, on arrive à accéder à notre carte !
Craquage nedis WIFIDS20WT (Détecteur de fumée)
Connexion du dispositif au réseau via WIFI
Nous avons connecté notre détecteur de fumée Nedis WIFIDS20WT à l'application mobile Nedis en suivant les étapes simples de configuration. Après avoir installé l'application sur notre smartphone, nous avons activé le Wi-Fi et ajouté le détecteur au réseau. L'application permet également de surveiller l'état du détecteur et d'effectuer des tests à distance.
Analyse du trafic réseau
Dans un premier temps, nous avons tenté d'analyser le trafic réseau via Wireshark afin d’identifier des échanges spécifiques liés au protocole WPA2, notamment les trames EAPOL (Extensible Authentication Protocol Over LAN) échangées lors du 4-Way Handshake. En capturant ces trames, notre objectif était de surveiller les retransmissions qui pourraient indiquer une tentative de réinstallation de clé, point central de l’exploitation de la faille KRACK.
Nous avons essayé d'identifier l'adresse IP que le dispositif Nedis utilise sur le réseau (connexion partagée depuis notre smartphone). Pour ce faire, nous avons appliqué un filtre spécifique dans Wireshark, en utilisant l'adresse IP de notre smartphone personnel comme référence 172.20.10.2
Ce filtre nous a permis de capturer uniquement les paquets ayant pour source notre smartphone, ce qui nous a aidés à repérer les échanges réseau dirigés vers le dispositif Nedis. En isolant ces paquets, nous avons pu mieux analyser les interactions spécifiques entre notre smartphone et le dispositif, et tenter de déterminer l'adresse IP assignée à ce dernier sur le réseau pour poursuivre les analyses liées à la vulnérabilité KRACK.
L'adresse IP la plus "suspecte" pour l'instant est 172.20.10.15 qu'on pense être celle du dispositif.
---
Après plusieurs tentatives avec le réseau du téléphone, on arrive à obtenir la "bonne adresse IP" avec l'adresse MAC du dispositif mais ce dernier n'arrive pas à maintenir une connexion stable (comme affiché sur la capture d'écran ci-dessous).
Nous avons alors décidé de changer de réseau et se connecter avec le Wifi WIFI_IA_SE5
On réalise un premier scan du réseau avec l'utilitaire nmap pour voir tous les appareils connectés avec leur adresse MAC correspondante, en espérant trouver notre dispositif connecté à ce réseau.
Deuxième tentative
On réessaye de connecter le dispositif en utilisant le réseau de notre smartphone.
192.168.89.183 : Adresse IP du dispositif
192.168.89.186 : Adresse IP du PC effectuant l'analyse
On peut voir des paquets entre le PC et le dispositif, mais pas grand chose du côté serveur.
Étant donné que le smartphone joue le rôle d'un MITM, on arrive pas à capturer des paquets pertinents.
On retrouve en grande partie des paquets de communication entre le PC et le dispositif (comme affiché sur l'image ci-joint).
Troisième tentative
Cette fois-ci, on utilisera le réseau PLIL pour ne pas avoir notre smartphone comme étant MITM.
D'après une analyse approfondie sur Wireshark, on arrive déjà à voir les paquets lors de la première connexion (requêtes SYNC) et d'autres paquets intéressants dès le démarrage du dispositif. Ceci n'était pas possible avant car il y avait le téléphone qui n'affichait pas en quelque sorte les paquets destinés directement au dispositif.
Pour cette manipulation, nous avons utilisé le réseau PLIL et tenté une attaque de type MITM. Plusieurs simulations de fumée ont été réalisées afin d’observer le comportement du système ainsi que les paquets échangés entre le capteur, l’application NEDIS et d’autres adresses IP publiques.
Après plusieurs tentatives de simulation, nous avons pu identifier deux adresses IP publiques apparaissant systématiquement dans les communications :
Adresse IP : 3.124.85.154 : Cette adresse appartient à la plage des IP réservées pour AWS (Amazon Web Services).
Adresse IP : 18.197.183.192 : Cette adresse appartient également à la plage des IP réservées pour AWS.
Nous avons vérifié ces deux adresses IP, et elles sont bien incluses dans les plages d’IP réservées pour AWS dans la région eu-central-1 ( Francfort ).
Les deux IP adresses sont des machines virtuelles EC2 hébergées dans la région eu-central-1 (Francfort).
Analyse Des serveurs CLOUD
Adresse IP : 3.124.85.154 : Contient 3 ports (80, 443 et 7010) qui sont ouverts et utilise principalement comme services HTTP/HTTPS. (Comme affiché sur les captures d'écran).
Adresse IP : 18.197.183.192 : Contient également 3 ports ouverts, dont 1 qui utilise du MQTT sur le port 1883 et un autre en MQTT-S sur le port 8883.
Workflow Potentiel
Capteur ---> 18.197.183.192 : Le capteur envoie des données via MQTT/MQTTS. Cette instance EC2 pourrait également acheminer les messages vers d'autres services pour traitement ou visualisation.
Capteur ---> 3.124.85.154 : L'application mobile/Capteur communique avec le (API Gateway) serveur pour des opérations destinées à l'utilisateur, telles que la récupération de données stockées, l'envoi de commandes de contrôle au capteur ou la gestion des comptes d'utilisateurs.
Mock du serveur MQTT
L'idée sera de créer un mock server avec la même adresse IP, sur notre machine, et essayer de faire passer une communication de paquets via notre machine plutôt que passer par le serveur d'origine. Une fois ceci sera réalisé, nous pourrons commencer à craquer et manipuler le dispositif comme souhaité.
En analysant les paquets à destination de ce serveur, nous avons remarqué que la communication passe par le port 8883 qui nécessite le protocole MQTTS (ceci va nous poser un blocage car un certificat sera nécessaire par la suite).
On va essayer de falsifier la connection en configurant un nouveau serveur MQTT-S sur la zabeth17. On a généré un certificat, une clé et CA en utilisant les commandes suivantes :
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt -subj "/C=US/ST=Newyork/L=Newyork/O=Nedis/CN=18.197.183.192"
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/C=US/ST=Newyork/L=Newyork/O=Nedis/CN=18.197.183.192"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256
