SE5 IdO sécurité des objets 2024/2025 b4

Wi-Fi

Création du serveur virtuel

- Création d'un serveur virtuel sur capbreton : SE5-yelqasta-ybenmbar - Interface réseau dans le commutateur virtuel bridgeStudents avec :

  * Adresse IPv4 : 172.26.145.104
  * Passerelle : 172.26.145.251

- Interface réseau dans le VLAN 404 :

  * Adresse IPv4 : 172.16.4.1
  * Masque : /24 (255.255.255.0)
  * VLAN : 404

Configuration du point d'accès WiFi Cisco

- Définition du SSID VM_binome_4 :

   dot11 ssid VM_binome_4
     vlan 404
     authentication open eap eap_binome_4
     authentication network-eap eap_binome_4
     authentication key-management wpa
     mbssid guest-mode

- Configuration du VLAN 404 sur l'interface radio et l'interface Ethernet :

   interface Dot11Radio0.404
     encapsulation dot1Q 404
     bridge-group 4

   interface GigabitEthernet0.404
     encapsulation dot1Q 404
     bridge-group 4

- Configuration de l'accès au serveur FreeRADIUS :

   aaa new-model
   aaa authentication login eap_binome_4 group radius_binome_4
   radius-server host 172.16.4.1 auth-port 1812 acct-port 1813 key glopglop
   aaa group server radius radius_binome_4
     server 172.16.4.1 auth-port 1812 acct-port 1813

Configuration du serveur FreeRADIUS

- Installation de FreeRADIUS sur le serveur virtuel :

   sudo apt update
   sudo apt install freeradius freeradius-utils

- Ajout de l'adresse IP du point d'accès Cisco dans le fichier de clients FreeRADIUS :

• Dans le fichier /etc/freeradius/3.0/clients.conf :

   client wifi_ap {
       ipaddr = 172.26.145.4
       secret = glopglop
       shortname = wifi_ap_binome_4
   }

- Configuration d'un utilisateur pour l'authentification WPA2-EAP :

• Dans le fichier /etc/freeradius/3.0/users :

   mouss Cleartext-Password := "glopglop"

- Activation de PEAP-MSCHAPv2 :

• Dans le fichier /etc/freeradius/3.0/mods-enabled/eap :

   peap {
       default_eap_type = mschapv2
   }

Serveur DHCP

- On a installé un serveur DHCP sur le serveur virtuel :

   sudo apt install isc-dhcp-server

- Configuration du serveur DHCP :

  * Dans le fichier /etc/dhcp/dhcpd.conf :

   subnet 172.16.4.0 netmask 255.255.255.0 {
       range 172.16.4.100 172.16.4.200;
       option routers 172.16.4.104;
       option domain-name-servers 255.255.255.0;
   }

- Dans le fichier /etc/default/isc-dhcp-server :

   INTERFACESv4="eth1"

Serveur DNS minimal

• Dans /etc/bind/named.conf.options

   ...
   forwarders { 
   		172.26.188.12;
   };
   ...

Mascarade entre VLAN privé et routeur

- Activation du transfert IP sur le serveur virtuel :

   systemctl -w net.ipv4.ip_forward=1

- Ajout d'une règle de masquerade avec iptables :

   iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Passage de WPA-EAP à WPA-PSK

Afin d'utiliser notre balance connectée, nous devons mettre en place un point d'accès avec WPA-PSK et non WPA-EAP.

• Dans le point d'accès Cisco :

no autentication open eap eap_binome_4
no authentication network-eap eap_binome_4
wpa-psk ascii [mdp]

Temptale USB

Identification des différentes puces

Temptale ouvert

µC : Atmel AT91SAM7S256

Puce mémoire : Winbond 25X40CLNIG

SN74CBTLV3126 : commutateur de bus FET quadripolaire, probablement utilisé comme convertisseur de niveau

Modification du fichier pdf

Nous avons d'abord pensé à passer par le système de fichiers et plus précisément le fichier pdf pour hacker le Temptale.

Mémoire

Afin d'extraire le firmware, nous avons soudé des fils sur chaque broche de la puce mémoire. Elle fonctionne en SPI, nous l'avons alors connectée à la Raspberry Pi sur les broches correspondantes (SCK,MISO,MOSI,SS). Grâce à l'utilitaire flashrom, nous pouvons depuis la Raspberry Pi extraire le firmware de la carte.

Schéma de la puce mémoire

Nous l'avons connecté de cette façon :

RPi	Winbond 25X40CLNIG
CE0	CS
MOSI	DI
MISO	DO
SCK	CLK
3,3V	VCC
GND	GND

Fils soudés sur les broches de la puce mémoire

flashrom -p linux_spi:dev=/dev/spidev0.0

Mais nous avons cette erreur :

No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

Nous avons tenté de lancer le programme en lui spécifiant le modèle :

flashrom -p linux_spi:dev=/dev/spidev0.0 --chip W25X40

Mais sans succès, nous suspectons un problème dans la soudure.

Balance

Objectif du TP:

Nous devons analyser et compromettre la sécurité d'une balance connectée fournie par Nedis. Pour cela, nous avons installé l'application mobile associée, Nedis SmartLife, qui permet d'interagir avec la balance. Nedis SmartLife

Balance WiFi Nedis

Problème réseau initial:

Lors des premières configurations, nous avons découvert que notre réseau Wi-Fi configuré en WPA EAP n’était pas compatible avec les exigences de la balance. Cette dernière nécessite une configuration en WPA PSK pour fonctionner correctement.

