Attaque Port Shadow, permettant de rediriger les connexions d'autres utilisateurs VPN et Wi-Fi

Un groupe de chercheurs des universités canadiennes et américaines a développé une technique d'attaque appelée Port Shadow, permettant, par la manipulation des tables de traduction d'adresses du côté du serveur VPN, de faire en sorte qu'une réponse à une demande soit envoyée à un autre utilisateur connecté au même serveur VPN. Cette méthode peut être utilisée pour intercepter ou rediriger du trafic chiffré, effectuer des analyses de ports et dé-anonymiser les utilisateurs de VPN. Par exemple, elle peut être utilisée pour rediriger les requêtes DNS de l'utilisateur, qui passe par un serveur VPN, vers un hôte contrôlé par l'attaquant, à qui le client a la possibilité de se connecter.

Pour réaliser l'attaque, l'attaquant doit avoir la capacité de se connecter à un VPN-serveur avec la victime, ce qui est possible, par exemple, en utilisant des opérateurs VPN classiques et des services VPN publics qui offrent un accès à tous. La vulnérabilité touche les serveurs VPN utilisant la traduction d'adresses (NAT) pour permettre aux clients d’accéder à des ressources externes, à condition que le même IP soit utilisé pour recevoir le trafic des clients et envoyer des demandes vers des sites externes. le serveur Un

L'attaque repose sur le fait qu'en envoyant des requêtes spécialement formulées, l'attaquant connecté au même serveur VPN et utilisant un NAT partagé, peut provoquer une distorsion du contenu des tables de traduction d’adresses, ce qui entraînera la redirection de paquets destinés à un utilisateur vers un autre utilisateur. Dans les tables de traduction d'adresses, l'information concernant l'IP interne à laquelle la demande envoyée est associée est déterminée en fonction du numéro de port réseau source utilisé pour l'envoi de la demande. L'attaquant, en envoyant des paquets SYN et ACK spécifiques et en manipulant simultanément la connexion client au serveur VPN et le serveur externe contrôlé par l'attaquant, peut provoquer une collision dans la table NAT et ajouter une entrée avec le même numéro de port source, mais associée à son adresse locale, ce qui entraînera le retour des réponses à une demande étrangère à l'adresse de l'attaquant.

Dans le cadre de l'étude, des systèmes de translation d'adresses Linux et FreeBSD ont été testés en combinaison avec les VPN OpenVPN, OpenConnect et WireGuard. La plateforme FreeBSD s'est avérée non sujette aux méthodes d'attaque de redirection des requêtes effectuées par d'autres utilisateurs connectés au même VPN. La substitution dans les tables NAT a pu être réalisée uniquement lors de l'attaque ATIP (Adjacent-to-In-Path), où l'attaquant peut s'immiscer dans le trafic entre l'utilisateur et le serveur VPN (par exemple, lorsque l'utilisateur se connecte à un réseau Wi-Fi contrôlé par l'attaquant) ou entre le serveur VPN et le site cible. Par ailleurs, le NAT FreeBSD a également été impacté par une attaque permettant de déterminer le fait qu'un utilisateur soit connecté à un certain site (Connection Inference).

En ce qui concerne Linux, le sous-système Netfilter s'est avéré vulnérable aux attaques par substitution d'enregistrements dans la table de translation d'adresses, permettant de rediriger les paquets entrants vers un autre utilisateur, d'envoyer des paquets en dehors du canal VPN chiffré (Decapsulation) ou de déterminer les ports réseau ouverts du côté client.

Comme mesures pour bloquer l'attaque, il est recommandé aux fournisseurs de VPN d'utiliser des méthodes adéquates de randomisation des numéros de ports source dans le NAT, de limiter le nombre de connexions simultanées autorisées vers le serveur VPN à partir d'un seul utilisateur, ainsi que d'interdire la possibilité pour le client de choisir le port réseau acceptant les requêtes du côté du serveur VPN.

Selon un représentant de Proton AG, l'attaque n'affecte pas les services VPN qui utilisent des IP distinctes pour les requêtes entrantes et sortantes. De plus, des doutes subsistent quant à la possibilité d'appliquer l'attaque sur de réels services VPN, car une attaque réussie n'a jusqu'à présent été démontrée que lors de tests en laboratoire et nécessite l'exécution de conditions spécifiques du côté du serveur VPN et du client attaqué. De plus, l'attaque ne peut être utile que pour manipuler des requêtes non chiffrées, telles que celles concernant DNS, tandis que l'utilisation de TLS et HTTPS au niveau des applications rend la redirection du trafic inutile.

Les manipulations des tables de traduction d'adresses d'attaque s'appliquent non seulement aux VPN, mais aussi aux réseaux sans fil, où le NAT est utilisé pour connecter les utilisateurs à des ressources externes via un point d'accès. Le mois dernier, des résultats d'une étude ont été publiés sur la possibilité de mener une attaque similaire pour intercepter des connexions TCP d'autres utilisateurs sur un réseau sans fil. La méthode d'attaque s'est avérée applicable à 24 des 33 points d'accès sans fil testés.

L'attaque proposée pour le Wi-Fi s'est révélée beaucoup plus simple que la méthode mentionnée ci-dessus pour le VPN, car, en raison des optimisations appliquées, de nombreux points d'accès ne vérifient pas la validité des numéros de séquence dans les paquets TCP. Au final, il suffisait d'envoyer un faux paquet RST pour nettoyer l'entrée dans la table de traduction d'adresses, puis de rediriger la réponse vers l'hôte de l'attaquant pour déterminer les numéros de séquence (SEQ) et d'accusation (ACK) nécessaires à l'interception de la connexion TCP.

Source : opennet.ru