Visit our booth at CANSEC on May 27-28
En décembre 2021, une vulnérabilité critique a secoué l'écosystème Java. Apache Log4j, une bibliothèque de journalisation utilisée massivement dans les applications d'entreprise, contenait une faille permettant l'exécution de code à distance. L'exploitation active a été observée immédiatement après la divulgation publique.
La bibliothèque Log4j permet aux développeurs de consigner les activités de leurs applications, incluant parfois les données saisies par les utilisateurs. Le problème réside dans sa prise en charge des fonctions Java Naming and Directory Interface (JNDI), utilisées dans la configuration et les messages de journalisation.
Dans les versions vulnérables, lorsque Log4j consigne des données contenant des recherches JNDI pointant vers des serveurs contrôlés par un attaquant, la bibliothèque exécute automatiquement ces recherches. L'attaquant peut alors faire charger du code arbitraire depuis son point de contrôle et l'exécuter directement sur le serveur victime. Aucune authentification n'est requise.
Log4j est intégré dans une multitude d'infrastructures Apache populaires: Struts2, Solr, Druid, Flink, Swift. D'autres cadres Java l'incorporent également, comme Netty, MyBatis et Spring. Cette adoption massive signifie que des milliers d'applications tierces héritent automatiquement de la vulnérabilité, souvent sans que leurs développeurs en soient conscients.
La détection passe par l'identification des recherches JNDI suspectes dans les journaux en amont. Le trafic provenant d'adresses IP associées à des campagnes d'exploitation connues doit être surveillé via les logs de pare-feu.
Apache a publié la version 2.15.0 qui corrige la faille. Pour les organisations ne pouvant migrer immédiatement, des solutions de contournement existent: définir la propriété "log4j2.formatMsgNoLookups" à "true" dans les versions 2.10 et ultérieures, ou supprimer la classe JndiLookup du classpath pour les versions antérieures.
L'urgence de la situation découle de trois facteurs combinés: la trivialité de l'exploitation, l'omniprésence de Log4j dans les infrastructures critiques, et l'observation de campagnes actives de balayage et d'exploitation dès les premières heures suivant la divulgation.