Malgré cette adaptation, nous avons rencontré des difficultés pour connecter nos téléphones à la balance. À la fin de l’appairage, la balance se déconnectait systématiquement avec le message d’erreur "Err2". D’après nos recherches, cette erreur est liée à un problème de réseau. Bien que la balance apparaisse dans l’application, elle n’envoie aucune donnée dans des conditions d’utilisation normale.

interface de l'application

Erreur de connexion réseau

Diagnostic initial:

Pour identifier la source du problème, nous avons vérifié la communication entre les trois entités principales du système : le téléphone, la balance, et le point d’accès Wi-Fi. Nous avons utilisé le Wi-Fi préalablement configuré lors des séances précédentes et effectué des tests de connectivité :

Ping vers le téléphone : Réussi

Ping vers la balance : Réussi

Ces résultats montrent que les appareils sont correctement connectés au réseau, ce qui écarte l’hypothèse d’un problème de connexion simple. Cependant, cela laisse supposer une potentielle perte des données pendant les échanges.

Analyse avancée avec Wireshark:

Pour approfondir le diagnostic, notre professeur nous a suggéré de mettre en place une analyse de trafic réseau en utilisant :

• Un injecteur PoE
• Le point d'accès PLIL
• Un commutateur réseau configuré pour effectuer un port mirroring.
• Wireshark en mode promiscuous pour capturer les paquets circulant dans le réseau.

Commande pour la configuration du port mirroring :

Switch(config)#monitor source interface fa 0/1 both

Schéma du réseau

Grâce à cette configuration, nous avons pu observer que la balance établit bien une connexion avec un serveur cloud spécifique. Cependant, les données échangées restent inintelligibles, ce qui rend le problème difficile à cerner.

Observation architecture cloud:

La balance qui prend l'adresse ip 172.26.145.206

La balance est identifiable dans les trames capturées par son adresse MAC : Express:16:2d:4c. Cette adresse MAC apparaît principalement dans des paquets ARP, confirmant que la balance effectue des requêtes pour résoudre des adresses IP ou répondre aux requêtes des autres équipements du réseau. Nous remarquons que les paquets montrent une tentative de négociation TLS entre la balance et un serveur cloud.

le serveur cloud

Le serveur cloud

Ce qui signifie que la communication entre la balance et l’application ne se fait pas directement via le routeur local. Au lieu de cela, les données transitent par un serveur cloud distant. Cette architecture ajoute une couche d’abstraction qui complique le diagnostic.

le handshake entre le téléphone ayant l'ip 172.26.145.211 et le serveur

transfert des paquets par chiffrement TLS

Bien que la balance semble bien résoudre les adresses et tenter d'établir une connexion avec le cloud, le message TCP RST indique probablement que l'une des deux parties rejette la connexion.

l'interruption de le communication TCP

Approche MITM (Man-in-the-Middle):

Un rejet du certificat présenté par le serveur peut être la cause de l'échec de la communication, donc pour mieux comprendre et intercepter les données, une approche MITM (Man-in-the-Middle) a été proposée. L’objectif est de configurer un serveur local qui imiterait le serveur cloud en utilisant un certificat TLS falsifié, permettant ainsi de capturer et d’analyser les communications chiffrées entre la balance et le serveur.

Avec l’équipe 5, nous avons configuré le réseau suivant:

VLAN 200: Réseau dédié à la balance, configuré pour se connecter à l’adresse 17.188.185.132 sur le port 5223.

VLAN 50: Réseau pour la machine locale à l’adresse 172.26.145.231, qui hébergera notre serveur MITM.

Le serveur est conçu pour générer et présenter un certificat TLS falsifié afin de se faire passer pour le serveur cloud légitime auprès de la balance.

import socket
import ssl

# Chemins vers les certificats falsifiés
CERT_FILE = "fake_cert.pem"
KEY_FILE = "fake_key.pem"

# Création du socket serveur
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(('0.0.0.0', 8443))  # Écoute sur le port 8443
server_socket.listen(5)

# Ajout de la couche TLS/SSL
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile=CERT_FILE, keyfile=KEY_FILE)

print("Serveur en attente de connexions...")

while True:
    client_socket, addr = server_socket.accept()
    print(f"Connexion acceptée de : {addr}")
    try:
        secure_socket = ssl_context.wrap_socket(client_socket, server_side=True)
        print("TLS établi avec le client.")
        
        # Communication avec le client
        data = secure_socket.recv(1024)
        print(f"Données reçues : {data.decode()}")
        
        # Réponse du serveur
        secure_socket.sendall(b"HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\nFake Cloud Response")
    except Exception as e:
        print(f"Erreur TLS : {e}")
    finally:
        if 'secure_socket' in locals():
            secure_socket.close()

Génération des certificats falisifiés :

openssl req -new -x509 -key fake_key.pem -out fake_cert.pem -days 365 -subj "/C=FR/ST=Lille/L=Lille/O=Fake Cloud/OU=Dev/CN=localhost"
openssl genrsa -out fake_key.pem 2048

Redirection de l'adresse de destination vers le serveur TCP :

sudo iptables -t nat -A PREROUTING -p tcp -d 3.121.210.75 --dport 443 -j DNAT --to-destination 127.0.0.1:8443

Conclusion et étapes suivantes :

Problème actuel :

Bien que la configuration MITM soit en place, nous devons encore analyser en détail les paquets chiffrés interceptés pour identifier la cause exacte de l’échec de communication.

Étape suivante ou éventuelle:

• Déployer des outils pour décrypter le trafic TLS intercepté et approfondir l’analyse des données échangées. (obsolète)
• Repérer l'extension apk de l'application Nedis pour faire du reverse.
• transformer la zabeth17 en un routeur pour pouvoir rediriger les paquets vers son adresse ip
• déssouder la puce mémoire de la carte pour la tester à part.