Pourquoi nous ne scannerons pas /0 pour la faille log4shell – Blog

Le système de journalisation Apache log4j est affecté par un problème critique affectant des milliards d’appareils et de piles logicielles. Ce problème est décrit comme CVE-2021-44228. Après mûre réflexion, ONYPHE a décidé de ne pas analyser l’intégralité de l’espace d’adressage IPv4 pour détecter cette vulnérabilité. Voici notre communication expliquant notre position.

MISE À JOUR : 15/12/2021 : ajout de nouveaux dorks pour détecter les autres produits impactés. Consultez la liste à la fin de cet article.

Sur l’analyse HTTP en aveugle avec des milliards de requêtes

L’analyse de cette vulnérabilité à grande échelle pose plusieurs problèmes techniques. Le premier concerne le nombre de requêtes nécessaires pour vérifier tous les actifs potentiellement affectés. Selon nos données, plus de 183 millions de services répondent actuellement aux requêtes HTTP, et ce uniquement pour l’analyse IP directe (sans utiliser d’en-tête HTTP d’hôte virtuel). En comptant le nombre de domaines uniques connus de notre solution, nous pourrions ajouter plus de 160 millions de noms de domaine. Pour une analyse optimale, il faudrait envoyer deux requêtes pour les noms de domaine : une avec HTTP (port 80/tcp) et une autre avec HTTPS (port 443/tcp). Au final, cela représente plus de 500 millions de requêtes à envoyer. Sachant qu’environ 400 millions de noms de domaine sont actuellement enregistrés, nous devrions envoyer plus d’un milliard de requêtes. Ce chiffre n’est pas tenable dans un délai raisonnable, et ce, uniquement en considérant le protocole HTTP (les autres protocoles sont également impactés).

De plus, chaque application aura un chemin d’exploitation différent, car nous devons envoyer la vérification au bon champ cible (par exemple, un champ de connexion, car ce champ doit être enregistré par la bibliothèque pour être exploitable). Ce nombre de requêtes (plus d’un milliard) pourrait atteindre plusieurs milliards. En ne vérifiant pas correctement ce problème, nous pourrions tout simplement ne pas vérifier efficacement son existence ou son absence et donner une fausse impression de correctif, ce qui serait totalement contre-productif. Le gain pour nos clients est discutable.

Un autre aspect est la charge qu’implique une telle analyse pour la cyberdéfense. Aujourd’hui, la plupart des entreprises ont déployé des méthodes pour détecter les tentatives d’exploitation. L’envoi de milliards de requêtes générerait un nombre considérable d’alertes, mettant inutilement sous pression les équipes de cyberdéfense, qui n’ont plus besoin de ce surcroît de travail. Nous souhaitons contribuer positivement à l’écosystème de la sécurité de l’information, et non négativement.

Considérations relatives à l’analyse des vulnérabilités à grande échelle

Nous avons toujours défendu notre approche éthique de l’analyse active d’Internet : utilisation d’adresses IP fixes pour tous nos scanners, publication de cette liste, configuration d’un DNS inversé pointant vers le nom de domaine probe.onyphe.net et réponse à toutes les demandes d’abus en bloquant les réseaux lorsque les propriétaires légitimes le demandent. Nous souhaitons être identifiés afin d’informer les propriétaires de réseaux de notre intention et de leur fournir des outils pour se désinscrire le plus simplement possible. De plus, en envoyant des milliards de requêtes, nous recevrons un nombre considérable de demandes d’abus, nous mettrons sous pression les équipes de cyberdéfense et, à terme, nos scanners seront bloqués par de nombreuses entités, y compris nos clients. Ce n’est une bonne chose ni pour nous ni pour nos clients.

Nous disposons d’une liste de règles de scan éthique pour déterminer quand inclure un test dans notre catégorie d’informations Vulnscan. Nous avons créé cette list simple pour nous aider à décider, de manière reproductible, quand inclure (ou non) une vérification de vulnérabilité spécifique. Notre liste de contrôle est actuellement la suivante :

Vérification ciblée : les actifs potentiellement vulnérables sont testés ; nous ne souhaitons pas adopter une approche de vérification à l’aveugle ;
Tests inoffensifs : nous ne voulons pas prendre le risque de planter ou d’impacter les cibles ;
Tests non intrusifs : vérification généralement effectuée en se connectant simplement à une URL spécifique et en analysant le corps de la réponse HTTP ;
Vulnérabilités critiques : celles exploitées par les cybercriminels à des fins lucratives.

Le problème log4shell ne répond pas au point 1. Cependant, certaines méthodes de test de produits pourraient passer notre liste de contrôle et nous pourrions, à l’avenir, développer des tests spécifiques.

Ce que nous pourrions faire à ce sujet

Avec le temps, une liste plus ciblée de produits apparaîtra, avec des détails d’exploitation spécifiques. Par exemple, nous savons que VMware vCenter (et d’autres produits VMware) sont concernés par ce problème. Il est plus judicieux de ne vérifier que ces produits identifiés, car cela permet une vérification ciblée, améliorant ainsi le rapport bénéfice/risque pour nos clients et l’écosystème de sécurité informatique dans son ensemble. Comme l’a souligné un chercheur en sécurité :

« Attendons patiemment de véritables RCE non authentifiés ciblant des produits spécifiques.» — Félix Aimé.

Let's wait patiently for real unauthenticated RCEs targeting specific products.
— Félix Aimé (@felixaime) December 12, 2021

La meilleure ressource actuellement disponible pour identifier les produits impactés est la liste des chercheurs de SwitHak, disponible au lien suivant :

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Une autre ressource intéressante est celle du NCSC NL :

https://github.com/NCSC-NL/log4shell/tree/main/software

Nous mettrons à jour cet article de blog avec les experts ONYPHE afin de permettre à nos clients d’identifier leurs produits potentiellement impactés. Une fois cette liste établie, ils pourront vérifier le problème par eux-mêmes. C’est ce que nous considérons aujourd’hui comme la meilleure solution pour remédier à cette vulnérabilité critique qui nécessite une correction au plus vite.

N’hésitez pas à nous contacter à support[at]onyphe dot io si vous avez des questions ou des suggestions à ce sujet.