De nombreux utilisateurs estiment que l'activation d'un réseau privé virtuel garantit la protection intégrale de leurs données par la seule force des algorithmes. Les chiffrements récents tels que ChaCha20-Poly1305 et AES-256-GCM offrent une robustesse mathématique irréprochable face à l'interception physique. Cependant, les algorithmes cryptographiques ne choisissent jamais l'itinéraire emprunté par les paquets. Cette responsabilité incombe exclusivement à la table de routage du noyau de votre système d'exploitation.

En 2023, les chercheurs en sécurité Mathy Vanhoef, Nian Xue, Yashaswi Malla, Zihang Xiao et Cristina Nita-Rotaru ont révélé une faille structurelle majeure affectant la quasi-totalité des clients du marché : TunnelCrack. Documentée sous les références CVE-2023-36664 et CVE-2023-35838, cette vulnérabilité démontre comment un réseau local non fiable ou un point d'accès Wi-Fi hostile peut manipuler les règles de routage pour diriger les données ciblées en clair, en dehors du canal chiffré.

Comprendre la portée de TunnelCrack implique d'analyser en profondeur ses deux variantes d'attaque : l'attaque LocalNet et l'attaque ServerIP.

+-----------------------------------------------------------------------------+
|                     FLUX DE FUITE DE ROUTAGE LOCALNET                       |
|                                                                             |
|  [Appareil de l'utilisateur]                                                |
|         │                                                                   |
|         ├── Destination : IP publique cible (ex. 142.250.190.46)            |
|         │                                                                   |
|         ▼                                                                   |
|  [Décision de la table de routage du noyau]                                 |
|         │                                                                   |
|         ├─► Route A : Tunnel VPN par défaut (0.0.0.0/1 via utun0)           |
|         │                                                                   |
|         └─► Route B : Sous-réseau hostile LocalNet (142.250.0.0/16 wlan0)   |
|                    (Priorité de correspondance de préfixe la plus longue)   |
|                                                                             |
|         ▼                                                                   |
|  [Interface physique : wlan0] ──────────────► [Passerelle Wi-Fi hostile]    |
|  (Trames Ethernet en clair transmises hors tunnel) (Interception du trafic) |
+-----------------------------------------------------------------------------+

L'attaque LocalNet (CVE-2023-36664) : détournement des exceptions de réseau local

La vulnérabilité LocalNet exploite une fonctionnalité de confort très répandue : l'accès aux ressources du réseau local. À domicile ou au bureau, les utilisateurs souhaitent régulièrement utiliser des imprimantes réseau, des serveurs de stockage NAS ou des équipements multimédias tout en restant connectés à leur VPN. Pour répondre à cet usage, les systèmes d'exploitation maintiennent des routes directes de portée liaison pour le sous-réseau local.

Lors de la connexion à un réseau sans fil, le serveur DHCP transmet une configuration comprenant une adresse IP, un masque de sous-réseau et une passerelle. En temps normal, une plage privée conforme à la RFC 1918 est attribuée, comme 192.168.1.0/24. Le noyau installe automatiquement une entrée locale :

192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105

Avec l'attribut scope link, le noyau sait que les paquets à destination de 192.168.1.0/24 peuvent être acheminés directement via ARP sans passer par une passerelle externe. Pour préserver les fonctionnalités locales, le client VPN conserve cette route ou crée une règle d'exception dans ses tables de routage.

Un point d'accès hostile exploite cette mécanique en annonçant un bloc d'adresses IP publiques légitimes en tant que sous-réseau local. Le serveur DHCP falsifié peut ainsi assigner une adresse dans 142.250.0.0/16 avec un masque 255.255.0.0 :

# Le noyau configure une route directe pour une plage publique sur la carte Wi-Fi
142.250.0.0/16 dev wlan0 proto kernel scope link src 142.250.10.45

Lorsque l'utilisateur ouvre un navigateur vers un service situé dans cette plage d'adresses, le noyau consulte sa base d'informations de transfert (FIB). Selon les règles conventionnelles de routage IP :

  1. L'interface virtuelle installe généralement des routes par défaut scindées en deux moitiés (0.0.0.0/1 et 128.0.0.0/1).
  2. La route locale imposée par le point Wi-Fi présente un préfixe /16, nettement plus spécifique que le préfixe /1 du tunnel.
  3. En vertu du principe de correspondance de préfixe la plus longue (Longest Prefix Match), la route /16 l'emporte.

En conséquence, le noyau achemine directement le paquet non chiffré vers l'interface physique wlan0. Le tunnel chiffré est délaissé pour ces échanges, permettant à l'attaquant de capturer les requêtes HTTP et les données applicatives en clair.

L'attaque ServerIP (CVE-2023-35838) : détournement de l'amorçage de connexion

Tandis que LocalNet exploite les masques de sous-réseau, l'attaque ServerIP cible le mécanisme indispensable à l'initialisation de la liaison sécurisée.

Pour transmettre des paquets encapsulés à travers l'infrastructure internet vers un serveur distant, la carte réseau physique doit savoir comment joindre son adresse IP externe. Si l'application dirigeait l'intégralité du trafic sans exception dans l'interface virtuelle, les paquets encapsulés à destination du serveur seraient réinjectés dans le tunnel, créant une boucle infinie bloquant immédiatement la liaison.

Afin d'éviter ce blocage, les logiciels configurent une route d'hôte dédiée (/32 pour IPv4 ou /128 pour IPv6) vers la passerelle physique avant d'activer le tunnel :

# Route d'hôte directe vers le serveur via le routeur physique
198.51.100.50/32 via 192.168.1.1 dev wlan0

La vulnérabilité ServerIP survient lorsque le nom de domaine du serveur est résolu à l'aide de serveurs DNS non fiables fournis par le réseau local lors de l'établissement de la session :

  1. Lors de l'initialisation, le client émet une requête DNS pour résoudre l'hôte du service.
  2. Un résolveur DNS malveillant sur le réseau local renvoie l'adresse IP d'un service cible que l'attaquant souhaite observer (un portail d'entreprise ou une interface de programmation).
  3. Le client accepte cette réponse et configure une route d'hôte /32 dirigeant tout le trafic de cette IP vers l'interface wlan0.
  4. Bien que la négociation avec ce faux nœud échoue, la règle d'hôte reste inscrite dans le système, forçant les futures connexions vers ce service cible à s'effectuer hors du tunnel chiffré.

