SE5 IdO sécurité des objets 2025/2026 b2

🌐 TP Infrastructure Réseau 🛜

Introduction

Ce wiki documente la mise en place d’une petite infrastructure réseau pédagogique pour le TP 2025/2026.

L’objectif est de déployer un serveur virtuel sur capbreton, d’y terminer un VLAN privé (ici 409 car je suis a la Zabeth 09), puis d’implanter les services exigés : DHCP, DNS (forwarder + zone locale d’interception), NAT/mascarade, et redirection réseau pour l’HTTP.

Des choix techniques sont explicités à chaque étape (pourquoi tel fichier, telle option, tel service), afin d’argumenter les décisions et permettre la reproductibilité.

Serveur virtuel (17/09)

La VM est créée sur Xen depuis capbreton avec une unique interface reliée à bridgeStudents, conformément au sujet (routage par 172.26.145.251 côté salles projets).

xen-create-image \
  --hostname=SE5.kelbachi \
  --dhcp \
  --bridge=bridgeStudents \
  --dir=/usr/local/xen \
  --size=10GB \
  --dist=daedalus \
  --memory=2G \
  --force

Pourquoi cette commande ?

--bridge=bridgeStudents impose l’unique attachement réseau demandé ; --dist=daedalus assure une base Devuan stable (ifupdown classique) ; les ressources (2 Gio RAM/10 Gio disque) suffisent pour DHCP/DNS/NAT.

Démarrage et accès console :

xl create -c /etc/xen/SE5.kelbachi.cfg
# Ctrl+] pour détacher la console sans éteindre

Adresse routée (réseau des salles projets)

Configuration statique avec passerelle 172.26.145.251. On choisit une IP libre dans la plage fournie (exemple 172.26.145.109/24).

# /etc/network/interfaces (extrait)
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 172.26.145.109/24
    gateway 172.26.145.251
    dns-nameservers 1.1.1.1 8.8.8.8

Pourquoi une IP statique ?

Le sujet exige un adressage maîtrisé côté salles projets et une route par défaut vers le routeur NAT de la salle. C’est la base pour que la VM accède à Internet et puisse, ensuite, NATer les clients WiFi.

Interface privée (VLAN 409)

Le réseau privé associé à X=09 est 172.16.9.0/24. La VM termine ce VLAN avec l’adresse 172.16.9.1/24 (gateway & DNS pour les clients). Dans notre mise en place, l’interface privée est eth1.

# /etc/network/interfaces (complément)
auto eth1
iface eth1 inet static
    address 172.16.9.1/24

Vérifications :

ip a
ip r
ping -c3 172.26.145.251
ping -c3 8.8.8.8

Point d’accès Cisco – SSID WPA2-PSK (29/09)

Connexion console série (9600 8N1, sans control flow) avec Minicom. Après habilitation, création d’un SSID attaché au VLAN 409.

dot11 ssid SE5-SSID09
  vlan 409
  authentication open
  authentication key-management wpa version 2
  wpa-psk ascii Cisco2025
  exit

interface dot11radio 0
  encryption mode ciphers aes-ccm
  ssid SE5-SSID09
  station-role root
  no shutdown

Nous laissons de cote cette partie car elle n'est pas bloquante pour la suite du TP.

Serveur DHCP (29/09)

Distribution automatisée d’adresses 172.16.9.100–200 aux clients du VLAN 409, avec routeur et DNS pointant vers la VM.

Installation :

apt-get update
apt-get install -y isc-dhcp-server

Configuration :

# /etc/dhcp/dhcpd.conf
default-lease-time 600;
max-lease-time 7200;
authoritative;

subnet 172.16.9.0 netmask 255.255.255.0 {
  range 172.16.9.100 172.16.9.200;
  option routers 172.16.9.1;
  option domain-name-servers 172.16.9.1;
}

Mascarade (NAT) – Accès Internet (29/09)

