Digest de sécurité Linode 12-19 décembre 2021

Note : Ce billet a été mis à jour le 15 décembre 2021 et à nouveau le 20 décembre 2021.

Cette semaine, nous allons parler de la vulnérabilité de Log4j2 qui a poussé de nombreuses organisations à mettre en place des correctifs pour leurs systèmes, mais d'abord, nous allons répondre à certaines préoccupations de nos clients concernant cette vulnérabilité.

La réponse de Linode à Log4j2 

• Nous avons évalué de manière approfondie l'étendue du risque et l'impact de cette vulnérabilité critique de type "zero-day" sur l'ensemble de notre infrastructure dans les premières heures qui ont suivi sa publication, le vendredi 10 décembre.
• Nous avons observé les tentatives d'exploitation échouées à l'aide de notre architecture de contrôle de sécurité approfondie de la défense.
• Nous n'avons pas observé d'Indicateurs de compromission liés à cette vulnérabilité dans notre environnement et nous surveillons en permanence notre infrastructure pour les IoC connus concernant cette vulnérabilité et d'autres.

Vulnérabilité critique d'exécution de code à distance de Log4j2 (CVE-2021-44228)

Log4j2 est le successeur de l'utilitaire de journalisation Log4j, couramment utilisé sur Apache . Ce composant est écrit en Java et fait partie des services de journalisation Apache . Selon Oracle, The Java Naming and Directory Interface (JNDI) est une interface de programmation d'applications (API) qui fournit des fonctionnalités de nommage et d'annuaire aux applications écrites en Java. 

La semaine dernière, Apache a publié dans sa page de vulnérabilités de sécurité Log4j que les versions de log4j-core entre 2.0-beta9 et 2.14.1 contiennent une vulnérabilité sérieuse. Cette vulnérabilité permet aux attaquants qui peuvent contrôler les messages de log ou les paramètres des messages de log d'exécuter du code arbitraire chargé à partir de serveurs LDAP. En pratique, ceci est exploitable par des attaquants externes. Cette vulnérabilité a reçu un score CVSS de 10 sur 10 car elle permet à un attaquant d'exécuter du code arbitraire sur chaque système affecté. Ce problème est atténué par la mise à jour 2.15, qui a désactivé le comportement de consultation de JNDI sur la base de deux problèmes Jira au début du mois de décembre et à la fin du mois de novembre. Apache a également publié la version 2.17 pour résoudre d'autres problèmes qui ont été découverts ultérieurement au sujet du composant.

Effets de la vulnérabilité

Log4j2 est un cadre de journalisation Java populaire utilisé par de nombreux fournisseurs dans de nombreux produits. Cette vulnérabilité peut être facilement exploitée en manipulant la chaîne User-Agent des en-têtes de requête HTTP et en envoyant la requête aux systèmes vulnérables. Bien que la chaîne User-Agent ne soit pas le seul en-tête pouvant être utilisé dans ce type d'attaque, une charge utile malveillante fera en sorte que le composant Log4j2 vulnérable déclenche une recherche JNDI sur le serveur malveillant. Lorsque l'URI malveillant intégré dans les en-têtes HTTP contient le chemin d'un fichier de classe Java malveillant, ce fichier est injecté dans le processus du serveur et permet à l'attaquant d'accéder au système affecté. De multiples charges utiles et contournements sont actuellement observés dans la nature, ce qui rend plus difficile la protection contre ce problème à l'aide de mécanismes de défense courants.

Un schéma de l'attaque

Le diagramme suivant, élaboré par l'équipe d'intervention en cas d'urgence informatique du gouvernement suisse, peut aider à comprendre le fonctionnement de l'attaque et la manière de l'atténuer.

Produits concernés

De nombreux fournisseurs ont publié des déclarations pour aider à atténuer cette vulnérabilité, et ces déclarations pourraient être une ressource utile pour nos clients concernés. Vous pouvez trouver les liens ci-dessous pour en savoir plus sur les produits concernés par les fournisseurs. Il ne s'agit pas d'une liste exhaustive de tous les produits concernés. Pour une liste complète des fournisseurs concernés et de leurs produits, vous pouvez consulter la liste établie par SwitHak sur Github ou une autre liste partagée par TechSolvency.

• Apache
• Atlassian
• Elastic
• Cisco
• CloudFlare
• Debian
• GitHub
• Minecraft
• Oracle
• RedHat
• L'oignon de la sécurité

Méthodes officielles d'atténuation

Sur la page de sécurité de Log4j, Apache indique qu'il existe plusieurs méthodes pour remédier à cette vulnérabilité, mais il convient de noter que ces méthodes peuvent ne pas fonctionner de la même manière dans tous les produits vulnérables. Veuillez vous référer à la déclaration de sécurité du fournisseur concernant la vulnérabilité pour plus d'informations.

• Les utilisateurs de Java 8 (ou d'une version ultérieure) doivent effectuer une mise à niveau vers la version 2.17.0 pour corriger cette vulnérabilité ainsi que d'autres vulnérabilités découvertes récemment.
• Les utilisateurs qui ont besoin de Java 7 doivent passer à la version 2.12.2.
• Si ces deux étapes ne sont pas possibles, l'atténuation est de supprimer la classe JndiLookup du classpath (indiquée comme log4j-core-*.jar) en utilisant une commande similaire à celle ci-dessous :

zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class

Nous sommes fiers de partager ces connaissances avec notre communauté afin de l'aider à atténuer les vulnérabilités, qu'elles soient aussi critiques que celle-ci ou moins importantes. N'hésitez pas à laisser un commentaire ci-dessous pour nous faire part de vos réflexions et suggestions.