RPC Runtime, deuxième prise : découverte d'une nouvelle vulnérabilité
Synthèse
Ben Barnea, chercheur chez Akamai, a découvert une vulnérabilité importante dans la bibliothèque d'exécution RPC (Remote Procedure Call) : CVE-2022-22019, avec un score de base de 8,8.
Cette nouvelle vulnérabilité exploite un dépassement d'entier précédemment signalé à Microsoft et corrigé en avril 2022.
La nouvelle vulnérabilité a été corrigée dans le Patch Tuesday de mai de Microsoft.
Nous recommandons, en plus de la précédente liste de précautions de Microsoft, de corriger rapidement cette faille et de segmenter le réseau pour limiter tout risque de mouvement latéral.
Introduction
Le 12 avril 2022, Microsoft a publié des correctifs pour trois vulnérabilités dans la bibliothèque d'exécution RPC (Remote Procedure Call) (rpcrt4.dll). Les CVE suivants ont été affectés à ces vulnérabilités : CVE-2022-26809, CVE-2022-24492 et CVE-2022-24528. Les systèmes d'exploitation concernés sont Windows 7, 8, 10 et 11 et Windows Server 2008, 2012, 2019 et 2022.
L'exploitation de ces vulnérabilités permettrait à un pirate informatique distant non authentifié d'exécuter du code sur la machine vulnérable avec les privilèges du service RPC. Elle peut être utilisée à la fois pour pénétrer par effraction sur un réseau et effectuer des mouvements latéraux, et est donc prisée des pirates informatiques et des opérateurs de ransomware. De son côté, Microsoft a indiqué que ces vulnérabilités étaient susceptibles d'être exploitées. En raison de leur gravité (CVSS 9,8), nous avons décidé d'examiner en profondeur la bibliothèque corrigée et avons consigné nos résultats dans un précédent billet de blog sur le sujet.
Nous avons constaté que ces trois vulnérabilités étaient des dépassements d'entier et que le correctif ajoutait une vérification pour voir si un dépassement d'entier s'était produit. Ce correctif a permis à Microsoft d'empêcher l'exploitation de ces failles spécifiques. Cependant, au cours de notre enquête, nous avons détecté une vulnérabilité supplémentaire utilisant le dépassement d'entier de la même variable que celle découverte précédemment, non traitée par le nouveau contrôle.
Après avoir révélé l'affaire à Microsoft, nous pouvons décrire cette nouvelle vulnérabilité RPC. Elle a été découverte le jour où la mise à jour Patch Tuesday d'avril a été publiée, et traitée dans le correctif de mai. Cette vulnérabilité, présente à la fois dans le code serveur et dans le code client, a reçu une seule CVE :
Comprendre la vulnérabilité détectée
Pour comprendre la vulnérabilité RPC récemment découverte, examinons à nouveau la vulnérabilité corrigée en avril. Comme indiqué dans notre précédent billet de blog,le code de la bibliothèque d'exécution RPC contenait un bug de dépassement d'entier qui, lorsqu'exploité, pouvait entraîner un dépassement de tampon (situation dans laquelle les données sont copiées dans un tampon trop petit pour être rempli). Cela permet ensuite d'écrire des données hors des limites du tampon, sur la pile, et d'exécuter du code à distance.
Pour corriger cette vulnérabilité, un nouvel appel a été ajouté à ProcessReceivedPdu :
cet appel déclenche une fonction qui vérifie exactement si le paramètre entier a été dépassé :
En observant OSF_SCALL::GetCoalescedBuffer (la fonction dans laquelle se produit le dépassement de pile), nous pouvons également remarquer le nouveau contrôle :
GetCoalescedBuffer rassemble les fragments de tampons mis en file d'attente dans ProcessReceivedPdu. Le dépassement d'entier d'origine se produit lorsque la longueur totale des fragments mis en file d'attente est ajoutée à la longueur du tampon reçu en cours ; cet ajout entraîne un dépassement. En appelant une fonction qui contrôle le risque de dépassement, Microsoft a corrigé la vulnérabilité d'origine.
Toutefois, le correctif n'a traité que partiellement la vulnérabilité. Au cours de notre recherche, nous avons constaté que, juste avant d'allouer de la mémoire pour le nouveau tampon intégré, le code ajoute 24 octets supplémentaires à la taille d'allocation (vu ci-dessus avec l'appel à OSF_SCALL::TransGetBuffer). Ces 24 octets correspondent à la taille d'une structure appelée rpcconn_request_hdr_t, qui sert d'en-tête de tampon. Comme le correctif contrôle le dépassement d'entier avant d'ajouter la taille d'en-tête, il ne tient pas compte de cet en-tête, ce qui peut entraîner le même dépassement d'entier que celui que le correctif tentait de limiter.
Cette nouvelle vulnérabilité (une dans une fonction côté client et une autre côté serveur) a été corrigée. Le nouveau correctif ajoute un autre appel pour confirmer que l'ajout de 24 octets n'entraîne pas de dépassement.
Résolution
Appliquez les mises à jour de sécurité de mai qui corrigent cette vulnérabilité.
Bloquez le trafic vers le port TCP 445 de terminaux situés hors du périmètre de l'entreprise.
Limitez le mouvement latéral en autorisant le port TCP 445 entrant uniquement sur les machines où il est nécessaire (contrôleurs de domaine, serveurs d'impression, serveurs de fichiers, etc.).
Calendrier de divulgation
13 avril 2022 : Rapport envoyé à Microsoft
13 avril 2022 : Changement de statut (de Nouveau à Examiné / Reproduit)
22 avril 2022 : Changement de statut (de Examiné / Reproduit à Développé)
10 mai 2022 : Publication du correctif
Conclusion
L'application de correctifs est considérée comme l'une des mesures de sécurité les plus fondamentales ; une vulnérabilité est détectée, un correctif est publié, la vulnérabilité est corrigée. Bien que les attaques « zero day » attirent beaucoup l'attention des médias et du public en général, nous savons en tant que spécialistes que les principales vulnérabilités naissent de situations comme celle-ci. Cela illustre parfaitement la nécessité d'établir un processus continu et répétitif.
La communauté se concentre souvent sur le code original lors de la recherche de bugs, mais le développement de mises à jour et de correctifs peut également faciliter la collaboration et contribuer à garantir une meilleure sécurité globale.
Cette situation rappelle également fortement l'importance des chercheurs indépendants en matière de sécurité. Nous aimerions encourager d'autres chercheurs en sécurité à continuer d'analyser cette vulnérabilité et d'autres correctifs.
Vous avez des questions ou souhaitez discuter de ce que nous avons découvert ? Contactez-nous sur Twitter @Akamai_Research pour nous donner votre avis.