Activation du routage IPv4 et NAT du réseau 172.16.9.0/24 vers eth0.

sysctl -w net.ipv4.ip_forward=1
sed -i 's/^#\?net\.ipv4\.ip_forward.*/net.ipv4.ip_forward=1/' /etc/sysctl.conf

iptables -t nat -F
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE

iptables -t nat -L -n -v

Pourquoi la mascarade ?

Les clients WiFi utilisent des adresses privées. Le NAT traduit leurs paquets pour qu’ils sortent avec l’IP de la VM côté salles projets.

Sans NAT, pas d’Internet pour le VLAN 409.

Persistance :

apt-get install -y iptables-persistent
netfilter-persistent save

Interception de flux (04/10)

Redirection par DNS (zone locale)

On implémente une zone primaire sur la VM pour rediriger picoctf.org et tous ses sous-domaines vers la VM. Service BIND sous Devuan : nom de service systemd = named.

Déclaration :

# /etc/bind/named.conf.local
zone "picoctf.org" {
    type master;
    file "/etc/bind/db.picoctf.org";
};

Zone :

$TTL  200
@  IN SOA ns.picoctf.org. admin.picoctf.org. (
    2025100403 ; Serial
    3600       ; Refresh
    1800       ; Retry
    604800     ; Expire
    86400 )    ; Minimum

        IN NS  ns.picoctf.org.
ns      IN A   172.16.9.1
@       IN A   172.16.9.1
www     IN CNAME ns

Options (écoute VLAN) :

# /etc/bind/named.conf.options (extrait)
options {
  directory "/var/cache/bind";
  recursion yes;
  allow-query { 172.16.9.0/24; 127.0.0.1; };
  forwarders { 1.1.1.1; 8.8.8.8; };
  listen-on { 172.16.9.1; 127.0.0.1; };
  dnssec-validation auto;
};

Service & vérifs :

systemctl enable named
systemctl restart named
named-checkconf
named-checkzone picoctf.org /etc/bind/db.picoctf.org
dig @127.0.0.1 picoctf.org +short
dig @127.0.0.1 www.picoctf.org +short
dig @127.0.0.1 test.picoctf.org +short   # wildcard

Redirection réseau

Mise en place d’une REDIRECT pour capter le HTTP et le diriger vers un service local.

# Table nat propre
iptables -t nat -F

# Interception HTTP
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 8080

# NAT format TP (409)
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.9.0/24 -j MASQUERADE

iptables -t nat -L -n -v

Serveur Apache sécurisé (08/10)

Dans cette partie, l’objectif est de mettre en place un serveur web sécurisé en HTTPS avec un certificat signé par une autorité locale. J'utilise ici le domaine d’exemple picoctf.org, déjà intercepté par notre DNS.

1. Création d’un certificat auto-signé

Avant toute chose, je génère un certificat auto-signé permettant à Apache de servir du HTTPS localement.

openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout /etc/ssl/apache/apache-selfsigned.key \
  -out /etc/ssl/apache/apache-selfsigned.crt \
  -subj "/C=FR/ST=Nord/L=Lille/O=Polytech/CN=picoctf.org"

2. Configuration d’Apache2

Je crée un nouveau fichier de configuration HTTPS dans /etc/apache2/sites-available/secure-site.conf.

<VirtualHost *:443>
    ServerName picoctf
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/apache2/sites-available/apache.crt
    SSLCertificateKeyFile /etc/apache2/sites-available/apache.key

    # Logs SSL
    ErrorLog ${APACHE_LOG_DIR}/ssl-error.log
    CustomLog ${APACHE_LOG_DIR}/ssl-access.log combined
</VirtualHost>

# HTTP vers HTTPS
<VirtualHost *:80>
    ServerName picoctf.org
    Redirect permanent / https://picoctf.org/
</VirtualHost>

Cette configuration active le service sur le port 443 et redirige automatiquement les connexions HTTP vers HTTPS.

