Sécurité Windows : pourquoi désactiver IPv6 pour atténuer les vulnérabilités ?
Sommaire
I. Présentation
Dans cet article, nous aborderons les méthodes de remédiation passives face aux vulnérabilités du protocole IPv6, sur une machine Windows.
Cet article fait suite à la découverte récente d’une nouvelle vulnérabilité (CVE-2024-38063) dans l’implémentation du protocole IPv6 sur Windows. L’exploitation de cette faiblesse permet une exécution de code à distance, révélant ainsi une faiblesse significative. Cette vulnérabilité expose non seulement les systèmes à des attaques potentielles, mais ouvre également la voie à divers autres exploits futurs…
Dans ce contexte, nous explorerons les stratégies pour atténuer ces risques et maintenir un contrôle efficace au sein de votre entreprise. Autrement dit, nous verrons comment et pourquoi les machines Windows de votre entreprise peuvent se passer de l’IPv6.
II. Pourquoi se passer d'IPv6 ?
Nous ne remettrons pas en question les recommandations précédentes concernant IPv6, mais il est important de tirer des conclusions claires sur son utilisation. Si IPv6 n'est pas encore administré ou déployé dans votre entreprise, son activation en interne peut être superflue. Sa présence ne fait qu’augmenter la surface d’attaque de vos machines.
De plus, la plupart des routeurs modernes utilisent la NAT (Network Address Translation), ce qui aide à gérer efficacement l'épuisement des adresses IPv4.
La question essentielle devient alors : comment se passer d'IPv6 ? Deux options principales se présentent :
- Désactiver IPv6 au niveau système : cette méthode désactive complètement le protocole IPv6 sur l'ensemble du système. Cela peut être approprié si vous ne prévoyez pas d'utiliser IPv6 à l'avenir ou si vous souhaitez éviter tout risque associé à ce protocole.
- Empêcher l'utilisation d'IPv6 au niveau de l'interface : vous pouvez configurer les interfaces réseau pour ne pas utiliser IPv6 tout en maintenant la capacité de le reconnaître. Cela équivaut à avoir une carte SIM dans un téléphone sans solde ni forfait d'appel : la carte est présente, mais le service n'est pas utilisé. Cette approche est souvent préférable à une désactivation totale, car elle conserve une certaine fonctionnalité sans exposer les systèmes aux risques potentiels d'IPv6.
Microsoft a rapidement publié un correctif pour la vulnérabilité CVE-2024-38063. Cependant, le cycle de patching peut varier d'une entreprise à l'autre, certaines entreprises possèdent encore des serveurs non supportés comme ceux sous Windows Server 2012 R2 ou version inférieure. Dans ce cas, comment s’y prendre pour désactiver IPv6 ?
III. Fragilité du protocole IPv6
Contrairement à IPv4, IPv6 utilise une auto-configuration via le mécanisme SLAAC (Stateless Address Autoconfiguration) permettant à une machine de générer une adresse IP unique à partir d'une partie de son adresse MAC, ce qui réduit la dépendance vis-à-vis du service DHCP.
Cependant, cette fonctionnalité peut exposer les systèmes à des attaques. Par exemple, des machines malveillantes peuvent tromper les systèmes en envoyant des configurations DNS falsifiées. Tout cela à cause du paramètre suivant activé par défaut sur les serveurs Windows Server et les postes de travail Windows.
L'attaque la plus connue dans ce contexte est le flood IPv6 ou l'empoisonnement DNS via le protocole RA (Router Advertisement). Pour illustrer cette vulnérabilité, nous allons démontrer une attaque sur un environnement patché.
Dans notre laboratoire, nous avons utilisé une machine Kali Linux pour jouer le rôle de l’attaquant. Avec l'outil mitm6, nous pouvons envoyer des configurations DNS aux machines IPv6 sans qu'elles soient correctement configurées. Ensuite, nous avons observé les échanges à partir d'un fichier de configuration WPAD pour illustrer la possibilité d'une attaque NTLM relay.
Pour cet exercice, nous utiliserons l'outil mitm6 disponible sur le GitHub suivant :
Commençons par installer l'outil à partir de la bibliothèque à l'aide de la commande suivante :
sudo git clone https://github.com/dirkjanm/mitm6.git
Déplacez-vous dans le dossier pour installer l'outil.
Une fois l'installation terminée, nous lancerons l'outil pour qu'il commence à écouter les demandes IPv6 sur le réseau. L'outil enverra régulièrement des requêtes ping pour détecter de nouvelles machines. Lorsqu'une machine est capturée, l'outil lui attribuera une fausse adresse IPv6 et un faux DNS afin d'intercepter les échanges.
Sur la machine victime, dans notre cas un poste Windows 10, nous pouvons observer des demandes DHCP et des échanges en cours.
Un faux fichier de configuration WPAD a été transmis. WPAD (Web Proxy Auto-Discovery Protocol) est utilisé pour découvrir automatiquement les serveurs proxy sur un réseau. En envoyant un fichier de configuration WPAD malveillant, un attaquant peut rediriger le trafic réseau de la machine victime vers un serveur proxy sous son contrôle, permettant ainsi l'interception et la manipulation des échanges.
En vérifiant la configuration DNS à l'aide de la commande « ipconfig /all », nous remarquons qu'un faux serveur DNS a été ajouté à la configuration, il s'agit de l'adresse de notre serveur d'attaque.
Nous n'irons pas plus loin dans cette attaque, mais nous avons pu constater, sans avoir besoin d'interaction ou de mot de passe, à quel point Windows peut être trompé par ce protocole, notamment en ce qui concerne la configuration IPv6.
IV. La désactivation d’IPv6 sur Windows
A. Désactiver IPv6 avec le Registre Windows
Outre le patch fourni par Microsoft pour la CVE évoquée précédemment, deux méthodes radicales ont été évoquées pour désactiver la prise en charge du protocole IPv6.
Avant de comparer ces méthodes, il est important de rappeler que Microsoft privilégie la mise en place de patchs comme principale contre-mesure plutôt que la désactivation du protocole au niveau système. Microsoft ne recommande pas cette dernière approche et ne fournit pas de support pour celle-ci.
Voici ce que nous pouvons lire sur cette page du site Microsoft :
Dans la pratique, la désactivation d'IPv6 peut se faire en modifiant la clé de registre suivante :
- Chemin : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
- Nom de la clé : DisabledComponents
- Valeur : FF (pour désactiver IPv6)
Si besoin, vous trouverez plus de détails sur cette méthode en suivant le lien fourni ci-dessus.
Nous allons créer cette clé de registre, puis relancer l'attaque précédente pour observer les effets.
Nous constatons que l'attaque a bien fonctionné.
En effet, la clé nécessite un redémarrage du serveur ou de la machine pour devenir opérationnelle, ce qui n'est pas toujours envisageable dans un environnement de serveurs en production. De même, pour effectuer un rollback, un redémarrage des serveurs est également nécessaire. Ces raisons, en plus des recommandations de Microsoft, nous poussent à privilégier la deuxième méthode.
B. Désactiver IPv6 sur les interfaces réseaux Windows
La deuxième méthode consiste à désactiver la prise en charge d'IPv6 au niveau des interfaces réseau (câblées ou Wi-Fi), sans modifier le comportement global du système. Cela signifie que si une application est conçue pour rechercher une adresse IPv6, écouter sur IPv6, ou effectuer des calculs ou traductions IPv6, les interfaces réseau répondront comme si IPv6 était absent.
Cependant, le système continuera à utiliser l'adresse IPv6 loopback, ce qui permet d'éviter les problèmes potentiels. Cette approche est utile car, dans certains cas, IPv6 peut être prioritaire dans le développement de services et d'applications.
Sur chaque interface réseau, nous devons décocher l’option « Protocole Internet version 6 (TCP/IPv6) ». Ceci peut être fait à partir de l’interface graphique, ou de PowerShell.
Pour gagner du temps, vous pouvez exécuter la commande PowerShell ci-dessous pour effectuer cette opération sur l’ensemble des interfaces de votre machine. Cette commande doit être exécutée en tant qu’administrateur.
Get-NetAdapter | ForEach-Object { Disable-NetAdapterBinding -Name $_.Name -ComponentID ms_tcpip6 }
L'utilisation de la commande « Get-NetAdapter » liste uniquement les cartes réseau physiques, en ignorant les cartes virtuelles comme le loopback. Cette approche est recommandée pour éviter toute déstabilisation du système. Pour vous assurer que l'interface loopback IPv6 est toujours active, vous pouvez vérifier son état avec la commande suivante, en vous assurant que l'interface "Loopback" est bien en mode "Connected" :
Get-NetIPInterface
Sur la machine Kali, nous constatons que le résultat est immédiat : l'attaque échoue, et la carte réseau ne répond à aucune requête IPv6. Il n'a pas été nécessaire de redémarrer la machine pour observer cet effet.
Cependant, la carte réseau continue de recevoir des requêtes IPv6, comme les pings, que ce soit avec la première ou la deuxième méthode.
Il faudra alors renforcer la sécurité avec des règles Pare-feu Windows dans le but d’ignorer les paquets IPv6.
Pour automatiser la création de ces règles, voici un script PowerShell prêt à l’emploi disponible sur GitHub et créé par mes soins :
Le script « Firewall_DisableIpv6.PS1 » permet de créer des règles de pare-feu pour les connexions entrantes et sortantes, bloquant ainsi tous les protocoles IPV6. Comme mentionné ci-dessous.
Téléchargez le script « Firewall_DisableIpv6.PS1 ». Une fois le script téléchargé, exécutez-le en mode administrateur.
Nous pouvons voir les règles créées pour le trafic entrant et sortant. Toutes les règles ont un nom qui contient le préfixe « No-IPv6 » pour simplifier l'identification.
Avec cette deuxième méthode, nous pouvons être sûrs d'atténuer les différentes vulnérabilités IPv6 en attendant l'application des mises à jour en cours ou la disponibilité de nouvelles mises à jour pour d'éventuelles vulnérabilités futures.
V. Automatiser la désactivation d’IPv6 par GPO
Bien que l'atténuation puisse être mise en place facilement, sa gestion devient complexe lorsqu'il s'agit de déployer sur un grand nombre de machines. Si vous utilisez une solution de gestion des machines ou des serveurs comme SCCM, Intune, ou autre, il vous suffit de déployer les scripts sur l'ensemble des machines, ce qui rend l'action rapide et immédiate.
En revanche, si vous ne disposez pas de telles solutions, vous devriez envisager de déployer les scripts soit par GPO, soit par les tâches planifiées. Nous allons explorer ces méthodes pour rendre le déploiement possible et protéger l'ensemble de votre parc informatique Windows.
Note : Grace au protocole WinRM, il est possible d'exécuter des commandes sur des serveurs distants, notamment PowerShell. Étant donné que la commande de désactivation du protocole IPv6 sur la carte n’impacte pas la disponibilité de l’hôte, vous pouvez le faire à tout moment.
A. Préparer le script de configuration
Téléchargez le script « Manage-IPv6.ps1 » à partir du GitHub. Mettez-le dans un dossier de téléchargement par exemple, ou copiez-le seulement dans l'éditeur ISE.
Le script est composé de deux fonctions majeures, « Enable-IPv6Adapter » et « Disable-IPv6Adapter », l'une permet d'activer la prise en charge IPv6 sur toutes les cartes locales et l'autre de désactiver le protocole, c'est cette dernière qui est activée par défaut.
Pour effectuer un rollback, il suffit de commenter la fonction « Disable-IPv6Adapter » et de décommenter la fonction « Enable-IPv6Adapter » en retirant le caractère « # » devant celle-ci.
Notre GPO va donc exécuter deux scripts :
- Firewall_DisableIpv6.PS1 pour la création des règles de firewall
- Manage-IPv6.ps1 pour la désactivation de l’IPv6 dans les paramètres des cartes réseaux
B. Exécuter le script au démarrage de Windows
Nous allons créer une GPO pour exécuter les scripts au démarrage de Windows, ce qui implique un redémarrage de la machine pour l’application de la configuration. Nous évoquerons une autre méthode dans la suite de ce tutoriel.
À partir de la console de gestion des stratégies de groupe, créez une GPO au niveau de la racine ou des unités d'organisation (OUs) des ordinateurs de votre parc. Le choix final revient aux administrateurs. Il est intéressant d'exclure les serveurs du cercle 0 (DC et PKI), même si l'action est sans impact, afin de favoriser le changement manuel.
Nous avons appelé notre GPO "Disable_IPV6_Adapter". De votre côté, respectez la convention de nommage dans votre entreprise.
Naviguez ensuite dans le chemin suivant :
- Configuration Ordinateur > Paramètres Windows > Scripts (Démarrage/arrêt) > Démarrage
Puis, basculez sur l'onglet « Scripts Powershell » et cliquez sur « Ajouter ».
Cliquez ensuite sur « Parcourir » pour lier les scripts.
Copiez les scripts précédemment téléchargés dans le chemin proposé, puis sélectionnez-les (c’est important pour qu’ils soient accessibles via le réseau !).
Pour rappel, nous avons copié les deux scripts à partir du GitHub. Le premier script évoqué dans cet article permet de créer des règles pour refuser les protocoles IPV6.
Note : certaines entreprises regroupent les scripts dans un dossier commun comme le Netlogon ou sur un partage DFS, si ce n'est pas votre cas, vous pouvez utiliser la méthode du chemin par défaut comme nous faisons.
Cliquez ensuite sur « Appliquer » puis « OK » pour fermer la fenêtre de la GPO. Vérifiez bien que 2 scripts sont liés à la GPO. L’ordre n’a pas d’importance.
Notre GPO est alors créée ! Au prochain redémarrage des serveurs et des machines, le protocole IPV6 sur les cartes sera bloqué.
Remarque : comme l'héritage est bloqué sur nos serveurs sensibles (DC), nous nous sommes permis de lier la GPO sur la racine. Pour avoir plus de détails sur l’objectif du blocage d'héritage sur l’OU « Domain Controllers », consultez l'article suivant :
Vous pouvez aussi utiliser le filtrage WMI pour cibler un OS particulier, suivez ce tutoriel si besoin d’approfondir le sujet.
Une fois la machine redémarrée, nous remarquons que le protocole a bien été décoché sur les cartes réseaux ! De plus, un fichier de log a été créé dans le dossier « C:\temp » de la machine sur laquelle s’est exécutée le script.
Voici un aperçu du fichier de log :
C. Utilisation de tâches planifiées
Il est possible d'appliquer immédiatement les scripts si l'entreprise ne possède pas d'outil de gestion de parc évoqué précédemment comme SCCM ou autres.
Cette méthode repose aussi sur l’utilisation d’une GPO, mais nécessite une maitrise et adaptation au contexte de l'environnement qui diffère d'une entreprise à l'autre. L’idée étant d’exécuter chaque script PowerShell via une tâche planifiée poussée par GPO.
Nous essaierons de vous proposer un tutoriel complémentaire sur cette méthode. En attendant, vous pouvez rejoindre le Discord IT-Connect pour en discuter ou laisser un commentaire si vous êtes intéressé. Vous pouvez aussi vous rapprocher de nous pour une mise en place.
Par ailleurs, si vous travaillez sur Intune, consultez cet article :
VI. Conclusion
En mettant en œuvre les mesures évoquées dans cet article, vous devriez être en mesure de protéger vos postes de travail et serveurs Windows des attaques liées l’IPv6. Ce sera d’ailleurs l’occasion de se protéger contre une vulnérabilité récente, bien que le correctif de sécurité de Microsoft sera toujours la meilleure option.
La disponibilité de l’IPv6 sur des machines où cela n’est pas nécessaire (réseau en IPv4) représente un risque réel. Pour minimiser ces risques et se protéger contre les menaces futures, il est recommandé de suivre les conseils et meilleures pratiques testés et décrits dans cet article.
Article honteux, la pseudo démonstration par mitm pour démontrer la faiblesse de l’IPv6 est ridicule. Nous avons bien plus de problème avec l’IPv4, les attaques encore plus facile (simple ARP par exemple, on peut aussi simuler un service DHCPv4 etc).
On rappellera que spoofer dans ces cas, n’est limitée qu’au réseau local. Les données transporté par https préserve la confidentialité et l’intégrité dans ce type d’attaque. De plus la plus part des entreprises utilise des IDS pour détecter ce genre d’attaque (une simple règle suffit à les détecter…).
Bref, c’est pas un problème lié à l’IPv6 mais à ce que l’on en fait ! L’IPv6 est un prototype d’avenir, certains pays l’on compris et ne propose plus que de l’IPv6 d’ailleurs !
Bonjour N005,
pouvons nous avoir votre identité ou votre entreprise, l’article s’adresse aux entreprises n’utilisant pas ipv6 de base, dans ce cas ils pourront le désactiver à l’aide du script en attendant la migration vers ipv6 et le réactivé à tout moment, cela n’a rien avoir avec l’utilisation des pays d’ipv6 je pense que vous avez confondu avec l’usage générale ou étendue.
Commentaire honteux et rageux du N005, alors pour les entreprises sous windows n’ayant pas pu mettre en place de patch vous préconisez quoi ??? des milliers de système sont menacés et je pense que l’auteur comme il avait mentionné à utilisé une attaque simple pour sensibiliser sur la faiblesse du protocole ipv6 s’il n’est pas utilisé. bien sur tout protocole est vulnérable.
sinon proposez nous un article avec la dernière attaque ipv6 permettant une execution de code à distance c’est encore pire que mitm.
Cordialement maxime,
Pas d’accord,
IPv6 apporte des avantages indéniables, mais dans des environnements où il n’est pas utilisé, le désactiver peut être une solution pragmatique pour réduire la surface d’attaque. IDS n’est pas utilisé dans le réseau étendu des machines entre eux, un attaquant peut envoyer du code sans etre intercepté par l’ids les attaques ne viennent pas forcément d’extérieur.
Un grand merci à l’auteur et à it-connect pour leur réactivité et travail.
Ludo,
Cher Monsieur,
Je suis curieux de voir l’implémentation d’un IDS entre deux PC sur le même switch (ou pas, d’ailleurs)… Et je ne comprends pas le rapport entre HTTPS (couche 7 du modèle OSI) et IPv6 (couche 3 du modèle OSI) – je met ici un petit lien pour ceux qui liront ce commentaire et voudrait creuser le sujet: https://www.malekal.com/la-couche-du-modele-osi-pour-les-nuls/, tout le monde ne maitrise pas ce modele qui est pourtant tellement utile au quotidien !
Votre argumentation est donc quelque peu bancale. Sur le fond, IPv4 n’est pas plus en défaut qu’IPv6 : les deux protocoles souffrent de leurs faiblesses intrinsèques et l’idée de l’article n’est aucunement de dénigrer IPv6 mais de faire un constat : la plupart des entreprises (et j’en ai pas mal à mon compteur) ne sont absolument pas en IPv6 sur le réseau interne, ni même ne l’utilise d’une quelconque façon. Par conséquent, elles doivent décider d’une stratégie afin de « fermer » les portes ouvertes par ce protocole et limiter le périmètre des possibles pour un attaquant.
Petit addendum : la démonstration de MITM6 n’a pour but que de montrer la désactivation effective du protocole avec un outil ‘standard’ des attaquants (ou pen-tester de tout bord) et, le cas échéant, de permettre à un quidam de l »expérimenter.
Pour conclure, rappelons que Microsoft a déjà patché cette faille (mais il y en a d’autre undisclosed, j’en mettrais ma main à couper).
Cher monsieur, aucune œuvre humaine n’est parfaite…En outre il n’est pas donné à tout le monde de rédiger de tels articles…La politesse recommande vivement de commencer par saluer le travail ayant permis la rédaction de cet article même si vous avez des remarques ou critiques !
Maintenant, la rédaction de cet article fait suite à une faille de sécurité découverte dans l’IPv6, et Microsoft l’a d’ailleurs confirmé en y apportant un patch par la suite…L’auteur de l’article essaye aussi d’y apporter une contribution selon son contexte et le résultat de ses recherches à lui…Si vous estimez avoir quelque chose à ajouter à cela, faites le en toute courtoisie, car avec l’agressivité ou des injures, je crains fort qu’on avance pas vraiment !
Cordialement.
Merci Emile pour votre intervention, il s’agissait surement d’une confusion que j’ai peut être pas souligné en gros dans l’article, nous nous sommes adressé aux entreprises qui n’utilisent pas ipv6 dans leur réseau interne en leur favorisant de décocher la fonction, certains ont cru qu’on demande aux opérateurs ou service WAN de désactiver IPv6 ce qui n’est pas le cas.
Cordialement,
Bonjour N005,
la vulnérabilité (attaque) est maintenant disponible, vous pouvez la vérifier vous même et vérifier que les mesures proposés à l’aide des scripts réduisent cette vulnérabilité, notamment pour les serveurs qui ne sont plus supportés en conséquences ne bénéficient pas de patches.
https://github.com/ynwarcs/CVE-2024-38063
Cordialement,
Très bon article, Mesure déjà mis en place grâce à cet article, merci pour les efforts.
effectivement si IPv6 n’est pas utilisé dans l’entreprise autant le désactiver.
Trés bon artcile merci mille fois it-connect et medhi
Une bonne pratique en matière de sécurité : ne jamais laisser actif (ou conf par défaut) un service / protocole que l’on utilise pas. C’est valable pour IPv6, comme pour IPv4 : tout simplement parce-que cette surface d’attaque ne sera jamais observé/analysé par vos équipes (qui sont déjà bien occupé avec le reste ;)).
Cela n’a aucun sens concernant ipv6. Dire de désactiver ipv6 c’est comme de dire de couper internet sur votre machine.
Bonjour Michael,
Merci pour votre intervention, en aucun cas nous avons dit de désactiver ipv6 dans le monde, si vous avez suivi les publications et l’évolution de la menace, l’article s’adresse aux entreprises n’utilisant pas le protocole IPV6.
il est logique et préférable de décocher la fonction à l’aide du script fourni pour éviter les futurs vulnérabilités le temps que cette dernière soit déployée dans les entreprises au niveau du réseau interne.
il s’agit surement d’une confusion,.
Cordialement,
Très bon article, même recommandation que HardenAD, article et procédure légitime.
Merci,
Bonjour, merci pour cet excellent article.
J’ai noté 2 erreurs dans ton script Manage-IPv6.ps1
-Il manque la création du dossier c:\temp au cas où il n’existe pas.
-Quand on utilise la fonction Enable-IPv6Adapter cela écrit « IPv6 has been disabled on adapter ‘$adapterName’. » dans les logs au lieu de enabled.
Une fois ces 2 erreurs corrigées, il fonctionne bien.