Arrêt de QUIC : vulnérabilité DoS dans les serveurs Windows exécutant SMB sur QUIC
Synthèse
Ben Barnea, chercheur chez Akamai, a découvert une vulnérabilité importante dans Windows Server 2022 qui a été classée CVE-2023-24898 avec un score de base de 7,5.
La vulnérabilité est une vérification manquante dans une allocation de mémoire tampon dans le pilote srvnet.sys.
Cette vulnérabilité peut entraîner des attaques par déni de service (DoS) à distance contre les machines Windows Server 2022. La vulnérabilité peut être déclenchée par un pirate non authentifié sur Internet.
Seuls les serveurs qui utilisent SMB sur QUIC, une fonctionnalité relativement nouvelle, sont vulnérables. Pour activer cette fonctionnalité, le serveur doit être un Windows Server 2022 Azure Edition.
Ces vulnérabilités ont été révélées de manière responsable à Microsoft et corrigées dans le Patch Tuesday de mai 2023.
Nous mettons à la disposition des utilisateurs d'Akamai Guardicore Segmentation une requête Insight qui leur permet de détecter les serveurs potentiellement vulnérables dans leurs réseaux.
Introduction
QUIC est un protocole de couche de transport relativement nouveau qui a été conçu à l'origine par Google, mais qui a été mis en œuvre à plusieurs reprises. QUIC a été conçu pour fournir une connexion plus fiable et sécurisée tout en surmontant les problèmes Internet courants, tels que la latence et la perte de paquets. Il est transmis par UDP.
La mise en œuvre de QUIC par Microsoft s'appelle MsQuic. Windows intègre également QUIC, l'utilisant comme couche de transport pour le protocole SMB (une fonctionnalité appelée SMB sur QUIC) et avec HTTP/3 dans IIS. SMB sur QUIC n'est disponible que dans Windows Server 2022 Azure Edition, tandis que HTTP/3 est disponible pour tous les déploiements IIS fonctionnant sur Windows Server 2022.
La vulnérabilité dont il est question dans cet article est située dans le pilote qui met en œuvre la couche de transport de SMB, srvnet.sys.
La vulnérabilité
Pour conserver l'état d'une connexion, QUIC utilise un identifiant de connexion qui désigne de manière unique une connexion entre le client et le serveur. Un client peut créer plusieurs connexions simultanées. Une connexion QUIC est également multiplexée, c'est-à-dire qu'un client et un serveur peuvent échanger des données via plusieurs flux simultanément sur la même connexion.
Le code pour SMB sur QUIC est implémenté dans srvnet.sys. Lorsque le serveur reçoit de nouvelles données sur un flux, la fonction SrvNetQuicServerReceiveEvent est appelée. Cette fonction a pour but de lire un message SMB complet envoyé par le client. Après avoir réussi, elle transfère le message dans la liste des messages SMB en vue d'un traitement ultérieur.
Pour lire un message SMB, le code essaie d'abord de lire la taille du message SMB, qui est représentée par un entier de quatre octets. S'il y parvient, il vérifie que la taille n'est pas supérieure à la taille maximale autorisée pour une allocation. Si la vérification est réussie, le code alloue une mémoire tampon de cette taille et tente de lire les octets restants du paquet dans la mémoire tampon nouvellement allouée. S'il parvient à finir de lire tout le message SMB, il indique à la couche SMB qu'un nouveau message SMB a été reçu.
La structure d'un message SMB est illustrée à la Figure 1.
Figure 1 : Structure d'un message SMB dans srvnet.sys
La vulnérabilité se produit si moins de quatre octets sont reçus pour la taille du message SMB (Figure 2). Dans ce cas, le code enregistrera les X octets reçus et définira également PendingMessageSize à 4 moins X (X étant le nombre d'octets reçus pour la taille du message). La prochaine fois qu'un paquet sera reçu, il lira les 4 - X octets restants nécessaires à la taille du message SMB.
Figure 2 : Un paquet malveillant comporterait moins de quatre octets pour la taille du message
Une fois que le code a fini de lire la taille du message, il alloue immédiatement un message SMB sans vérifier cette taille par rapport à la taille maximale autorisée. Par conséquent, en envoyant la taille du message SMB en deux paquets au lieu d'un, un pirate peut contourner la vérification de la taille maximale autorisée et demander une allocation exceptionnellement élevée.
Exploitation
Pour transformer ce bogue en vulnérabilité DoS, il faut envoyer continuellement des paquets qui déclenchent le problème décrit.
Cependant, même en contournant la taille maximale autorisée, deux restrictions subsistent :
1. SrvNetAllocateBuffer a une limite stricte de 16 Mo pour les allocations.
2. Le nombre de connexions non authentifiées simultanées autorisées est limité en fonction de la mémoire vive disponible sur le serveur. Cette restriction limite l'exploitation aux serveurs ayant jusqu'à 32 Go de RAM. (Dans la section suivante, nous allons élaborer une théorie sur la manière dont cette limite peut être contournée.)
Pour exploiter cette vulnérabilité, nous avons d'abord essayé de créer plusieurs connexions et d'envoyer deux paquets chaque fois pour que le serveur alloue 16 Mo. La répétition de cette opération conduit à l'épuisement de la mémoire. Comme cette vulnérabilité se trouve dans un pilote et qu'elle s'exécute en mode noyau, l'ensemble du système devient instable et ne répond plus.
Une exploitation optimisée ?
Cette exploitation nécessite l'envoi de nombreux paquets. Nous pensons qu'en utilisant les fonctionnalités de QUIC, il est possible de réduire le nombre de paquets nécessaires.
Bien que QUIC permette l'envoi de plusieurs flux sur une seule connexion, il permet également de limiter ce nombre grâce à la propriété initial_max_streams_bidi . SMB sur QUIC limite à un le nombre de flux simultanés pour une connexion.
Bien que nous ne puissions pas améliorer l'exploitation en utilisant plusieurs flux simultanés, nous pouvons essayer de tirer parti de la vulnérabilité d'une manière différente. Au lieu de créer plusieurs flux concurrents, nous créons un paquet QUIC avec plusieurs trames, de sorte que la séquence suivante se produise en série et de manière répétée :
1. Création d'un flux
2. Déclenchement de l'allocation de 16 Mo par l'envoi de deux trames DONNÉES
3. Fermeture du flux
De cette manière, nous pouvons également contourner la limite des connexions non authentifiées. Nous vous invitons à relever ce défi.
Détection et prévention
Pour trouver un serveur SMB sur QUIC en cours d'exécution, les utilisateurs d'Akamai Guardicore Segmentation peuvent exécuter la simple requête Insight suivante :
select * from registry where
path="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableSMBQUIC" and data=1
Nous recommandons d'appliquer des correctifs à votre machine Windows Server, car il n'existe pas d'autres solutions pour pallier cette vulnérabilité, à l'exception de la désactivation de la fonction SMB sur QUIC.
Résumé
QUIC est un protocole réseau relativement nouveau qui garantit de meilleures performances et moins de latence. De toute évidence, il a déjà été adopté et incorporé dans deux protocoles très importants : IIS (pour HTTP/3) et SMB.
Nous pensons que QUIC constitue une nouvelle surface d'attaque intéressante dans Windows et de manière générale. En plus du problème décrit ici, une autre vulnérabilité, CVE-2023-23392, a été corrigée dans HTTP/3.
Nous encourageons les chercheurs à se pencher sur les différents composants qui utilisent MsQuic et sur MsQuic lui-même.