3. Création d’une autorité de certification locale

Afin de simuler un certificat signé par une autorité de confiance, je crée une CA interne appelée "Certif".

openssl req -x509 -new -nodes \
  -keyout ca.key -sha256 -days 365 \
  -out ca.crt -subj "/CN=Certif"

4. Signature du certificat Apache avec l’autorité locale

Je commence par créer une demande de signature (CSR) pour le serveur Apache :

openssl req -new -newkey rsa:2048 -nodes \
  -keyout apache.key -out apache.csr \
  -subj "/CN=picoctf.org"

Puis je signe cette requête avec notre autorité Certif :

openssl x509 -req -in apache.csr \
  -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out apache.crt -days 365 -sha256

Je remplace ensuite dans la configuration Apache les fichiers de certificat auto-signés par ceux nouvellement générés :
- /etc/apache2/sites-available/apache.crt
- /etc/apache2/sites-available/apache.key

Redémarrage du service :

a2enmod ssl
a2ensite secure-site.conf
systemctl reload apache2

Machine virtuelle Android

Lorsque je tente d’accéder à https://picoctf.org depuis un appareil Android récent, le certificat de l’autorité “Certif” n’est pas reconnu.

Pour contourner cela, il est possible d’installer une ancienne machine Android (par exemple sous Android 4.x), où l’ajout manuel d’une autorité de certification est encore possible.

Sur cette Android, après quelques ajustements réseau, il est possible d’importer le certificat racine Certif et ainsi naviguer vers le faux site picoctf.org.

Appareil Android physique (08/10)

Enfin, le même test a été reproduit sur la tablette Android 4.4 de mon camarade, une version qui permet encore l’ajout d’autorités de certification manuellement.

En important le fichier `ca.crt` dans les paramètres de sécurité, le site `https://picoctf.org` devient totalement “sécurisé” : le navigateur affiche le cadenas vert , confirmant que la connexion est chiffrée et que le certificat est reconnu par le système.

Problèmes rencontrés

• Console Cisco muette : causée par le flow control. Solution : désactiver hardware & software flow control dans minicom (9600, 8N1, /dev/ttyUSB0).
• Erreur AP cipher not configured : corriger en posant `authentication ... version 2` côté SSID et encryption mode ciphers aes-ccm côté radio.

Partie 2 : Casse d'objets connectés (IoT)

Dans cette seconde partie, l'objectif est d'analyser le fonctionnement d'un objet connecté : une **alarme incendie Wi-Fi**. Pour comprendre comment elle communique avec le cloud et potentiellement intercepter ses messages, nous avons besoin d'analyser l'application mobile de contrôle (Nedis SmartLife / Tuya).

Deux approches sont envisagées : une approche **logicielle** (émulation Android pour interception HTTPS) et une approche **matérielle** (analyse électronique).

1. Approche Logicielle : La quête de l'émulation

L'objectif est de faire tourner l'application IoT dans un environnement contrôlé (VM Android) où nous pouvons devenir **root** et installer notre certificat CA (créé précédemment) pour déchiffrer le trafic HTTPS (Man-in-the-Middle).

Tentative 1 : Android-x86 (Android 6.0 Marshmallow)

Nous avons d'abord créé une VM sur l'hyperviseur avec une image ISO Android-x86. Pour connecter cette VM à notre infrastructure (et donc à Internet via notre passerelle NAT), nous avons dû adapter la configuration réseau pour qu'elle s'attache au pont `bridgeStudents` et récupère une IP via notre serveur DHCP.

# Configuration Xen (extrait)
vif = [ 'mac=00:16:3E:XX:XX:XX, bridge=bridgeStudents' ]

Observation

L'installation se déroule bien, le Play Store est accessible. L'application de l'alarme se télécharge, s'installe, mais **ne s'ouvre pas** (crash immédiat au lancement). Même constat avec des versions plus récentes d'Android-x86.

