Log4j 2.17.1 maintenant disponible, corrige un nouveau bug d’exécution de code à distance

log4j

Apache a publié une autre version de Log4j, 2.17.1 corrigeant une vulnérabilité d’exécution de code à distance (RCE) nouvellement découverte dans 2.17.0, suivie comme CVE-2021-44832.

Avant aujourd’hui, 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é.

Cinquième Log4j CVE en moins d’un mois

L’exploitation massive de la vulnérabilité Log4Shell d’origine (CVE-2021-44228) par des acteurs malveillants a commencé vers le 9 décembre, lorsqu’un Exploiter le PoC car il a fait surface sur GitHub.

Compte tenu de la vaste utilisation de Log4j dans la majorité des applications Java, Log4Shell est rapidement devenu un cauchemar pour les entreprises et les gouvernements du monde entier.

Alors que le risque critique posé par l’exploit Log4Shell d’origine est primordial, des variantes plus légères de la vulnérabilité sont apparues dans les versions Log4j, notamment les versions 2.15 et 2.16, que l’on croyait auparavant entièrement corrigées.

EZpublish-france.fr a signalé précédemment quatre CVE différents affectant Log4j et un découvert dans le cadre « logback ». Après la découverte d’une faille DoS dans la version 2.16, le conseil s’est rapidement déplacé vers la mise à niveau vers la version 2.17.0, considérée comme la plus sûre de toutes.

Mais maintenant, une cinquième vulnérabilité – une faille RCE, suivie comme CVE-2021-44832 a été découverte dans 2.17.0, avec un correctif appliqué au dernière version 2.17.1 qui est sorti.

Classé « modéré » en gravité et attribué 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 », indique la description du problème vue par EZpublish-france.fr.

« 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. »

Chercheur en sécurité Checkmarx Yaniv Nizry revendiqué pour avoir signalé la vulnérabilité à Apache :

Le tweet de Nizry a rapidement explosé dans le trafic, attirant des remarques et 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 Visage pensif #log4j », 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 indique « LOG4J NE PEUT PAS ÊTRE RÉPARÉ, NE L’UTILISEZ PAS POUR RIEN. » » raillé une autre.

Expert en sécurité Kevin Beaumont étiqueté l’instance une autre « divulgation Log4j échouée en mouvement » pendant les vacances.

Divulgué trop tôt ?

Au moment du tweet de Nizry, EZpublish-france.fr n’a pas vu d’avis ou de mémo officiel indiquant la présence d’un bug 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 bug 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 de la menace, des pirates informatiques soutenus par l’État aux gangs de ransomware et autres pour injecter des mineurs Monero sur des systèmes vulnérables.

Le gang de ransomware Conti a été vu en train de surveiller des serveurs VMWare vCenter vulnérables. Considérant que, les attaquants violant la plate-forme crypto vietnamienne ONUS via log4shell a demandé une rançon de 5 millions de dollars.

Les utilisateurs de Log4j doivent immédiatement passer à la dernière version version 2.17.1. Les versions rétroportées 2.12.4 et 2.3.2 contenant le correctif devraient également être publiées sous peu.

EZpublish-france.fr a contacté Checkmarx pour commentaires avant d’écrire et nous attendons leur réponse.