Détection de CVE-2021-31166 – Vulnérabilité HTTP
Dans ce blog, nous visons à donner un petit aperçu d’une partie du cycle de vie de la réponse de Corelight Lab à une vulnérabilité HTTP critique.
Il s’agit d’une bonne démonstration de la nature évolutive du paysage des menaces.
Il sert également à mettre en évidence certains problèmes que nous suivons lors du développement de ces packages.
Semblable à notre réponse à l’incident de Solarwinds [1] [2] [3] , il y a deux questions principales sur lesquelles nous aimerions nous concentrer :
- Comment savoir si votre entreprise utilise un système vulnérable ?
- Comment savoir si un adversaire cherche cet exploit ?
Dans le Patch Tuesday de mai, Microsoft a publié un correctif critique pour les systèmes exécutant une version vulnérable d’une fonction dans HTTP.sys .
La vulnérabilité est non authentifiée, triviale, vermifuge et est évaluée à un score CVE de 9,8.
Vous pouvez lire les détails sous-jacents de la vulnérabilité ici .
L’essence de la vulnérabilité réside dans la façon dont le code gère l’en – tête HTTP Accept-Encoding .
L’en-tête Accept-Encoding est simplement un en-tête envoyé par le client pour informer le serveur des algorithmes de compression que le client peut comprendre.
Si le client peut accepter plusieurs algorithmes, ceux-ci sont séparés par des virgules, et c’est là que réside la vulnérabilité CVE-2021-31166.
L’exploit est déclenché simplement s’il y a des espaces (ou rien du tout) entre les virgules dans l’en-tête Accept-Encoding.
Figure 1 : en-tête Accept-Encoding conçu avec des virgules
Une preuve de concept (POC) fonctionnelle de l’exploit DoS est devenue publique quelques jours après la publication du correctif.
C’est à ce moment-là que les “Corelighters” Anthony Kasza , Alex Kirk , Aaron Soto et Paul Dokas sont passés à la vitesse supérieure , dans le but de produire rapidement à la fois un package Zeek et une règle Suricata pour aider les défenseurs.
CoreLight a développé une solution initiale dans les heures qui ont suivi la publication du POC, puis continué à tester et à peaufiner avant d’ouvrir le contenu.
Vous pouvez trouver ce contenu Zeek et Suricata ici https://github.com/corelight/CVE-2021-31166 .
Pour donner une idée des différentes facettes examinées par CoreLight au cours de l’élaboration de ces réponses, voici quelques considérations :
La logique de détection produit-elle un nombre acceptable de faux positifs ?
Notre expérience a montré que sans tester les détections dans les réseaux à grande échelle du monde réel , même une logique de détection très spécifique peut déclencher des faux positifs de manière surprenante.
Peu de détections sont garanties à 100% pour ne pas créer de faux positifs, mais CoreLight vise à réduire le nombre de faux positifs au niveau minimum absolu possible.
Détecte-t-il des variantes subtiles du POC ?
Ici, la solution vise à réduire le cas de faux négatifs à zéro, c’est-à-dire que nous ne voulons pas manquer des détections car la logique est trop spécifique et fragile pour tenir compte des petites variations du vecteur d’attaque.
Pour atteindre cet objectif, nous emmenons le POC dans un environnement de test de laboratoire où nous testons plusieurs variantes subtiles de l’exploit et les lançons sur un système vulnérable.
Nous vérifions ensuite que notre contenu fournit toujours les avis/alertes attendus pour toutes ces variations.
Le défi de ce processus est que l’élargissement d’une détection pour inclure plus de variations de travail ouvre également la possibilité de plus de faux positifs.
L’optimisation des faux négatifs par rapport aux faux positifs implique d’apprivoiser les forces opposées, et obtenir cet équilibre dans les limites acceptables peut parfois se révéler être tout un “Art” ou une sacrée performance.
Quelles sont les caractéristiques de performance de la détection ?
C’est là que l’expérience prend toute son importance.
L’aspect clé est de s’assurer que les ressources consommées par la logique de détection sont conformes aux attentes.
Nous dépensons une énergie importante ici; car avec le contenu Zeek et Suricata, il y a souvent des subtilités qui font ou défont une stratégie de détection.
Voici quelques exemples de conseils pratiques sur les performances de Zeek dans un blog récent .
Pour en revenir au cycle de vie de l’exploit, quelques jours après la publication du POC d’exploit (qui se concentrait largement sur le serveur IIS), il est devenu connu que la fonction d’analyse d’acceptation d’encodage vulnérable est également utilisée par le service Windows Remote Management (WinRM) .
Qu’est-ce que WinRM?
Pour les besoins de ce blog, nous nous en tiendrons à une brève explication, mais vous pouvez en savoir plus à ce sujet ici .
La gestion à distance de Windows (WinRM) s’exécute par défaut sur le port TCP 5985.
Elle peut s’exécuter à la fois sur les serveurs et les bureaux identifiée comme une API SOAP conçue pour que les systèmes Windows puissent être gérés à l’aide de scripts tels que Powershell.
Remarque : WinRM peut également être utilisé par des attaquants pour un mouvement latéral, selon https://attack.mitre.org/techniques/T1021/006/ . Il s’agit d’une tactique efficace et parfois appelée « living off the land » – dans la mesure où l’outil utilisé pour le mouvement latéral (WinRM) existe déjà de manière native sur le système.
Le contenu du trafic WinRM est chiffré en dehors de la session HTTP, mais le point de terminaison de l’API lui-même fonctionne sur le texte en clair HTTP.
Plus important encore, s’il exécute la version vulnérable de HTTP.sys sur le port 5985, il est également exploitable.
Peu de temps après que la possibilité de winRM a été signalée en utilisant le code vulnérable dans HTTP.sys , l’exploit existant a été adapté au service WinRM.
Les chercheurs ont également utilisé shodan.io pour évaluer combien de systèmes sur Internet exposent WinRM :
Figure 2 : périphériques WinRM exposés à Internet (source : shodan.io )
Notez que tous ces systèmes n’auront pas la version vulnérable de HTTP.sys, mais cela sert à quantifier l’étendue de l’exposition de WinRM lui-même.
C’est certainement assez de contexte pour pouvoir s’assurer que cette logique de détection résiste à WinRM par rapport à IIS.
Il faut donc vérifié en premier les en-têtes du serveur du port 5985 sur notre machine victime du laboratoire, pour s’assurer que le port est ouvert et qu’il sert les en-têtes attendus de WinRM :
Figure 3 : en-têtes de serveur WinRM
Ensuite, il faut tester plusieurs variantes de l’exploit contre WinRM sur la machine victime et ainsi constater que le contenu Zeek et Suricata déjà publié il y a quelques jours détectait également le scénario WinRM.
Cela est largement dû à la capacité de Zeek à détecter et à analyser le trafic HTTP sur n’importe quel port.
Le graphique suivant montre à quel point l’exploit est trivial, le redémarrage de la machine Windows qui en résulte, ainsi que les avis et alertes fournis par notre package Zeek avec la règle Suricata.
Figure 4 : Flux d’attaquants/victimes avec les sorties Zeek et Suricata
Figure 5 : Exemple d’avis Zeek généré par une tentative d’exploit
Figure 6 : Exemple d’alerte Suricata générée par une tentative d’exploit
Si vous avez lu jusqu’ici, vous serez peut-être intéressé par la quantité d’activité WinRM que vous avez sur votre réseau d’entreprise.
Indépendamment de l’existence de l’exploit, il est toujours utile de comprendre l’étendue des protocoles de gestion, en particulier lorsqu’ils pourraient être utilisés par des adversaires pour un mouvement latéral.
Si vous avez des journaux Zeek, vous pouvez vérifier http.log pour certains artefacts WinRM courants.
Notez que s’il existe d’autres moyens de découvrir l’activité WinRM, ces indicateurs simples sont fournis par Zeek par défaut.
Tableau 1 : Exemples d’artefacts WinRM dans Zeek http.log
Corelight Labs continuera à surveiller cette vulnérabilité, en particulier pour tout développement impliquant un exploit de code à distance ou un nouveau vecteur d’attaque.
Si ou quand cela se produit, Corelight Labs testera et modifiera à nouveau le contenu si nécessaire.
En attendant, si vous avez des suggestions ou des commentaires, n’hésitez pas à nous contacter !
Pour plus d’informations concernant les produits : https://corelight.com/products/
Source : CoreLight
Pour plus d’informations concernant les solutions
