SE5 IdO sécurité des objets 2024/2025 b1
Configuration du routeur wifi pour notre VLAN 11
Le VLAN est apparent sur le réseau, mais il n'y a pas d'accès Internet.
Pourtant, il semble que nous ayons la même configuration que les binômes qui avaient un wifi fonctionnel.
Configuration de l'interface eth0 (172.26.145.101) et eth1 (172.16.11.111) sur la VM SE5-WIJSMAN-LEFRANC sur Capbreton.
Dans la VM, configuration de FreeRADIUS:
/etc/freeradius/3.0/users:
louis Cleartext-Password := "glopglop" MS-CHAP-Use-NTLM-Auth := Yes
/etc/freeradius/3.0/clients.conf:
client wifi_ap {
ipaddr = 172.26.145.1
secret = glopglop
shortname = VM_binome_11
}
Sur le routeur CISCO:
Mise en place d'un point d'accès VM_binome_11 avec comme mot de passe "glopglop" en suivant les commandes du wiki.
ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc 172.26.145.1
...
aaa new-model
aaa authentication login eap_binome_11 group radius_binome_11
radius-server host 172.26.145.101 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_binome_11
server 172.26.145.101 auth-port 1812 acct-port 1813
!
...
dot11 ssid VM_binome_11
vlan 411
authentication open eap eap_binome_11
authentication network-eap eap_binome_11
authentication key-management wpa
mbssid guest-mode
!
...
interface Dot11Radio0
encryption vlan 411 mode ciphers aes-ccm
...
!
...
interface Dot11Radio0.11
encapsulation dot1Q 411
bridge-group 11
!
interface GigabitEthernet0.11
encapsulation dot1Q 411
bridge-group 11
!
Piratage d’objets connectés
Objectif :
Dans un premier temps, notre objectif est de pirater une sonnette sans fil.
Ensuite, nous tenterons également de compromettre un capteur de température LIBERO CS afin d'analyser sa sécurité et ses vulnérabilités.
Sonnette sans fil
Matériel utilisé :
- PC avec GNU Radio
- SDR HackRF One
Méthodologie :
- Analyse du signal : Nous commençons par analyser le signal envoyé lorsqu'on appuie sur le bouton de la sonnette à l'aide d'un analyseur de spectre.
- Analyse des trames : Nous analysons la trame envoyée à chaque appui sur le bouton. Après une série de tests, nous avons découvert que la trame envoyée est toujours la même.
- Reproduction du signal : Dans un deuxième temps, nous mettons en place un programme sur GNU Radio pour reproduire le signal, afin de faire croire à la sonnette que le bouton a été appuyé.
Méthode 1 : Ecoute et réémission (PARROT) :
La méthode consiste à utiliser une antenne et un récepteur SDR pour écouter le signal émis par la télécommande, puis à le réémettre après enregistrement.
Le programme GNU Radio utilisé pour cette opération est présenté à droite.
Problèmes rencontrés
Malheureusement, cette approche ne fonctionne pas en l’état, pour deux raisons principales :
- Accumulation de bruit : Lors de l’enregistrement, du bruit parasite est capté avec le signal. Lors de la réémission, ce bruit est amplifié, ce qui altère la qualité du signal transmis.
- Manque de puissance : Une puissance insuffisante lors de la réémission peut empêcher le signal d’avoir un effet notable, d’autant plus que l’augmentation de puissance améliorerait également le rapport signal/bruit.
Améliorations possibles
Cette méthode pourrait être optimisée en ajoutant :
- Des filtres pour réduire le bruit et améliorer la qualité du signal réémis.
- Un amplificateur pour garantir une puissance suffisante et assurer une transmission efficace.
Méthode 2 : Recréation du signal
Nous avons utilisé un oscilloscope et une sonde de champ proche pour améliorer le rapport signal/bruit et ainsi observer clairement le signal.
Dans un premier temps, nous avons analysé le signal à l’aide d’un récepteur SDR, mais celui-ci introduisait des défauts suffisants pour altérer la qualité du rendu. Nous avons ensuite amélioré la mesure en utilisant un oscilloscope professionnel, ce qui nous a permis d’obtenir les fréquences exactes du signal.
Grâce à ces mesures, nous avons développé un programme GNU Radio capable de reproduire le signal de la télécommande.
Structure du signal
La trame transmise contient le message suivant, répété 75 fois par pression sur le bouton :
0001010011000111100110000
Le codage du signal est défini ainsi :
- 0 : 0,2 ms high + 0,6 ms low
- 1 : 0,6 ms high + 0,2 ms low
Nous prenons le PGCD de 6 et 2, soit 2, ce qui nous donne un pas de temps minimal de 0,2 ms. Un signal de 5 kHz est donc utilisé pour générer cette modulation.
L'encodage du signal à 5 kHz suit la règle suivante :
- 0 → 1000
- 1 → 1110
Par exemple, pour coder le message "101", nous transmettons la séquence : 1110 1000 1110.
Nous avons utilisé une fréquence d’échantillonnage (sampling rate) de 10 MHz, largement supérieure à 433 kHz, garantissant ainsi un signal propre. L'interpolation est réalisée avec un facteur de 2000 pour obtenir un signal carré net : 2k × 5k = 10M.
Résultats
Après de nombreux tests et ajustements, nous avons réussi à déclencher l’alarme à environ 1 mètre de distance. En intégrant un système d’amplification, il serait possible d’augmenter considérablement cette portée.
Capteur de température LIBERO
Objectif
L’objectif est de contourner le système afin de modifier les valeurs enregistrées en mémoire et fausser les mesures de température.
Analyse matérielle
Nous avons démonté le boîtier afin d’examiner le PCB et les composants. L’image ci-dessous montre l’emplacement du capteur de température.
Deux approches ont été envisagées pour compromettre le capteur :
Modification matérielle :
Le capteur semble être une CTN (thermistance à coefficient de température négatif).
Il est possible d’ajouter une résistance en parallèle ou de remplacer complètement la CTN, ce qui permettrait de modifier les valeurs mesurées à volonté.
Reprogrammation du microcontrôleur :
Le microcontrôleur utilisé est un STM32L073CZTB.
Nous avons identifié plusieurs testpoints sur la carte, utilisés pour la programmation automatisée.
Nous avons procédé à une rétro-ingénierie afin de localiser les pins de reprogrammation :
- NRST (Pin 7) : Reset du microcontrôleur
- SWDIO (Pin 34, PA13) : Interface de communication bidirectionnelle
- SWCLK (Pin 35, PA14) : Horloge du débogage série
- VSS (Pin 8 ou 33) : Masse
- VDD (Pin 9 ou 36) : Alimentation
Aprés s'être connecter dessus voici les étapes que nous avons réalisés.
Étapes du contournement
1. Récupération du programme
Nous avons utilisé le logiciel STM32 Programmer et un ST-Link V2 pour extraire le programme via le port SWD.
Une lecture complète (READ ALL) permet d’obtenir un fichier .bin contenant le firmware.
2. Analyse du programme
Le fichier .bin a été analysé avec Ghidra, configuré pour un ARM Cortex-M 32 bits.
Grâce à Ghidra SVD Loader, nous avons chargé le fichier SVD du STM32 pour afficher les registres et leur correspondance en mémoire.
Nous avons identifié plusieurs zones d’intérêt :
- Le programme principal : Adresse 0x02E850
- Les valeurs stockées en mémoire : Adresse 0x9010 - 0x9384
- Le fichier PDF contenant les mesures :
- Stocké en mémoire de 0x2B040 à 0x2414B
- Le template du PDF est entre 0x237C8 et 0x24163
- Le fichier commence à 0x8300 et se termine à 0x2414B
3. Modification du programme
Nous avons cherché à modifier la récupération des valeurs mesurées par l’ADC du STM32.
L’objectif était de détourner la lecture du registre ADC_DR (offset 0x40 dans l’ADC) et de le remplacer par une autre valeur, par exemple le registre ISR (Interrupt Status Register).
Cette modification devait perturber l’affichage des températures dans le PDF généré.
4. Réinjection du programme
Le programme modifié a été réinjecté via STM32 Programmer.
5. Vérification des résultats
L’analyse dans Ghidra a confirmé que la valeur du registre mesuré avait bien été modifiée.
Cependant, nous avons rencontré une difficulté pour relancer une nouvelle mesure, sans parvenir à identifier la séquence nécessaire dans le code.
Nous avons aussi modifié une valeur à l’adresse 0x9010, ce qui a entraîné un changement dans le graphique des températures du PDF généré par la clé.
Cependant, nous n’avons pas encore compris précisément l’impact de cette modification sur l’ensemble du système.
Par manque de temps, nous n’avons pas poursuivi l’exploration, mais cette approche pourrait être approfondie pour mieux comprendre la manière dont le système enregistre et affiche les mesures.
Conclusion
Nous avons démontré plusieurs moyens potentiels pour compromettre le capteur LIBERO CS :
- Altération matérielle du capteur (ajout/remplacement de composants).
- Reprogrammation du microcontrôleur pour modifier les valeurs enregistrées.
Des recherches supplémentaires seraient nécessaires pour comprendre comment déclencher une nouvelle mesure après modification et pour affiner les modifications appliquées au système.