Log4j : le périmètre des correctifs s’étend

Arctic Wolf, BinaryDefense, Datto, FullHunt… Autant d’outils de détection et/ou de remédiation spécifiques à Log4j. Le CESIN les mentionne tous dans un guide à destination des entreprises et des collectivités.

Ce guide, publié le 13 décembre dernier, a déjà fait l’objet de deux mises à jour. La dernière date du 30 décembre. Elle ajoute, entre autres, un tableau récapitulatif des failles signalées jusque-là dans Log4j.

Ces failles sont désormais au nombre de quatre. En tête de liste, celle qui avait « tout déclenché » : la CVE-2021-44228, qu’on a appelée Log4Shell. Connue du public depuis le 9 décembre, elle avait entraîné la publication d’un correctif (Log4j 2.15) pour les environnements Java 8 – et versions ultérieures.

Quelques jours plus tard, la fondation Apache avait publié un deuxième correctif, applicable à partir de Java 7. Objectif : corriger la CVE-2021-45046, moins critique que Log4Shell, mais pouvant entraîner un déni de service sur certaines configurations.

Le 18 décembre, on avait eu droit à une nouvelle révélation. En l’occurrence, l’existence d’une troisième vulnérabilité (CVE-2021-45105), elle aussi susceptible d’occasionner des DoS. Le périmètre des correctifs s’était étendu à Java 6.

La semaine dernière s’y est ajoutée la CVE-2021-44832. Elle présente un risque d’exécution de code à distance. Vecteur : le composant JNDI qui stocke les logs en base de données. La solution ? Si possible, installer Log4j 2.3.2, 2.12.4 ou 2.17.1.

Log4j : la question des sous-traitants

Le CESIN évoque un certain nombre d’attaques avérées chez ses membres. Parmi elles, l’injection de cryptomineurs, l’exploitation des failles par des malwares (exemple : StealthLoader) et le dépôt de ransomwares (exemple : Khonsari).

Les échanges avec les membres du CESIN ont fait apparaître de l’incertitude quant à la gestion de la crise par les sous-traitants. Aussi le guide comporte-t-il, en français et en anglais, des modèles de questionnaires à adresser aux éditeurs de logiciels ; SaaS d’un part, on-prem de l’autre.

Au-delà des outils et des scripts dont il fait mention, le CESIN pousse les analyses manuelles, notamment par échantillonnage. Et attire l’attention sur divers risques, dont l’infection de postes de développeurs et la restauration de backups avec des versions vulnérables.

Photo d’illustration © monsitj – Adobe Stock