Les exploits NatJack mettent les hypothèses de sécurité NAT à l’épreuve chez Black Hat

Depuis des décennies, la traduction d’adresses réseau (NAT) constitue le moyen par défaut pour fournir les adresses IP au sein de réseaux plus vastes, afin de relever les défis liés à la disponibilité des adresses IPv4.

Le principe de base du NAT est que les adresses privées restent privées, mais cette hypothèse n’est peut-être plus tout à fait exacte (si elle l’a jamais été). Lors de Black Hat USA 2026, le chercheur Malcolm Stagg, chercheur indépendant et membre de l’équipe Synack Red, a révélé NatJack, une classe d’attaque qui manipule la table de suivi des connexions NAT.

Un attaquant partageant une limite NAT avec une victime peut détourner les connexions actives, empoisonner les réponses DNS et forcer un déni de service, sans que l’usurpation d’adresse IP ou l’accès au domaine de diffusion d’anciennes attaques de couche 2 ne soient nécessaires. Treize fournisseurs ont été informés et les tests ont porté sur 32 produits et configurations dans 95 rapports. Chaque implémentation testée était vulnérable à tout ou partie des techniques NatJack.

Stagg n’a pas intentionnellement cherché à trouver des failles dans le NAT, mais il les a trouvées. « Je suis tombé sur cette attaque entièrement par accident », a déclaré Stagg. « J’ai remarqué que je recevais parfois des réponses qui ne correspondaient pas aux paquets que j’envoyais. Cela m’a indiqué qu’il y avait une sorte de corruption dans la table NAT. »

Ce qui casse dans le modèle de confiance NAT

NAT n’a jamais été conçu comme un contrôle de sécurité. Il est apparu au début des années 1990 comme un palliatif à l’épuisement des adresses IPv4, permettant à plusieurs appareils de partager une adresse IP publique dans le cadre d’une hypothèse de confiance entre pairs.

« Je pense que cela revient essentiellement à une sous-spécification dans certaines RFC qui autorisent simplement des comportements basés sur l’hypothèse que vous êtes dans un réseau où les pairs sont dignes de confiance », a déclaré Stagg.

NAT a déjà été piraté. Le chercheur en sécurité Samy Kamkar a divulgué NAT Pinning lors de DEF CON 18 et Black Hat en 2010, une des premières techniques de manipulation du comportement des ports NAT. Il est revenu sur le problème une décennie plus tard avec NAT Slipstreaming, divulgué en 2020 et développé avec les chercheurs d’Armis en 2021, qui abusait du suivi des connexions Application Level Gateway (ALG) et obligeait une victime à visiter un site Web malveillant. Ces failles ont toutes été corrigées.

NatJack est différent. Il manipule directement la table NAT, ne nécessite aucun ALG et ne nécessite aucune action de la victime au-delà d’une connexion active via le même NAT.

La faille ne s’arrête pas à la couche 2. La segmentation des VLAN et l’isolation des ports de commutation n’aident pas, puisque l’attaque cible l’infrastructure NAT partagée aux couches 3 et 4 plutôt que le domaine de diffusion local. La faille a été confirmée sur Windows, Linux et macOS malgré l’absence de base de code NAT partagée, indiquant une hypothèse de conception partagée plutôt qu’un bug isolé.

Quatre techniques d’attaque, une faiblesse commune

NatJack couvre quatre techniques distinctes, toutes basées sur la même faiblesse dans la façon dont les tables NAT suivent les connexions.

• Détournement de connexion TCP. Un attaquant force la connexion d’une victime dans un état fermé à l’aide de paquets usurpés, puis remplace l’entrée de table résultante par une entrée pointant vers l’attaquant. Le mécanisme d’assassinat RFC 1337 TIME-WAIT identifié par Stagg permet que cela se produise dans une poignée de paquets plutôt que dans un délai d’expiration de connexion standard.
• Empoisonnement de la réponse DNS. La technique intercepte et modifie les réponses DNS UDP transitant par le NAT, redirigeant les recherches d’une victime à son insu.
• Déni de service. Un attaquant épuise lui-même la table NAT, interrompant ainsi la connectivité de chaque appareil partageant ce NAT.
• Identification du port de connexion. Un attaquant détermine quel port un NAT a attribué à une connexion active, information qui peut prendre en charge les trois autres techniques.

