Tout le monde a déjà entendu parler du jour zéro critique de log4j. Surnommée « Log4Shell » et « Logjam », la vulnérabilité a mis le feu à Internet.
Jusqu’à présent, la vulnérabilité log4j, identifiée comme CVE-2021-44228, a été exploitée 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.
L’utilisation de Log4j est endémique parmi de nombreux produits logiciels et plusieurs avis de fournisseurs ont depuis fait surface. Et, il semble maintenant, le « logback » n’est pas non plus si immunisé.
Ci-dessous, nous résumons les multiples CVE pertinentes identifiées jusqu’à présent, et de très bonnes raisons d’abandonner log4j version 2.15.0, en faveur de 2.16.0.
De quoi dois-je me préoccuper pour tous les CVE ?
Tout a commencé jeudi dernier, le 9 décembre, lorsqu’un Exploiter le PoC pour le hit zéro jour critique de Log4j GitHub.
Ce qui a suivi était la vulnérabilité divulgation et balayage de masse activité des attaquants ciblant les serveurs vulnérables.
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.
Vous trouverez ci-dessous les CVE dans l’ordre de leur apparition que vous devez connaître :
- CVE-2021-44228 [Critical]: La vulnérabilité d’origine ‘Log4Shell’ ou ‘logjam’ est une désérialisation non fiable défaut. Classé critique en gravité, celui-ci obtient un 10 sur le CVSS à l’échelle et accorde des capacités d’exécution de code à distance (RCE) aux attaquants non authentifiés, permettant une prise de contrôle complète du système.
Rapporté par Chen Zhaojun de l’équipe de sécurité cloud d’Alibaba à Apache le 24 novembre, CVE-2021-44228 a un impact sur les configurations par défaut de plusieurs frameworks Apache, notamment Apache Struts2, Apache Solr, Apache Druid, Apache Flink et autres.
Étant la plus dangereuse de toutes, cette vulnérabilité se cache dans le log4j-core composant, limité aux versions 2.x : de 2.0-beta9 jusqu’à et y compris 2.14.1. Un correctif pour Log4Shell a été déployé dans la version 2.15.0 mais jugé incomplet (continuez à lire).
Florian Roth, analyste sur les menaces, a partagé les règles Sigma [1, 2] qui peut être utilisé comme l’un des moyens de défense.
- CVE-2021-45046 [Low]: Classé faible en gravité, celui-ci est une faille de déni de service (DoS) avec un score de seulement 3,7. La faille est survenue à la suite d’un correctif incomplet qui est entré dans 2.15.0 pour CVE-2021-44228. Alors que le correctif appliqué à 2.15.0 a largement résolu la faille, ce n’était pas tout à fait le cas pour certaines configurations autres que celles par défaut.
Log4j 2.15.0 fait « une tentative au mieux » pour restreindre les recherches LDAP JNDI à hôte local par défaut. Cependant, les attaquants qui contrôlent les données d’entrée de Thread Context Map (MDC) peuvent créer des charges utiles malveillantes via les modèles de recherche JNDI pour provoquer une attaque DoS. Cela s’applique aux configurations autres que celles par défaut dans lesquelles une disposition de modèle autre que celle par défaut utilisant soit une recherche de contexte, par exemple $${ctx:loginId}, soit un modèle de mappe de contexte de thread (%X, %mdc ou %MDC).
« Log4j 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 », indique l’avis NVD. Pour ceux sur la branche 2.12.1, un correctif a été rétroporté en 2.12.2.
- CVE-2021-4104 [High]: Avons-nous dit que les versions Log4j 2.x étaient vulnérables ? Qu’en est-il de Log4j 1.x ?
Alors que l’on pensait auparavant qu’il était sûr, Log4Shell a également trouvé un moyen de se cacher dans l’ancien Log4j. Essentiellement, la configuration non par défaut des instances Log4j 1.x utilisant le JMSAppender classe deviennent également sensibles à la faille de désérialisation non fiable.
Bien qu’il s’agisse d’une variante moins sévère du CVE-2021-44228, ce CVE impacte néanmoins toutes les versions du log4j:log4j et org.apache.log4j:log4j composants pour lesquels seules les versions 1.x existent. Parce que ce sont fin de vie versions, un correctif pour la branche 1.x n’existe nulle part, et il faut passer à log4j-core 2.16.0.
- CVE-2021-42550 [Moderate]: Il s’agit d’une vulnérabilité dans le cadre de journalisation Logback. Successeur de la bibliothèque Log4j 1.x, Logback prétend reprendre « là où log4j 1.x s’arrête ».
Jusqu’à la semaine dernière, Logback a également vanté cela étant « sans rapport avec log4j 2.x, [logback] ne partage pas ses vulnérabilités. »
Cette hypothèse s’est rapidement estompée lorsqu’il a été découvert que CVE-2021-4104 avait également un impact sur Log4j 1.x et que la possibilité d’un impact potentiel sur Logback était évalué. Les nouvelles versions de Logback, 1.3.0-alpha11 et 1.2.9 corrigeant cette vulnérabilité moins grave ont maintenant été publié.
- Un CVE de plus…? Continue de lire.
Ditch Log4j 2.15 : Exfiltration DNS & RCE possible
Log4j 2.15.0 pourrait contenir des vulnérabilités encore plus graves que celles découvertes jusqu’à présent, c’est pourquoi 2.16.0 est de loin un pari plus sûr.
En raison du CVE-2021-45046 décrit ci-dessus, l’impact maximal de la faille semblait initialement être le DoS, mais cette hypothèse évolue, a appris EZpublish-france.fr.
La société de sécurité cloud Praetorian a démontré comment les versions de Log4j 2.15.0 pouvaient toujours être utilisées à mauvais escient pour l’exfiltration de données DNS à partir d’hôtes externes, et travaille avec Apache pour une divulgation coordonnée.
Dans une interview par e-mail avec EZpublish-france.fr, le principal ingénieur en sécurité de Praetorian, Anthony Weems fait la lumière sur la recherche :
« Le Prétorien article de blog est en réponse à CVE-2021-45046, qui s’applique à Log4j version 2.15. La description CVE indique que, lors de l’utilisation d’un type spécifique de disposition de modèle, cette vulnérabilité peut conduire à un déni de service. La raison pour laquelle ils déclarent qu’il s’agit uniquement de DoS est due au hôte local liste d’autorisation », a déclaré Weems à EZpublish-france.fr.
« Nous avons développé un contournement pour cette liste d’autorisation ‘localhost’ et envoyé les détails à Apache. Au minimum, cela signifie que les systèmes vulnérables à CVE-2021-45046 ne sont pas seulement vulnérables au DoS, mais aussi à l’exfil DNS d’un environnement potentiellement sensible variables. »
Praetorian a partagé une vidéo PoC démontrant juste ceci :
« Apache a confirmé la réception de notre article ; si cela mérite une modification du CVE ou un nouveau CVE est une bonne question – cependant, l’action requise par les défenseurs est claire dans les deux cas : passer à 2.16.0 où jndi est désactivé par défaut est le plan d’action le plus sûr et c’est l’approche que nous recommandons à nos clients », a conclu Praetorian dans sa déclaration à EZpublish-france.fr.
De plus, au moment de la rédaction de cet article, EZpublish-france.fr a rencontré plusieurs chercheurs en sécurité affirmant qu’il est possible d’obtenir un RCE complet, même avec 2.15.0.
« Voici un PoC sur la façon de contourner autoriséLdapHost et Cours autorisés vérifie dans Log4J 2.15.0. atteindre le RCE… et contourner Cours autorisés choisissez simplement un nom pour une classe dans le JDK. La désérialisation se produira comme d’habitude », explique le chercheur Márcio Almeida :
Cela se produit parce que la vérification a été effectuée. la https://t.co/KrgP5x639QLa méthode .URI getHost() renvoie la valeur avant le # en tant qu’hôte réel. Mais le résolveur JNDI/LDAP résoudra la chaîne complète du nom d’hôte en tentant de se connecter au serveur LDAP malveillant. 2/n pic.twitter.com/HuZtYekuHw
– Marcio Almeida (@marcioalm) 17 décembre 2021
De même, Alvaro Muñoz de GitHub Security Lab a partagé le succès en contournant les correctifs apportés à 2.15.0 pour réaliser l’exécution de code à distance :
@_atorralba
et j’ai juste réussi à contourner les vérifications allowLdapHost et allowClasses. 2.15 sans atténuation formatMsgNoLookups est toujours vulnérable à RCE. 2.15.0 sans ces atténuations n’est vulnérable que si les attaquants peuvent contrôler les parties non-messages de la mise en page du modèle– Alvaro Muñoz (@pwntester) 16 décembre 2021
« En remarque, les paramètres par défaut ne colleront pas. La recherche doit être générée en spécifiant % m {recherches} ou par une méthode telle que CVE-2021-45046, » dit chercheur en sécurité RyotaK, ajoutant à la recherche de Muñoz.
Le pire scénario possible résultant de Log4j 2.15.0 n’a pas encore été entièrement déterminé, mais il suffit de dire qu’il ne semble pas qu’il se limite au DoS.
Alors que la situation continue d’évoluer, les organisations et les développeurs sont encouragés à passer à la version 2.16.0 et à continuer à surveiller le Log4j d’Apache. page de conseil pour les mises à jour.