Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

CVE-2021-44228 « LOG4SHELL » – Vulnérabilité critique dans LOG4J massivement exploitée

décembre 2021 par Akerva

Log4j est une bibliothèque logicielle utilisée dans de très nombreuses applications Java (près de 800 000 projets sur Github), permettant de gérer traces et journaux. Le 10 décembre 2021, la fondation Apache a publié la version 2.15.0 de log4j, qui corrige la vulnérabilité CVE-2021-44228, qui a été remontée par des chercheurs en sécurité informatique d’Alibaba fin novembre et publiée avec un score CVSS de 10.

Cette vulnérabilité concerne la fonctionnalité de résolution JNDI présente dans log4j. JNDI (Java Naming and Directory Interface) est une API de connexion permettant à une application Java de requêter des ressources tierces. En injectant une valeur spécifique reconnue par log4j, il est possible de forcer l’application utilisant la bibliothèque à exécuter des requêtes vers un serveur contrôlé par un tiers, via différents protocoles comme RMI, DNS, HTTP ou LDAP. Il est alors possible pour un attaquant d’extraire des secrets contenus par le serveur, comme le contenu de variables d’environnement par exemple. Cela est particulièrement sensible dans les environnements Cloud, où les variables d’environnement contiennent des informations d’authentification comme les AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY du Cloud d’Amazon, ou encore les variables utilisées pour paramétrer les conteneurs Docker/Kubernetes.

Cette vulnérabilité est particulièrement simple à exploiter, dans la mesure ou l’omniprésence de log4j (35 863 packages Java utilisent une version vulnérable de la bibliothèque sur Maven Central) rend le nombre d’applications vulnérables très important, mais également par la facilité d’exploitation. De très nombreux champs manipulables par un utilisateur sont souvent traités par log4j, comme un nom d’utilisateur, le contenu d’une requête, un « user-agent » d’un navigateur… Toutes ces valeurs peuvent être simplement manipulées par un utilisateur malveillant et sont autant de points d’entrée pour une injection. Mais le vol de secrets n’est pas le seul risque… En effet, il est possible d’utiliser cette résolution JNDI pour requêter un serveur contenant du code Java malveillant, qui sera alors récupéré par la machine ciblée et exécuté. Un attaquant peut donc obtenir une exécution de code à distance et ainsi prendre la main sur la machine hébergeant l’application vulnérable.

Enfin, il est critique de noter que le même message peut être manipulé par différentes instances de log4j à différents niveaux de la chaîne d’application. Par exemple, si une application Java exécutée sur un serveur Tomcat vulnérable fait appel à un backend lui aussi vulnérable, une même injection peut compromettre les deux serveurs d’un coup.

Statut de l’exploitation

Lors de sa découverte, la vulnérabilité a principalement été exploitée par des joueurs de Minecraft pour compromettre des serveurs de jeu. Cependant, elle a très vite été exploitée par des acteurs malveillants ciblant des entreprises. Des chercheurs en sécurité ayant mis en place des honeypots ont pu constater de très nombreuses et diverses tentatives d’exploitation de la vulnérabilité. La simplicité d’exploitation et l’absence de privilèges requis font que l’attaque a été massivement utilisée.

Des botnets comme Mirai ou Muhstik ont été mis à jour pour exploiter la vulnérabilité. Des charges malveillantes ont été découvertes pour miner des cryptomonnaies ou encore pour déployer des ransomwares. Confirmation de la vulnérabilité

Identifier les applications utilisant log4j

Les commandes suivantes permettent d’identifier si log4j est utilisé sur la machine :
# ps aux | egrep ’[l]og4j’
# find / -iname "log4j*"
# lsof | grep log4j
# find . -name ’*[wj]ar’ -print -exec sh -c ’jar tvf | grep log4j’ \

Identifier les points d’entrée potentiellement exploitables

Si une application utilise log4j, il faut procéder au fuzzing des paramètres manipulables par l’utilisateur en observant les journaux pour identifier si ces paramètres sont traités par log4j.

Tentative d’exploitation d’un paramètre vulnérable

Une résolution JNDI s’effectue de la manière suivante :
$jndi :[protocole] ://[serveur] :[port]/[ressource]

Il est possible d’effectuer une requête JNDI en HTTP vers un serveur de test pour voir si la connexion arrive. Il est également possible d’utiliser un canari avec le protocole DNS si le protocole HTTP est bloqué sur la machine.

Liste des programmes affectés par la vulnérabilité :
- https://github.com/cisagov/log4j-af... (CISA)
- https://github.com/NCSC-NL/log4shel... (NCSC) Indicateurs de compromission

Il est possible de détecter une tentative de compromission en observant les logs ou le trafic sortant.

Le CERT-FR propose une liste de motifs indiquant une tentative d’exploitation de la vulnérabilité s’ils sont découverts dans des journaux :
$jndi :
$%7Bjndi :
$$
$ ::-
%24%7B%3A%3A-
$env :
$date :
$lower :
$upper :
hostName

$
$

Des règles SIGMA et YARA sont également disponibles. Le NCSC-NL propose une liste de ressource sur son github.

Il est également recommandé d’observer le trafic réseau sortant pour identifier du trafic inhabituel vers des serveurs externes, en particulier sur les protocoles RMI, DNS ou LDAP.

Remédiation

La fondation Apache a publié la version 2.15.0 de log4j le 10/12/2021, cependant celle-ci restait vulnérable à une attaque de déni de service, tout comme la version 2.16.0. Par conséquent, le 17/12/2021, une nouvelle version a été publiée. Il convient donc de mettre à jour log4j :
- Vers la version 2.17.0 pour les utilisateurs de Java 8 ou supérieur.
- Vers la version 2.12.2 pour les utilisateurs de Java 7. S’il n’est pas possible de mettre à jour log4j, il est nécessaire de supprimer la classe « JndiLookup » responsable de la résolution JNDI du classpath Java à l’aide de la commande suivante :
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

A noter que d’autres remédiations proposées initialement ne corrigent que partiellement la vulnérabilité et les applications restent vulnérables.

Sources :
CERT FR : https://www.cert.ssi.gouv.fr/alerte... Apache : https://logging.apache.org/log4j/2....
CISA : https://www.cisa.gov/uscert/apache-...
BlackHat 2016 : Injection JNDI : https://www.blackhat.com/docs/us-16...




Voir les articles précédents

    

Voir les articles suivants