Log4Shell : l’inquiétude monte autour de cette faille Java
Répandu dans les applications Java, l’utilitaire de journalisation Log4j abrite une faille critique. Le point sur la situation.
Atlassian, Boomi, Cisco, Docker, ESET… Autant de fournisseurs qui ont émis, ces derniers jours, des alertes relatives à Log4j. La raison ? Une faille de sécurité dans cet utilitaire de journalisation. Les risques sont multiples pour les applications Java qui l’exploitent. Ils vont jusqu’à l’injection – et l’exécution – de code indésirable à distance.
Le problème touche les versions 2.0-beta9 à 2.14.1 de Log4j. Dans les grandes lignes, il permet d’envoyer un message spécifique que le serveur visé va journaliser. Message qui active la faille, de sorte que le serveur, via l’API JNDI (connexion à des annuaires), en contacte un autre où il récupère le code malveillant.
La fondation Apache – qui gère Log4j – avait tiré la sonnette d’alarme le 9 décembre. Depuis, les PoC se sont multipliés. Et un surnom a émergé pour la faille : Log4Shell. Les preuves d’exploitation active se sont aussi accumulées. Parmi elles, la diffusion des botnets Mirai et Muhstik, connus pour véhiculer notamment des ransomwares et des mineurs de cryptomonnaies.
Le niveau de risque n’est pas le même en fonction de la version de Java. Le principal vecteur d’attaque (LDAP) ne semble effectivement pas exploitable à partir de la 6u211, de la 7u201, de la 8u191 et de la 11.0.1. D’autres protocoles (HTTP/S, DNS…) restent cependant utilisables pour charger le code.
Log4j : quelle solutions pour colmater la brèche ?
Les corrections qu’apporte Log4j 2.15.0 consistent à « cadenasser » JDNI en limitant aussi bien les protocoles utilisables que les classes accessibles via LDAP. Pour qui n’a pas la possibilité de faire la mise à jour, il existe plusieurs palliatifs qui ont en commun de désactiver l’interface StrLookup (grâce à laquelle on peut modifier la configuration de Log4j).
– À partir de Log4j 2.10, régler sur « vrai » la propriété log4j2.formatMsgNoLookups ou la variable d’environnement LOG4J_FORMAT_MSG_NO_LOOKUPS
– Sur la 2.7 et ultérieures, modifier tous les schémas de journalisation pour éliminer les lookups (en remplaçant %m par %m{nolookups})
– De la 2.0-beta9 à la 2.10.0, retirer la classe JndiLookup du classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ; ou y substituer une implémentation non vulnérable
L’ampleur de la faille se constate, par exemple, chez Cisco. Aux dernières nouvelles, le groupe américain recense une trentaine de services affectés. Le serveur Webex Meetings en fait partie… au contraire du client.
Les projets de la fondation Apache ne sont pas non plus épargnés. Sur la liste, il y a, entre autres, Druid, Flink et Struts2.
La mise en œuvre des attaques apparaît parfois comme élémentaire. Changer le nom d’un iPhone a fait mouche sur les serveurs iCloud. Idem pour le chat de Minecraft chez qui utilise l’édition Java.
Quand bien même on aurait coupé le vecteur d’exécution à distance, il semble possible d’exploiter du code existant sur le serveur. Un exemple a émergé sur Tomcat, à travers la classe org.apache.naming.factory.BeamFactory/.
Photo d’illustration © monsitj – Adobe Stock
