TunnelCrack contre TunnelVision : ce que chacun casse réellement

Deux noms de recherche sont employés indifféremment pour tout trafic VPN qui sort du tunnel, alors que les mécanismes derrière ne sont pas les mêmes. TunnelCrack décrit deux familles d’exceptions de routage ; TunnelVision décrit une route fournie par DHCP sur le poste final. Ni l’un ni l’autre ne casse le chiffrement, et ni l’un ni l’autre ne vous dit ce que fait aujourd’hui une version précise du client. Cinq vérifications séparent les mécanismes du titre.

Première étape : nommez le mécanisme que vous examinez

La divulgation TunnelCrack d’août 2023 décrit deux familles d’attaques. Dans le cas du réseau local, le trafic que le client considère comme appartenant au réseau local prend une exception d’accès local et quitte le tunnel. Dans le cas de l’adresse du serveur, la route dont le client a besoin pour atteindre le serveur VPN lui-même se trouve hors du tunnel, et un adversaire qui contrôle cette adresse peut exploiter l’exception.

TunnelVision est un rapport distinct sur les routes statiques sans classe fournies par DHCP. Un serveur DHCP malveillant peut remettre au poste final des routes qui changent le chemin pris par le trafic, y compris le chemin vers le serveur VPN. Le rapport reconnaît des travaux antérieurs sur des effets de routage apparentés, ce qui rappelle que le mécanisme sous-jacent est plus ancien que le nom.

Gardez les noms attachés à leurs mécanismes. Appliquer un correctif pour l’un parce que l’autre est dans l’actualité, c’est ainsi qu’une revue produit du mouvement sans couverture.

Deuxième étape : examinez l’exception d’accès local

La plupart des clients exemptent le trafic du réseau local pour que les imprimantes, la diffusion d’écran et le partage de fichiers continuent de fonctionner pendant que le tunnel est actif. Cette exception est une décision de politique avec un coût de sécurité : un adversaire sur le même réseau peut se présenter comme un hôte local, et le trafic qui l’atteint n’est jamais entré dans le tunnel.

Demandez si le profil déployé a vraiment besoin de l’exception. Un personnel à distance qui n’utilise jamais la découverte locale peut souvent la désactiver, et les services locaux restants sont joignables par un chemin documenté. Là où l’exception est nécessaire, indiquez quelles destinations elle couvre au lieu de la décrire comme du trafic local.

La vérification est une question de configuration, pas une capture de paquets. Lisez le réglage du profil et la documentation du client pour la version que vous déployez, car la valeur par défaut diffère entre produits et entre versions d’un même produit. Écrivez la réponse à côté du profil, pour que le prochain relecteur n’ait pas à la déduire du comportement. Une exception que personne n’a documentée est une exception que personne ne révise.

Troisième étape : examinez comment l’adresse du serveur est apprise

Le client doit atteindre le serveur VPN avant qu’un tunnel existe, donc cette destination est routée hors du tunnel par conception. Si l’adresse est apprise à partir d’un nom, l’étape de résolution fait partie du chemin de confiance, et un adversaire capable de répondre à cette requête peut diriger le client vers un hôte qu’il contrôle.

Épingler l’adresse, utiliser un certificat vérifié portant le bon nom et refuser de retomber sur un serveur non vérifié réduisent tous l’exposition. Aucun d’eux ne supprime le besoin d’atteindre le serveur hors du tunnel ; ils changent qui peut répondre de cette adresse.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

La recherche de route montre l’interface que le client utiliserait pour l’adresse du serveur, ce qui est l’exception sous forme concrète. Si cette recherche renvoie l’interface du tunnel, le client ne peut même pas établir le tunnel, donc une route extérieure est attendue et la question est seulement comment sa destination est choisie.

Quatrième étape : examinez les routes fournies par DHCP

Les routes statiques sans classe permettent à un serveur DHCP de distribuer des entrées de la table de routage, et le poste final les accepte généralement sans demander. Sur un réseau où un adversaire peut répondre au DHCP plus vite que le serveur légitime, ces entrées peuvent rediriger un trafic que l’utilisateur croit à l’intérieur du tunnel.

Comparez les routes du poste final avec celles que vous attendez. Une route par défaut ou un préfixe large pointant vers la passerelle locale pendant que le tunnel est actif est la signature qui mérite une enquête, et elle est visible sans aucun trafic d’attaque.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

Le dernier réglage est le contrôle côté poste final que beaucoup de clients et de plateformes exposent sous une forme ou une autre : ignorer les routes fournies par le réseau. Désactiver l’acceptation automatique des routes est un compromis, car cela désactive aussi le routage divisé légitime d’un serveur DHCP d’entreprise, alors décidez-le par classe de réseau plutôt que globalement.

Cinquième étape : séparez l’avis de la version actuelle

Une attaque publiée décrit un comportement observé sur certaines versions du client à un moment donné. Elle n’établit pas que l’ordinateur portable devant vous est touché, et elle n’établit pas qu’il est corrigé. Les deux affirmations exigent le numéro de version réel et l’avis actuel de l’éditeur.

Notez la version du client, la plateforme, les réglages de profil qui gouvernent les exceptions ci-dessus et la date à laquelle vous avez vérifié. Ce compte rendu vieillit honnêtement, alors qu’une note affirmant que la VPN a été corrigée pour TunnelCrack ne vieillit pas honnêtement. Relisez-le à chaque mise à jour du client, car une valeur par défaut de profil peut changer sous une version que vous n’avez pas touchée.

Quand vous validez réellement, utilisez un plan approuvé contre votre propre poste final et une destination inoffensive. Reproduire l’attaque contre d’autres utilisateurs sur un réseau partagé n’est pas un test, et désactiver la vérification des pairs ou le chiffrement de l’application pour faciliter une observation supprime la protection que vous cherchiez à mesurer.

Enfin, gardez la protection au niveau applicatif dans l’image. Une exception de routage peut exposer un trafic que le tunnel aurait porté, et le TLS de l’application protège encore ce trafic de bout en bout. Les deux couches échouent indépendamment, ce qui explique qu’un canal de contrôle connecté ne prouve pas que chaque flux a suivi le chemin prévu.