« SE5 IdO sécurité des objets 2024/2025 b3 » : différence entre les versions

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
 
(5 versions intermédiaires par le même utilisateur non affichées)
Ligne 16 : Ligne 16 :
Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.
Par la suite, on a configuré notre SSID '''VM_binome_3''' pour qu'il utilise le <code>VLAN403</code> puis on l'a sécurisé avec '''WPA2-EAP'''.


Mascarade : Implementée avec succés.
Mascarade : Implementée avec succés (''Problème du chain "DROP" corrigé le 21/09'').


FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).
FreeRadius : Fonctionnel en '''PEAP-MSCHAPv2''' (2 utilisateurs disponibles).
Ligne 38 : Ligne 38 :
sudo mount /dev/sdb TempTaleUltra/
sudo mount /dev/sdb TempTaleUltra/
</syntaxhighlight>
</syntaxhighlight>
[[Fichier:20241021 154850.jpg|vignette]]
[[Fichier:Carte TempTale.jpg|vignette|Carte TempTale après soudage|302x302px]]
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.
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.


Ligne 47 : Ligne 47 :
Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].
Datasheet MCU [https://www.st.com/content/ccc/resource/technical/document/datasheet/2a/6e/97/91/cd/c0/43/8b/DM00048356.pdf/files/DM00048356.pdf/jcr:content/translations/en.DM00048356.pdf STM32L152RCT6].


D'après le Datasheet, on a :
'''''<u>Séances (21/09 + 22/09) :</u>'''''


PA14 : JTCK-SWCLK
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é).
 
[[Fichier:Connexion L152-Nucleo.jpg|vignette|229x229px|Connexion L152-Nucleo]]
Ensuite, comme une deuxième tentative, nous avons essayé de la connecter en utilisant la carte <code>NUCLEO-FR401RE</code> comme intermédiaire via le canal CN4.
{| class="wikitable"
|+ST-Link Pins
!'''VDD'''
!'''CN4-1'''
|-
|'''GND'''
|'''CN4-3'''
|-
|'''SWDIO'''
|'''CN4-4'''
|-
|'''SWCLK'''
|'''CN4-2'''
|-
|'''RST'''
|'''CN4-5'''
|}
 
 
 
En alimentant que la carte <code>NUCLEO-FR401RE</code>, 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 !
[[Fichier:Wiki-3.png|vignette|288x288px|Détection de la carte STM32L152]]
[[Fichier:Wiki-2.png|centré|vignette|420x420px|Successful connection to the target]]
 
 
[...]
 
== Craquage nedis WIFIDS20WT (Détecteur de fumée) ==
 
=== Connexion du dispositif au réseau via WIFI ===
[[Fichier:Connexion nedis via app.jpg|vignette|191x191px|Connexion nedis via app]]
Nous avons connecté notre détecteur de fumée <code>Nedis WIFIDS20WT</code> à 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 <code>Wireshark</code> 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 <code>172.20.10.2</code>
 
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 <code>172.20.10.15</code> qu'on pense être celle du dispositif.
[[Fichier:Analyse Wireshark.jpg|vignette|338x338px|1ère analyse Wireshark]]


PA13 : JTMS-SWDIO


NRST : NRST


BOOT0: BOOT0





Version actuelle datée du 13 novembre 2024 à 15:21

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 : glopglop

ayoub : glopglop

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/
Carte TempTale après soudage

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/09 + 22/09) :

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é).

Connexion L152-Nucleo

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.

ST-Link Pins
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 !

Détection de la carte STM32L152
Successful connection to the target


[...]

Craquage nedis WIFIDS20WT (Détecteur de fumée)

Connexion du dispositif au réseau via WIFI

Connexion nedis via app

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.

1ère analyse Wireshark



--

Membres : BILAL EL HASNAOUI et AYOUB CHAOUNI