Ceci est un PoC (plutôt instable) pour CVE-2024-38063, une RCE dans tcpip.sys corrigée le 13 août 2024. Je n'ai pas découvert et signalé cette vulnérabilité, c'est Wei.

prérequis

pip3 install scapy

utilisation

Modifiez les champs dans le script :

• iface <- Si vous avez plusieurs adaptateurs, vous devez choisir celui à utiliser pour envoyer les paquets. Par exemple "eth0" sous Linux ou "Hyper-V Virtual Ethernet Adapter" sous Windows. Si vous comptez utiliser votre interface par défaut, laissez-le vide.
• ip_addr <- Adresse IP du système cible (IPv6)
• num_tries & num_batches <- Combien de lots de paquets différents envoyer. Plus il y en a = plus de corruptions du tas provoquées + plus de chances de déclencher la vulnérabilité.
• mac_addr <- Laissez vide, sauf si scapy se plaint de ne pas trouver l'adresse MAC. Voir ci-dessous dans la section de dépannage.

Exécutez le script :

python3 cve-2024-38063.py

La façon la plus simple de reproduire la vulnérabilité est d'utiliser bcdedit /set debug on sur le système cible et de redémarrer la machine/VM. Cela fait du pilote d'adaptateur réseau par défaut kdnic.sys, qui est très enclin à fusionner les paquets. Si vous essayez de reproduire la vulnérabilité sur une configuration différente, vous devrez amener le système à fusionner les paquets que vous envoyez. Vous pouvez consulter la section de dépannage ci-dessous pour plus de détails.

démo

cve-2024-38063.webm

analyse approximative

Vous pouvez lire cette excellente analyse de la vulnérabilité par Marcus si vous êtes intéressé par les détails techniques. Les détails que j'ai écrits ci-dessous sont destinés à servir de résumé, plutôt que d'analyse technique sérieuse.

