Vendredi 10 novembre, une faille de sécurité critique de la bibliothèque de journalisation Apache Log4j a été mise à jour.

Note :  vous êtes concerné par ce message si vous disposez d’un hébergement sur serveur dédié ou VDS (VPS).
 
Vendredi 10 novembre, une faille de sécurité critique de la bibliothèque de journalisation Apache Log4j a été mise à jour.
Apache Log4j est communément utilisée pour le développement d’applications et logiciels basés sur Java/J2EE.
 
Cette vulnérabilité a obtenu la note maximale de 10/10 quant à sa criticité, car elle permet à un attaquant de provoquer une exécution de code arbitraire à distance s’il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l’évènement. L’attaquant peut, par exemple, détourner des applications comme des pages d’authentification qui journalise les erreurs.
 

Comment savoir si je suis concerné ?

La vulnérabilité concerne les versions suivantes de l’outil :
  • Apache Log4j versions 2.0 à 2.14.1
  • Apache log4j versions 1.x (qui est une version obsolète de la bibliothèque) dans certaines configurations
  • Les produits logiciels utilisant une version vulnérable de Apache Log4j.
    >> Liste non-exhaustive de produits vulnérables

Vous disposez d’une infogérance serveur chez Icodia ?

Si vous avez souscrit à une option d’infogérance niveau 1 ou supérieure auprès de nos services, notre service technique procède aux vérifications nécessaires et, le cas échéant, aux correctifs adaptés.
 

Que faire si mon serveur est vulnérable ?

La mise à jour vers la version 2.15.0 de la bibliothèque résout la problématique.
 
Si cette mise à jour n’est pas possible, vous pouvez effectuer les modifications suivantes pour contourner provisoirement la vulnérabilité :

 

Pour les applications utilisant Log4j dans les versions 2.7.0 et ultérieures :

Modifiez le format de la journalisation des données fournies par l’utilisateur avec la syntaxe suivante dans le fichier de configuration de log4j :
%m{nolookups}
 

Pour les applications utilisant Log4j dans les versions 2.10.0 et ultérieures :

 
1- Modifiez le paramètre de configuration log4j2.formatMsgNoLookups  à la valeur true :
 
log4j2.formatMsgNoLookups=true
 
2- Vous pouvez également supprimer la classe ndiLookup dans « JndiLookup » pour éliminer le vecteur principal d’attaque :
  • repérez le(s) chemin(s) où est(sont) stocké(s) la classe JndiLookup :
    find / | grep "JndiLookup.class"
  • et exécutez la commande :
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
/!\ Attention :
avant de déployer ces modifications, assurez-vous de réaliser les tests de validation techniques et fonctionnelle.

 

Vous n’êtes pas en mesure de traiter ces vérifications et mises à jour ?

Contactez l’administrateur de votre serveur, ou encore notre service technique, qui pourra vous accompagner le cas échéant dans ces opérations
 
 

Pour en savoir plus :

Applicatifs concernés par la vulnérabilité

(Liste non-exhaustive)

  • Elasticsearch (éventuel, si activation du module)
  • Minecraft (tout clients / serveurs)
  • Différents produits VMware
  • Certains systèmes et interfaces broadcom
  • Des produits Cisco utilisant log4j
  • Adobe CF
  • Certains clients Azure
  • Cpanel (via plugin Soir)
  • Certains produits Fortinet
  • F-Seccure proxy
  • Certains produits F5
  • Ghidra
  • Jitsi
  • OpenMRS/NMS
  • Puppet CDPE
  • SAP
  • Sentry
  • Solarwinds
  • SonicWall
  • TP-Link SDN
  • ZAP Proxy
  • Certains produits McAfee
  • Zimbra (si module actif)