Divulgation et réponse mitigée des fournisseurs

Stagg a divulgué la faille de manière responsable, bien que la réaction des fournisseurs ait été très variée, allant de correctifs formels à un rejet pur et simple.

L’équipe de sécurité du noyau Linux a initialement rejeté le rapport, allant jusqu’à le qualifier de totalement faux. Stagg a déclaré que la réponse l’avait pris au dépourvu. « J’ai été assez surpris par cela », a déclaré Stagg. « Recevoir cette réponse était un peu inattendu et un peu décourageant. »

Le noyau a finalement été corrigé à la demande de Microsoft pour prendre en charge le service Azure Kubernetes, ce qui a donné naissance au CVE-2026-63913. La propre vulnérabilité Windows NAT de Microsoft, affectant Hyper-V, a été attribuée CVE-2026-56181.

D’autres fournisseurs ont refusé de classer les résultats comme vulnérabilités. « Ces rapports concernent des limitations NAT au niveau de la conception plutôt que des vulnérabilités de sécurité », a déclaré Cisco PSIRT. « Il existe des mesures d’atténuation documentées pour les produits Cisco Secure Firewall et Cisco IOS XE qui permettraient d’éviter la plupart, sinon la totalité, de ces problèmes. »

Apple a adopté une position similaire. « Nous avons déterminé que le comportement reflète une limitation connue de la couche de transport plutôt qu’une vulnérabilité », a déclaré Apple Product Security. « Les modèles de sécurité modernes supposent que le réseau local peut être hostile. C’est pourquoi nous continuons à nous appuyer sur le cryptage de bout en bout, tel que TLS. »

Stagg a noté que même si le cryptage atténue les pires résultats de NatJack, il n’élimine pas le risque. « Le cryptage est ici d’une grande aide car un attaquant peut toujours pirater une connexion, mais s’il le fait, il ne peut ni envoyer ni recevoir de données non cryptées sur cette connexion », a déclaré Stagg. « Un attaquant peut toujours cibler et supprimer n’importe laquelle de ces connexions. »

Détection et atténuation

Même sans correctifs complets disponibles, les professionnels des réseaux peuvent prendre certaines mesures pour limiter les risques. Stagg suggère ce qui suit :

• Surveillez les indicateurs de compromission. Surveillez une table NAT pleine ou presque pleine, des flots de paquets TCP ou UDP sur une large plage de ports, la même adresse IP apparaissant à deux emplacements physiques et des séquences de paquets SYN ou RST anormales.
• Activez la protection IP source. Activez des protections telles que IP Source Guard pour bloquer les paquets usurpés au niveau du routeur ou du pare-feu.
• Segmentez le trafic non fiable. Placez les utilisateurs non fiables sur un sous-réseau ou un VLAN distinct et limitez les connexions par client à environ 10 000.
• Désactivez les modes de connexion lâches. Désactivez le suivi des connexions lâches, la préservation des ports et le mappage indépendant du point de terminaison lorsque cela est pris en charge.
• Restreindre l’accès au réseau de conteneurs. Désactivez l’accès au réseau pour les conteneurs non fiables et les charges de travail Kubernetes, évitez de les exécuter en tant que root et supprimez les fonctionnalités par défaut.
• Isolez les charges de travail cloud. Gardez les charges de travail non fiables et fiables hors de la même passerelle NAT et utilisez des adresses IP dédiées pour les charges de travail sans serveur.

« L’une des variantes d’attaque fonctionne toujours dans les cas où l’attaquant et la victime se trouvent dans des sous-réseaux différents », a déclaré Stagg.

Stagg a déclaré que la leçon sous-jacente de NatJack s’étend au-delà de n’importe quel patch.

« De nombreux réseaux sont vulnérables à cela, et vous ne pouvez pas toujours compter sur les isolations de couche 2 en place », a déclaré Stagg. « Lorsque vous vous appuyez sur des choix de conception historiques, ces modèles de menace peuvent ne pas être les mêmes qu’à l’époque. Il est important d’examiner ces hypothèses de conception et de voir si des mises à jour pourraient être nécessaires sur la base des nouveaux modèles de menace. «