Log4j : une autre vulnérabilité corrigée par Apache

Plus d’une semaine après la publication de la mise à jour 2.17 de la bibliothèque de journalisation Log4j d’Apache Logging, une faille CVE-2021-44832 l’affectant est comblée. La montée de version vers la 2.17.1 est à effectuer dès que possible.

A l’instar de la vaccination en santé, l’application de mises à jour pour limiter les risques cybersécurité est essentielle, bien qu’elle ne protège pas toujours une bonne fois pour toute. C’est précisément le cas des montées de versions successives publiées par la fondation Apache pour neutraliser les failles découvertes dans la bibliothèque de journalisation Log4j d’Apache Logging. Quelques jours après la parution d’une mise à jour 2.17 pour contrer de possibles attaques par DoS, on apprend que cette version est elle-même sujette à faille. Une mise à jour 2.17.1 a donc été proposée et il est vivement conseillé de l’installer.

« Apache Log4j2 versions 2.0-beta7 à 2.17.0 (à l’exception des versions de correctifs de sécurité 2.3.2 et 2.12.4) sont vulnérables à une attaque d’exécution de code à distance (RCE) où un attaquant autorisé à modifier le fichier de configuration de journalisation peut construire une configuration malveillante en utilisant un Appender JDBC avec une source de données référençant un URI JNDI pouvant exécuter du code à distance », explique la fondation Apache. Cette faille, référencée en tant que CVE-2021-44832, s’est vu attribuée un score de sévérité de 6.6. 

Des améliorations aussi de la partie :

Cette version  Log4j 2.17.1 apporte plusieurs améliorations, comme l’indique un billet de Matt Sicker, ingénieur logiciel chez Apple et contributeur pour la fondation Apache. Par exemple, JdbcAppender utilise désormais JndiManager pour accéder à JNDI Ressources, et JNDI n’est activé que lorsque la propriété système log4j2.enableJndiJdbc est défini sur true, vorrection du nom du package SpringLookup dans Interpolator ou encore la classe

ExtendedLoggerWrapper.logMessage qui ne produit plus de log en double lors d’un requêtage d’emplacement.

Les cyberattaques se multiplient pour tenter d’exploiter les vulnérabilités liées à Log4j et les éditeurs de sécurité multiplient les initiatives pour scanner du code à risque dans des applications en cours d’exécution ou dans des fichiers sources. Les exemples d’exploits se multiplient un peu partout dans le monde comme au ministère de la Défense en Belgique). Ou encore une plateforme de cryptomonnaie ONUS au Vietnam, victime d’une cyberattaque par ransomware exploitant la CVE-2021-44228 de Log4j (de la 2.0-beta9 à la 2.14.1). Ce dernier a refusé de payer une somme de 5 millions de dollars suite à quoi près de 2 millions de données clients ont été mis en vente sur des forums.

Pour plus d’information : https://www.lemondeinformatique.fr/actualites/lire-log4j-une-autre-vulnerabilite-corrigee-par-apache-85265.html

Nous sommes présents sur les réseaux : LinkedIn, Twitter, Facebook, Instagram