• Dans certaines situations, Windows fusionne plusieurs paquets IP ensemble et les traite par lots. Il traite d'abord les en-têtes d'extension de chaque paquet, puis seulement il passe au traitement des données de chaque paquet.
• Pendant le traitement des en-têtes d'extension, les objets paquets de ces paquets fusionnés sont liés entre eux dans une liste chaînée. Chaque objet paquet contient un objet NET_BUFFER qui contient les données du paquet en mémoire tampon. À l'offset 0x30, nous avons également un champ d'offset courant qui indique jusqu'où le paquet a été analysé. À ce stade, la valeur de l'offset est généralement 0x28, indiquant que l'en-tête IPv6 a été analysé mais rien d'autre.
• Lors du traitement de l'en-tête d'extension "destination options" dans tcpip!Ipv6pReceiveDestinationOptions, une erreur d'analyse entraînera l'appel de tcpip!IppSendErrorList. Cette fonction appelle tcpip!IppSendError sur chaque objet paquet de la liste chaînée (en commençant par l'actuel).
• Dans certaines conditions (par exemple si le paquet est unicast), tcpip!IppSendError a des effets secondaires. Il "ramène" les données du paquet mises en mémoire tampon au début et remet à zéro le champ d'offset courant.
• Cependant, dans toute cette chaîne d'événements, seul le premier paquet est marqué comme ayant une erreur (offset 0x8C). Cela signifie que le pilote continuera à analyser les en-têtes d'extension des autres paquets de la liste chaînée, même s'ils ont été "ramenés" dans .

stratégie

• Pour abuser de la vulnérabilité, nous utilisons Ipv6pReceiveFragment. La fonction analyse l'en-tête d'extension de fragment et suppose que le champ d'offset du paquet sera au moins 0x28 lors du calcul de la longueur des données hors en-tête du paquet en soustrayant 0x30 de la valeur d'offset courante. Cette valeur est ensuite stockée dans l'objet de réassemblage dont le but est de réassembler le paquet fragmenté.
• Dans notre cas, la fonction sera appelée sur un paquet qui a été ramené par IppSendError. La valeur de l'offset sera zéro et sera augmentée à 8 plus tôt dans Ipv6pReceiveFragment. Lors du calcul de la taille des données hors en-tête, la valeur passera sous zéro et sera égale à 0xffd8 (la soustraction est effectuée sur 16 bits).
• La valeur de longueur n'est utilisée qu'à deux endroits plus tard :
  • Ipv6pReassembleDatagram, où elle est utilisée pour calculer la longueur d'un tampon de sortie du paquet réassemblé. Cependant, tous les calculs sont effectués sur 32 bits et il y a une vérification de cohérence pour que la longueur totale ne dépasse pas 0xFFFF, ce qui est le cas dans cette situation.
  • Ipv6pReassemblyTimeout, où elle est également utilisée de la même manière. Cependant, les calculs ici sont effectués sur 16 bits et un dépassement d'entier se produit. Cela conduit à un débordement de tampon lors de la copie des données dans le tampon plus tard.

Pour déclencher Ipv6pReassemblyTimeout, l'expéditeur du fragment doit être inactif pendant 1 minute. Notre stratégie est alors :

• Envoyer des options de destination malformées pour déclencher IppSendError, suivies d'un paquet fragmenté
• Espérer que les deux paquets soient fusionnés et que l'objet du second paquet voie ses données et son offset réinitialisés
• Provoquer le sous-dépassement dans Ipv6pReceiveFragment et créer un nouvel objet de réassemblage avec une longueur de données de fragment qui est une valeur élevée sur 16 bits
• Attendre 1 minute sans envoyer d'autres paquets pour que Ipv6pReassemblyTimeout soit déclenché.
• Provoquer un dépassement d'entier dans le calcul de la taille du tampon dans Ipv6pReassemblyTimeout et déclencher un débordement de tampon basé sur le tas.

Les paquets du script sont envoyés en rafale afin d'augmenter les chances qu'ils soient fusionnés. La charge utile principale est assez simple :

• Paquet IPv6 avec un en-tête d'extension "destination options" contenant des données d'options malformées qui déclencheront une erreur d'analyse
• Fragment IPv6 n°1, que nous espérons être concaténé au premier paquet
• Fragment IPv6 n°2 (même id), qui peut également être concaténé aux deux premiers, mais dont le but principal est de compléter le 2e fragment afin que des erreurs ne soient pas générées en cas de traitement normal

Nous définissons également manuellement les champs hop limit et flow label de l'en-tête IPv6. Rappelons que les données du paquet en mémoire tampon sont réinitialisées à cause de la vulnérabilité. Cela signifie que, lors du traitement du paquet fragmenté, l'en-tête IPv6 sera interprété comme des données d'en-tête de fragment. Le champ hop limit de l'en-tête IPv6 sera interprété comme l'un des bits du champ id de l'en-tête de fragment. En le modifiant, nous nous assurons de déclencher la vulnérabilité pour plusieurs fragments différents et de provoquer plusieurs corruptions différentes, augmentant ainsi les chances d'un crash (après tout, c'est un PoC). Le champ flow label de l'en-tête IP sera interprété comme les champs offset et "more indicator" de l'en-tête de fragment. En le définissant sur 1, nous indiquons qu'il y a d'autres en-têtes à venir (d'où la possibilité de déclencher Ipv6pReassemblyTimeout plus tard) et que l'offset est nul (puisque c'est le premier paquet avec un tel id qui arrive).

remarques

• Ce qui précède n'est qu'une stratégie pour exploiter le problème introduit en déclenchant la vulnérabilité. J'ai utilisé cette stratégie car elle était assez directe et je ne voulais pas perdre de temps à explorer d'autres possibilités. Je ne serais pas surpris que d'autres personnes proposent bientôt des stratégies bien plus élégantes.
• Ce que la vulnérabilité nécessite :
  • Capabilité IPv6 sur le système cible, capacité à recevoir des paquets (avant le pare-feu)
  • Capacité à faire fusionner les paquets envoyés par le système cible dans une certaine mesure. Certaines paires adaptateur + pilote sont très enclines à le faire, tandis que d'autres semblent plus hésitantes. Il pourrait exister des astuces ou des chaînes de paquets spéciales permettant de faire fusionner les paquets par le RSC de Windows indépendamment de l'adaptateur ou de l'état du réseau, mais je n'ai aucune preuve de cela.
• Ce que la vulnérabilité ne nécessite pas :
  • L'envoi de paquets en rafale, le PoC ne le fait que pour augmenter les chances de fusion et déclencher plusieurs corruptions à titre de démonstration.
  • Des situations de forte charge sur le système cible, car la fusion peut se produire dans de nombreuses situations différentes.
  • Des paramètres spécifiques sur le système cible, autres que l'activation de l'IPv6.
  • (Très probablement) Attendre une minute pour déclencher la corruption, je n'ai utilisé cette stratégie d'abus de la vulnérabilité que parce qu'elle était la plus simple. Il y a de très fortes chances que la situation problématique causée par la vulnérabilité puisse être exploitée de manière plus directe.
  • (Très probablement) Les paquets unicast, je les utilise car le chemin de code que nous utilisons dans Ipv6pReassemblyTimeout exige que le paquet fragment d'origine soit envoyé en unicast.

dépannage

Si cela ne fonctionne pas, cela peut être parce que :

• Le système cible n'est pas joignable en IPv6 :
  • Désactivez le pare-feu Windows
  • ping -6 {ipv6_address} depuis le PC hôte
  • Assurez-vous d'obtenir une réponse
  • Réactivez le pare-feu
• Le système cible ne reçoit pas les paquets
  • Installez Wireshark sur le système cible et vérifiez que les paquets envoyés par le script arrivent
• scapy signale "Mac address to reach destination not found. Using broadcast."
  • Vous devez trouver l'adresse MAC de la machine cible
  • Cela peut être fait en exécutant la commande ping ci-dessus et en vérifiant la réponse dans Wireshark (champ adresse source eth)
  • Vous pouvez aussi utiliser scapy : Ether(raw(sr1(IPv6(dst={your_dest_ip})/ICMPv6EchoRequest()))).src, mais cela ne fonctionne pas parfois
  • Une fois que vous avez l'adresse MAC, placez-la dans le champ mac_addr du script et exécutez le script
• Les paquets ne sont pas fusionnés sur le système cible
  • Selon votre adaptateur réseau / pilote, il peut être difficile d'amener Windows à fusionner les paquets sans recourir à quelque chose comme inonder la cible à la manière d'un DDoS.
  • Vous pouvez essayer de modifier les paramètres de votre adaptateur, par exemple "Packet Coalescing", "Interrupt Moderation", "Interrupt Moderation Mode", "Recv Segment Coalescing", selon ceux qui sont disponibles. Par exemple, définir "Interrupt Moderation Mode" sur "Extreme" sur mon serveur dédié rend la vulnérabilité reproductible.
• Si tout le reste échoue, vous pouvez attacher un débogueur de noyau et vérifier quelques points :
  • Est-ce que tcpip!Ipv6pReceiveDestinationOptions -> tcpip!Ipv6pProcessOptions -> tcpip!IppSendErrorList est atteint ?
  • Placez un point d'arrêt sur tcpip!Ipv6pProcessOptions et vérifiez si est nul tout le temps. Si oui, alors les paquets ne sont pas fusionnés pour une raison quelconque.