Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2020-16898 — CVE-2020-16898 (Mauvais Voisin) Vulnérabilité TCP/IP de Microsoft Windows - Logique de détection et règle | Kitploit
Outils/GitHubGitHub/advanced-threat-research/cve-2020-16898
Analyse des VulnérabilitésExploitationSécurité RéseauDétection d'Intrusion
GitHubadvanced-threat-research/cve-2020-16898

CVE-2020-16898

CVE-2020-16898 (Mauvais Voisin) Vulnérabilité TCP/IP de Microsoft Windows - Logique de détection et règle

Voir le dépôt

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
Site web
20930il y a 5 ansVérifié par Kitploit

CVE-2020-16898: “Mauvais Voisin”

Score CVSS : 8.8

Vecteur CVSS : CVSS3.0/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C

Aperçu

Le 13 octobre, Microsoft a annoncé une vulnérabilité exceptionnellement critique dans la pile IPv6 de Windows, qui permet à un attaquant d'envoyer des paquets malveillants pour potentiellement exécuter du code arbitraire sur un système distant. La preuve de concept partagée avec les membres MAPP est à la fois extrêmement simple et parfaitement fiable. Elle entraîne un BSOD (Blue Screen of Death) immédiat, mais surtout, indique la probabilité d'une exploitation pour ceux qui parviendraient à contourner les mesures d'atténuation de Windows 10 et Windows Server 2019. Les effets d'une exploitation qui accorderait l'exécution de code à distance seraient étendus et très impactants, car il s'agit du type de bogue qui pourrait être rendu verrable. Pour faciliter la référence, nous avons nommé la vulnérabilité « Mauvais Voisin » car elle se situe dans un « Protocole » de découverte de voisins ICMPv6, utilisant le type Annonce de Routeur.

Ce document a été préparé par McAfee Advanced Threat Research. Il vise à fournir des informations précieuses aux administrateurs réseau et au personnel de sécurité, afin de mieux comprendre cette vulnérabilité et de se défendre contre son exploitation. La signature produite ici doit être soigneusement examinée et testée dans des environnements de staging avant d'être utilisée en production et peut bénéficier d'un réglage spécifique pour le déploiement cible.

Les informations fournies ici sont sujettes à modification sans préavis et sont fournies « TELLES QUELLES », avec tous leurs défauts, sans garantie quant à leur exactitude ou applicabilité à une situation ou circonstance particulière et à utiliser à vos propres risques. De plus, nous ne pouvons garantir aucun critère de performance ou d'efficacité pour les signatures.

Signature

La signature Suricata pour cette vulnérabilité se trouve dans cve-2020-16898.rules et contient la logique suivante :

alert icmp any any -> any any (msg:"Potential CVE-2020-16898 Exploit"; lua:cve-2020-16898.lua; sid:202016898; rev:1;)

Le script Lua correspondant se trouve dans cve-2020-16898.lua. Il contient la logique nécessaire pour analyser correctement la couche ICMPv6 et identifier une exploitation potentielle de Mauvais Voisin, comme suit :

Une fois que nous avons localisé le début de la couche ICMPv6, nous testons le premier octet de la couche pour nous assurer qu'il s'agit d'un paquet ICMPv6 de type Annonce de Routeur (Type = 134) - si ce n'est pas le cas, nous sortons.

Comme les primitives de Suricata n'ont pas été mises à jour pour analyser les options ICMPv6, nous sautons simplement au 17e octet de la couche ICMPv6, car c'est là que les Options devraient commencer, si présentes (les 16 premiers octets sont des champs de longueur fixe, selon la RFC 4443). De là, nous parcourons chaque Option jusqu'à épuisement des octets du paquet. Pour chaque Option, nous ne nous intéressons qu'aux deux premiers octets : les champs Type et Longueur d'Option, respectivement. Nous ignorons toutes les Options qui ne sont pas RDNSS, mais pour Type d'Option = 25 (RDNSS), nous vérifions si la Longueur (deuxième octet de l'Option) est un nombre pair. Si c'est le cas, nous signalons l'alerte. Sinon, nous continuons. Comme la Longueur est comptée par incréments de 8 octets, nous multiplions la Longueur par 8 et sautons ce nombre d'octets pour atteindre le début de l'Option suivante (en soustrayant 1 pour tenir compte de l'octet de longueur déjà consommé).

Avec cette règle, nous vérifions également que la Longueur est d'au moins 3, car la RFC 8106 l'exige, mais finalement cette vérification peut être superflue, puisque nous ne nous intéressons qu'au fait que la Longueur soit paire ou non.

Télécharger l’outil