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

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche
 
(28 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
== Infrastructure WiFi ==
== Infrastructure WiFi ==
VM SE5-cruchet-deryckere : 172.26.145.102
''VM SE5-cruchet-deryckere : 172.26.145.102''


''Connexion au point d'accès ap_SE5 : ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc 172.26.145.1''


Connexion au point d'accès : ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc 172.26.145.1
Nous avons finis la configuration WIFI avec le WPA2-EAP (VM_binome_2). Notre Vlan est le VLAN402 et notre bridge sur capbreton est bridgeSL.
{| class="wikitable"
|+Lots d'identifiants pour notre accès WiFi
!Identifiant
!Mot de passe
|-
|simon
|simon!
|-
|louis
|louis!
|-
|pifou
|pasglop
|}


Nous avons finis la configuration WIFI avec le WPA2-EAP.
== Cassage des objets connectés ==


Plusieurs lots d'identifiants existent :
=== Enregistreur de données de température TEMPTALE 4 USB ===
En E304 (sur les Zabeth 02, 03 et 04), l'objet n'a pas été reconnu, mais il l'a été sur Zabeth 15.


simon ; simon !
Nous aimerions pouvoir récupérer le firmware et le modifier pour "HACKER" l'objet.


louis ; louis!
Pour accéder aux fichiers de l'objet, il suffit de le connecter et d'attendre quelques secondes. Par la suite on peut le monter avec la commande suivante : <syntaxhighlight lang="bash">
sudo mount /dev/sdb /dossier_au_choix
</syntaxhighlight>Une fois monté, on peut avoir accès aux fichiers générés. Il est possible de mettre un fichier dans l'objet, montrant une première vulnérabilité.


pifou ; pasglop
Nous avons également démonté l'objet pour voir sa carte, sur laquelle on peut voir différents composants électronique :


== Cassage des objets connectés ==
* le microcontrôleur (ARM de chez Atmel)
* une mémoire flash SPI
* l'écran (non soudé, seulement maintenu mécaniquement) et son driver


=== Enregistreur de données de température TEMPTALE 4 USB ===
On peut également déchiffrer la référence du microcontrôleur : AT91SAM7S256 (dont la datasheet, sur laquelle nous nous sommes basés, est disponible [https://www.keil.com/dd/docs/datashts/atmel/at91sam7s256_ds.pdf ici]).
En E-304 (sur les ZABETH 2-3-4), l'objet n'a pas été reconnu, mais il l'a été sur ZABETH15.


Nous aimerions pouvoir récuperer le firmware et le modifier pour "HACKER" l'objet.
Pour reprogrammer le firmware, nous avons :


Pour accéder aux fichiers de l'objet, il suffit de le connecter et d'attendre quelques secondes. Par la suite on peut le monter avec la commande suivante : sudo mount /dev/sbX /dossier_au_choix
* démonté la pile pour alimenter nous même la carte ;
* câblé les entrées/sorties de la flash pour récupérer ses informations via la Raspberry PI 4 ;
* câblé les entrées/sorties du microcontrôleur nécessaire à sa programmation (SWDIO, SWCLK, NRST et UART (UTXD et URXD) sur les pads suivants.
<gallery widths="360" heights="360">
Fichier:Uart temptale4usb simonlouis.jpg|Emplacement des pads UTXD et URXD
Fichier:Reset temptale4usb simon louis2.jpg|Emplacement du pad RESET
Fichier:Procesor temptale4usb simon louis.jpg|Emplacement des pads SWCLK et SWDIO
</gallery>


Il fois monté, on peut avoir accés aux fichiers générés. Il possible de mettre un fichier dans l'objet, montrant une première vulnérabilité.
Malheureusement, il n'existe pas d'utilitaire STM32 pour lire la mémoire flash de cette carte. Nous utiliserons donc le software flashrom de la Raspberry PI 4. Après avoir déssoudé la RAM de la carte et avoir branché ses pins sur la Raspberry comme décrit dans le tableau suivant, nous avons récupérer le fichier backup.bin qui contient les données de la mémoire flash.
 
{| class="wikitable"
Une fois démonté, on peut voir différents composants électronique :  
|+
 
!Pin de la mémoire
* le microcontrôleur (ARM de chez Atmel)
!Nom du pin
!Pin de la Raspberry
!Nom du pin
|-
|4
|GND
|39
|Ground
|-
|1
|/CS
|24
|GPIO 8
|-
|6
|CLK
|23
|SCLK
|-
|2
|DO
|21
|MISO
|-
|5
|DI
|19
|MOSI
|-
|8
|VCC
|1
|3V3 power
|-
|7
|/HOLD
|7
|GPIO 4
|-
|3
|/WP
|3
|GPIO 2
|}
La commande que nous avons utilisée est<syntaxhighlight lang="bash">
flashrom -p linux_spi:dev=/dev/spidev0.0 -r backup.bin
</syntaxhighlight>
[[Fichier:Screenshot from 2024-10-21 17-03-25.png|vignette|Commande de flashrom|centré]]


Nous avons réussi à obtenir un fichier "backup.bin". Mais malheureusement, les données récupérées ne sont pas exploitable.
=== Lampes connectées ===
La finalité de ce module est de contrôler de façon malfaisante les lampes connectées par le biais du réseau WiFi mis en place précédemment.


==== Fonctionnement ====
Ces lampes, de la marque Nedis, sont contrôlables à distance par WiFi depuis l'application mobile Nedis Smart Life.


On peut également déchiffrer la référence du microcontrôleur : AT91SAM7S256 (dont la datasheet, sur laquelle nous nous sommes basés, est disponible [https://www.keil.com/dd/docs/datashts/atmel/at91sam7s256_ds.pdf ici]).
==== Hacking ====
Après démontage d'une des trois lamps, on remarque qu'elles sont constituées de deux cartes reliés par un connecteur 2x4 :


Pour reprogrammer le firmware, nous avons :  
* la carte qui gère l'éclairage constituée de 8 LEDs dite "cold" (éclairage froid, tah l'hiver) et 8 LEDs dites "warm" (éclairage chaud, ambiance tamisée) avec son driver
* la carte qui gère l'alimentation (et sûrement le WiFi et son antenne) avec sa puce BK7231N
<gallery widths="360" heights="360">
Fichier:Alim.jpg|Carte d'alimentation
Fichier:Eclairage.jpg|Carte d'éclairage
</gallery>


* démonté la pile pour alimenter nous même la carte ;
===== Test n°1 : Mot de passe WiFi =====
* câblé les entrées/sorties du microcontrôleur nécessaire à sa programmation (SWDIO, SWCLK, NRST et UART (UTXD et URXD) sur les pads suivants
La lampe se connectant au téléphone et à l'application par WiFi exige, lors de la première connexion, d'entrer en clair le mot de passe du susdit réseau. Nous allons donc objectiver de récupérer ce rempart électronique qu'est le mot de passe, qui sera sûrement stockée quelque part dans la mémoire de la lampe, avec ou sans chiffrement, nous le découvrirons bientôt...


[[Fichier:Procesor temptale4usb simon louis.jpg|gauche|vignette|Emplacement des pads SWCLK et SWDIO]]
Pour ce faire, nous allons utiliser l'application ''BK7231 Uart flasher'' (recommandé sur [https://www.elektroda.com/rtvforum/topic3951016.html ce forum], accessible dans [https://github.com/openshwprojects/BK7231GUIFlashTool ce git]) nous permettra de récupérer une backup du software de notre carte BK7231N dans lequel réside sûrement le mot de passe. Pour ce faire, nous récupérons les pads VCC, GND, RX1, TX1 pour assurer la liaison UART. Il est également nécessaire de court circuiter le pad CEN avec le GND pendant 1/4 de seconde comme expliqué dans notre source (soudure d'un bouton). C'est un succès : on récupère un fichier .bin suivant :  que nous pouvons désormais exploiter !
[[Fichier:Uart temptale4usb simonlouis.jpg|vignette|Emplacement des pads UTXD et URXD]]
[[Fichier:Reset temptale4usb simon louis2.jpg|vignette|Emplacement du pad NRST|centré]]


En exploitant les données, nous avons réussi à trouver le SSID et le mot de passe en clair !!!


=== Lampes connectées ===
Dans notre cas, nous connaissions le SSID ainsi que le mot de passe, ce n'est pas très intéressant mais nous allons chercher si le SSID ainsi que le mot de passe sont stockés à des endroits fixes dans la memoire.

Version actuelle datée du 22 octobre 2024 à 14:32

Infrastructure WiFi

VM SE5-cruchet-deryckere : 172.26.145.102

Connexion au point d'accès ap_SE5 : ssh -l admin -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 -o HostKeyAlgorithms=ssh-rsa -c aes128-cbc,3des-cbc,aes192-cbc 172.26.145.1

Nous avons finis la configuration WIFI avec le WPA2-EAP (VM_binome_2). Notre Vlan est le VLAN402 et notre bridge sur capbreton est bridgeSL.

Lots d'identifiants pour notre accès WiFi
Identifiant Mot de passe
simon simon!
louis louis!
pifou pasglop

Cassage des objets connectés

Enregistreur de données de température TEMPTALE 4 USB

En E304 (sur les Zabeth 02, 03 et 04), l'objet n'a pas été reconnu, mais il l'a été sur Zabeth 15.

Nous aimerions pouvoir récupérer le firmware et le modifier pour "HACKER" l'objet.

Pour accéder aux fichiers de l'objet, il suffit de le connecter et d'attendre quelques secondes. Par la suite on peut le monter avec la commande suivante :

sudo mount /dev/sdb /dossier_au_choix

Une fois monté, on peut avoir accès aux fichiers générés. Il est possible de mettre un fichier dans l'objet, montrant une première vulnérabilité.

Nous avons également démonté l'objet pour voir sa carte, sur laquelle on peut voir différents composants électronique :

  • le microcontrôleur (ARM de chez Atmel)
  • une mémoire flash SPI
  • l'écran (non soudé, seulement maintenu mécaniquement) et son driver

On peut également déchiffrer la référence du microcontrôleur : AT91SAM7S256 (dont la datasheet, sur laquelle nous nous sommes basés, est disponible ici).

Pour reprogrammer le firmware, nous avons :

  • démonté la pile pour alimenter nous même la carte ;
  • câblé les entrées/sorties de la flash pour récupérer ses informations via la Raspberry PI 4 ;
  • câblé les entrées/sorties du microcontrôleur nécessaire à sa programmation (SWDIO, SWCLK, NRST et UART (UTXD et URXD) sur les pads suivants.

Malheureusement, il n'existe pas d'utilitaire STM32 pour lire la mémoire flash de cette carte. Nous utiliserons donc le software flashrom de la Raspberry PI 4. Après avoir déssoudé la RAM de la carte et avoir branché ses pins sur la Raspberry comme décrit dans le tableau suivant, nous avons récupérer le fichier backup.bin qui contient les données de la mémoire flash.

Pin de la mémoire Nom du pin Pin de la Raspberry Nom du pin
4 GND 39 Ground
1 /CS 24 GPIO 8
6 CLK 23 SCLK
2 DO 21 MISO
5 DI 19 MOSI
8 VCC 1 3V3 power
7 /HOLD 7 GPIO 4
3 /WP 3 GPIO 2

La commande que nous avons utilisée est

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

Nous avons réussi à obtenir un fichier "backup.bin". Mais malheureusement, les données récupérées ne sont pas exploitable.

Lampes connectées

La finalité de ce module est de contrôler de façon malfaisante les lampes connectées par le biais du réseau WiFi mis en place précédemment.

Fonctionnement

Ces lampes, de la marque Nedis, sont contrôlables à distance par WiFi depuis l'application mobile Nedis Smart Life.

Hacking

Après démontage d'une des trois lamps, on remarque qu'elles sont constituées de deux cartes reliés par un connecteur 2x4 :

  • la carte qui gère l'éclairage constituée de 8 LEDs dite "cold" (éclairage froid, tah l'hiver) et 8 LEDs dites "warm" (éclairage chaud, ambiance tamisée) avec son driver
  • la carte qui gère l'alimentation (et sûrement le WiFi et son antenne) avec sa puce BK7231N
Test n°1 : Mot de passe WiFi

La lampe se connectant au téléphone et à l'application par WiFi exige, lors de la première connexion, d'entrer en clair le mot de passe du susdit réseau. Nous allons donc objectiver de récupérer ce rempart électronique qu'est le mot de passe, qui sera sûrement stockée quelque part dans la mémoire de la lampe, avec ou sans chiffrement, nous le découvrirons bientôt...

Pour ce faire, nous allons utiliser l'application BK7231 Uart flasher (recommandé sur ce forum, accessible dans ce git) nous permettra de récupérer une backup du software de notre carte BK7231N dans lequel réside sûrement le mot de passe. Pour ce faire, nous récupérons les pads VCC, GND, RX1, TX1 pour assurer la liaison UART. Il est également nécessaire de court circuiter le pad CEN avec le GND pendant 1/4 de seconde comme expliqué dans notre source (soudure d'un bouton). C'est un succès : on récupère un fichier .bin suivant : que nous pouvons désormais exploiter !

En exploitant les données, nous avons réussi à trouver le SSID et le mot de passe en clair !!!

Dans notre cas, nous connaissions le SSID ainsi que le mot de passe, ce n'est pas très intéressant mais nous allons chercher si le SSID ainsi que le mot de passe sont stockés à des endroits fixes dans la memoire.