Même si le client exploite une adresse IP statique, un attaquant local peut empoisonner les réponses DNS d'autres domaines pour les faire coïncider avec l'IP du serveur, entraînant l'émission en clair des requêtes vers ces destinations.

+-----------------------------------------------------------------------------+
|                      COMPARAISON DES ATTAQUES LOCALNET ET SERVERIP          |
+------------------------+----------------------------------------------------+
| Type d'attaque         | Mécanisme principal d'exploitation                 |
+------------------------+----------------------------------------------------+
| LocalNet               | Masque étendu sur IP publiques via faux DHCP       |
| (CVE-2023-36664)       | Priorité du préfixe supplantant les routes /1      |
|                        | Exploitation de l'accès aux imprimantes locales    |
+------------------------+----------------------------------------------------+
| ServerIP               | Réponse DNS falsifiée durant l'initialisation      |
| (CVE-2023-35838)       | Route d'hôte /32 envoyant les données à découvert  |
|                        | Exploitation de la prévention des boucles          |
+------------------------+----------------------------------------------------+

TunnelCrack et TunnelVision : distinguer les vecteurs d'attaque

Il est essentiel de distinguer TunnelCrack de l'attaque TunnelVision (CVE-2024-3661). Si les deux techniques exploitent les mécanismes de décision de routage, leurs leviers diffèrent sensiblement :

  • TunnelVision dépend exclusivement de l'option DHCP 121 (RFC 3442, options de routes statiques sans classe) pour insérer des chemins spécifiques. Les systèmes d'exploitation ignorant cette option par défaut, comme Android, sont naturellement préservés de cette faille.
  • TunnelCrack n'exige aucun paramètre DHCP facultatif. La déclinaison LocalNet s'appuie sur le champ de masque de sous-réseau présent dans la RFC 2132 depuis 1997. Tout équipement réseau devant impérativement traiter les masques, TunnelCrack a touché l'ensemble des plateformes : iOS, macOS, Windows, Linux et Android.

Le noyau applique les priorités d'acheminement selon la spécificité des masques sans considération d'ordre cryptographique. Dès qu'une route physique présente un préfixe plus ciblé, les données sont transmises directement sur le réseau local.