Analyse du problème (Architecture CPU)

Pour comprendre l'échec, nous avons extrait l'APK de l'application et l'avons analysé comme une archive ZIP pour inspecter ses bibliothèques natives.

mv app.apk app.zip
unzip app.zip -d app_content
ls -R app_content/lib/

Résultat

Le dossier `lib/` ne contient que des sous-dossiers `armeabi-v7a` et `arm64-v8a`. Il n'y a pas de bibliothèques `x86`.

**Conclusion** : L'application contient du code natif compilé uniquement pour les processeurs ARM. Elle ne peut pas s'exécuter sur une VM x86 standard sans un traducteur binaire (type libhoudini) qui n'était pas fonctionnel ici.

Tentative 2 : Émulation QEMU ARM

Sur conseil des enseignants, nous avons tenté d'utiliser une image QEMU émulant une architecture ARM (Android 4.4).

sudo apt install qemu-system-arm
# Lancement de l'image fournie

Échec

Si l'architecture est la bonne (ARM), la version d'Android (4.4 KitKat) est trop ancienne. L'application exige une version minimale du SDK Android (souvent Android 6 ou 7 minimum) et refuse de s'installer.

Tentative 3 : Android Studio (La solution lourde)

Nous nous sommes tournés vers **Android Studio** installé sur les machines de l'école pour bénéficier d'émulateurs plus récents et configurables.

Installation et correctifs d'environnement : Les machines de TP nécessitent des droits spécifiques et des ajustements de variables d'environnement pour que l'émulateur (AVD) fonctionne.

# Installation locale
sudo mv ~/Downloads/android-studio ~/
sudo chown -R kelbachi ~/android-studio

# Fix : L'émulateur ne trouvait pas les AVD créés via l'interface graphique
find ~ -name "*.avd"
# Résultat trouvé dans ~/.config/.android/avd
export ANDROID_AVD_HOME=~/.config/.android/avd

# Démarrage manuel de l'émulateur (Pixel 6 Pro)
~/Android/Sdk/emulator/emulator -avd Pixel_6_Pro_2

Tentative de Root et Injection du Certificat : Pour intercepter le trafic, nous devons installer le certificat CA généré sur notre serveur Apache dans le magasin système d'Android. Sur les versions récentes d'Android (10+), cela nécessite d'être root et de remonter la partition système en écriture.

1. **Préparation du certificat (Hashage)** Android attend un nom de fichier basé sur le hash du certificat.

openssl x509 -inform PEM -subject_hash_old -in ca.crt
# Output: 9de4c2c8
cp ca.crt 9de4c2c8.0

2. **Connexion ADB et tentative de Root**

adb devices        # OK
adb root           # Redémarre adbd en root
adb shell whoami   # Retourne: root
adb remount        # Tente de remonter /system en écriture (RW)

3. **Le Mur du "Read-only file system"** Malgré le `adb root`, l'écriture dans `/system/etc/security/cacerts/` a échoué.

adb push 9de4c2c8.0 /sdcard/Download/
adb shell
mv /sdcard/Download/9de4c2c8.0 /system/etc/security/cacerts/
# Erreur : Read-only file system

Explication technique

Sur les images "Google Play" (production) ou les images Android récentes (Android 10+), la partition système est protégée par **dm-verity** (Verified Boot) et montée via **overlayfs**. Même en root, il est impossible de la modifier de façon persistante sans lancer l'émulateur avec l'option `-writable-system` dès le premier démarrage (cold boot), ce qui n'était pas possible dans notre configuration figée.

Conclusion de l'approche logicielle : L'impossibilité d'injecter le certificat CA au niveau système sur une version récente d'Android nous empêche de casser le chiffrement SSL de l'application via cette méthode simple. Nous pivotons donc vers l'approche matérielle.

2. Approche Matérielle (Hardware Hacking)

(À compléter - Analyse du circuit imprimé, port série, etc.)