Une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache Log4j. Cette vulnérabilité, si elle n'est pas corrigée permet le contrôle total du serveur ciblé.
La bibliothèque Apache Log4j est très utilisée dans les projets de dev d'applications Java/J2EE + les éditeurs de solutions logicielles basées sur Java/J2EE.
Cette vulnérabilité permet de prendre le contrôle total du serveur très facilement
Presque toutes les applications Java utilisées par les organisation (on premise, dans le cloud et les applications SAAS sont concernées)
Vous êtes concernés :
Les versions affectées sont les suivantes :
Contre-mesures :
Procédures :
La bibliothèque Apache Log4j est très utilisée dans les projets de dev d'applications Java/J2EE + les éditeurs de solutions logicielles basées sur Java/J2EE.
Cette vulnérabilité permet de prendre le contrôle total du serveur très facilement
Presque toutes les applications Java utilisées par les organisation (on premise, dans le cloud et les applications SAAS sont concernées)
Vous êtes concernés :
- Directement si vous utilisez Apache Log4j
Les versions affectées sont les suivantes :
- Apache Log4j versions 2.0 à 2.14.1
- Apache Log4j versions 1.x (versions obsolètes)
Contre-mesures :
- Correctives :
- Si vous êtes directement concernés, mettre à jour Log4j vers la version 2.15.0
- Si vous êtes indirectement concernés, rapprochez-vous de l’éditeur pour récupérer une version patchée
- Provisoires :
- Versions 2.7.0 et ultérieures : dans le fichier de configuration log4j, modifier le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur.
- Versions 2.10.0 et ultérieures :
- modifier le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true ( par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true).
- supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (l'existence d'un autre vecteur d'attaque n’est pas exclu)
- De manière générale :
- L'utilisation d'un environnement d'exécution Java en version 8u121 ou ultérieure permet d'empêcher le principal vecteur d'attaque.
- Filtrer les flux sortants des serveurs pour les limiter aux seuls flux autorisés vers des services dits "de confiance".
Procédures :
- Tests de Non Reg : validation technique et fonctionnelle
A+