Hiérarchie des priorités de routage dans le noyau :
┌────────────────────────────────────────────────────────┐
│  Route d'hôte (/32) : Cible précise (ServerIP)         │  ◄── Priorité maximale
├────────────────────────────────────────────────────────┤
│  Route locale (/16, /24) : Sous-réseau (LocalNet)      │  ◄── Suppante le tunnel
├────────────────────────────────────────────────────────┤
│  Route scindée du tunnel (/1) : 0.0.0.0/1              │  ◄── Tunnel standard
├────────────────────────────────────────────────────────┤
│  Passerelle par défaut (/0) : 0.0.0.0/0                │  ◄── Priorité minimale
└────────────────────────────────────────────────────────┘

Réponses architecturales : comment assainir le routage réseau

Neutraliser définitivement la menace TunnelCrack impose de dépasser la simple écriture de tables de routage. Les architectures modernes adoptent une défense en profondeur conjuguant pare-feu de noyau, espaces de noms réseau et liaison stricte de sockets.

1. Pare-feu de noyau et arrêt d'urgence du trafic

Un mécanisme d'arrêt d'urgence (Kill Switch) performant ne doit pas se reposer uniquement sur les métriques de routage. Il requiert des règles de filtrage de paquets au niveau du noyau, rejetant systématiquement tout flux sortant sur l'adaptateur physique s'il ne correspond pas au socket chiffré du serveur authentifié.

Sous Linux avec nftables, le trafic physique est strictement verrouillé :

# Autorisation exclusive des paquets UDP encapsulés sur l'interface physique
table inet vpn_filter {
    chain output {
        type filter hook output priority 0; policy drop;

        # Autorisation du trafic de boucle locale et de l'interface virtuelle
        oifname "lo" accept
        oifname "rice0" accept

        # Autorisation unique du serveur distant sur la carte physique
        oifname "wlan0" udp dport 51820 ip daddr 203.0.113.10 accept
    }
}

Sur Windows, la plateforme Windows Filtering Platform (WFP) intercepte les paquets au niveau de la couche transport avant qu'ils n'atteignent le contrôleur physique. Sur macOS, des règles pf empêchent toute interface autre que le tunnel virtuel de traiter le trafic applicatif.

2. Désactivation du partage local sur les réseaux Wi-Fi publics

L'attaque LocalNet reposant sur les exceptions de réseau local, les clients robustes désactivent automatiquement l'accès local sur les points de connexion inconnus :

  • Suppression des routes directes de portée liaison.
  • Redirection de l'intégralité du trafic non-boucle vers le tunnel sécurisé.
  • Même si un serveur DHCP attribue un faux sous-réseau /8, les règles de pare-feu bloquent l'émission directe.

3. Espaces de noms réseau et directive SO_BINDTODEVICE

Dans les environnements Linux et Android, les espaces de noms réseau procurent une isolation étanche. En plaçant l'adaptateur Wi-Fi physique dans un espace de noms distinct et en conservant les logiciels utilisateurs dans l'espace principal doté uniquement du tunnel virtuel, les programmes sont dans l'incapacité matérielle d'adresser les liaisons externes.

Au niveau applicatif, les sockets peuvent également être assignés directement à l'interface virtuelle :

// Liaison obligatoire du socket à l'interface virtuelle sécurisée
setsockopt(sock_fd, SOL_SOCKET, SO_BINDTODEVICE, "rice0", strlen("rice0"));

Cette liaison explicite neutralise l'évaluation standard de la table de routage globale et envoie directement les charges utiles dans l'interface désignée.

Vérifier la robustesse de son installation face aux manipulations

Les ingénieurs système et les utilisateurs soucieux de leur sécurité peuvent tester la résilience de leur matériel :

  1. Vérification de la table de routage active : Examinez les routes avant et après l'activation de la session pour identifier toute entrée d'hôte suspecte ou sous-réseau inattendu :
    ip route show table all
  2. Épreuve du sous-réseau simulé : Configurez un routeur de test pour annoncer une plage publique (ex. 198.51.100.0/24) par DHCP local. Connectez votre appareil, activez le tunnel et constatez si le trafic vers 198.51.100.1 est correctement sécurisé ou bloqué par le filtre.
  3. Contrôle des paramètres locaux : Vérifiez que l'option de visibilité sur le réseau local est bien désactivée lors de vos déplacements.

L'écosystème VPNRice s'appuie sur le protocole RiceGuard et un moteur de couche 3 renforcé, combinant liaison stricte des interfaces et filtrage dynamique pour écarter toute manipulation malveillante des tables de routage.

Pour sécuriser efficacement ordinateurs portables, terminaux mobiles et postes de travail, installez la version la plus récente depuis la page Télécharger VPNRice.