Log4Shell : ce qu’il faut savoir sur la faille Java qui sème la panique
Répandu dans les applications Java, l’utilitaire de journalisation Log4j abrite une faille critique qui sème la panique parmi les DSI. Le point sur les solutions pour colmater la brèche.
Log4Shell, c’est quoi ?
Il s’agit d’une faille de sécurité dans l’utilitaire de journalisation Log4j qui touche les versions 2.0-beta9 à 2.14.1.
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.
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.
Qui a donné l’alerte ?
La fondation Apache – qui gère Log4j – a 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.
Atlassian, Boomi, Cisco, Docker, ESET ont aussi émis, ces derniers jours, des alertes relatives à Log4j.
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.
Quels sont les risques ?
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.
Les attaques sont susceptibles de contourner les solutions, notamment les firewalls, aussi bien en exploitant des ports alternatifs qu’en mettant en œuvre des techniques d’obscurcissement.
Cisco 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.
Il semble aussi possible d’exploiter du code existant sur le serveur même avec le vecteur d’exécution à distance. Exemple sur Tomcat, à travers la classe org.apache.naming.factory.BeamFactory/.
Comment se protéger ?
Log4j 2.15.0 apporte des corrections pour « 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
Le bulletin d’alerte du CERT-FR met l’accent sur ces techniques d’obscurcissement. En toile de fond, une recommandation aux entreprises : effectuer une analyse approfondie de leurs journaux réseau, à la recherche des chaînes de caractères utilisées pour déclencher l’attaque. Et faire, si possible, la corrélation avec les logs DNS. Puis, au niveau des logiciels affectés, filtrer et journaliser les flux sortants tout en vérifiant la disponibilité de correctifs. Les développeurs auront soin de passer à Log4j 2.15. Voire à la version 2.16. Publiée avant-hier, elle complète la correction en désactivant par défaut l’API JNDI et la fonction de lookup.
Quels sont les résultats des attaques ?
À son dernier pointage (mardi 14 décembre), Check Point recensait plus d’un million de tentatives d’exploitation de Log4Shell. Et fournissait un indicateur « brut » : à l’échelle mondiale, 44 % des réseaux corporate touchés. Principal objectif des assaillants : le minage de cryptomonnaies, assurait le groupe américain.