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

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.

<mettre screen>

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

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

<mettre screen>

Balance

Objectif du Projet:

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.

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 ou altération des données pendant les échanges.

Observation Architecture Cloud:

Nous avons découvert 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.

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 répéteur CPL.

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

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

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.

(Schéma réseau avec VLANs et captures de configuration)

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

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.

- Repérer l'extension apk de l'application Nedis pour faire du reverse.