Faille Log4j : un cauchemar pour des millions d'applications Java
-
Faille Log4j : un cauchemar pour des millions d’applications Java
Lucian Constantin, CSO (adapté par Jacques Cheminat) , publié le 13 Décembre 2021Des cybercriminels exploitent activement une faille critique dans Apache Log4j. Cette librairie de journalisation est utilisée par des millions d’applications Java. Les entreprises doivent immédiatement vérifier leurs applications et mettre à jour cette bibliothèque. Le spectre d’un scénario à la Heartbleed refait surface.
Peu avant le week-end, les premières alertes (notamment Majong éditeur de Minecraft) ont été lancées sur une faille critique dans Apache Log4j, une bibliothèque de log dont se sert des millions d’applications Java. Cette vulnérabilité est connue sous le nom de CVE-2021-44228 et a été publiée le 9 décembre. Rapidement, les développeurs ont publié un correctif avec la version 2.15.0 de la librairie.
L’exploit Log4Shell
La faille découverte, peut conduire à l’exécution de code à distance sur les serveurs servant aux applications vulnérables et elle ne nécessite aucune authentification. La sévérité de la brèche est maximale 10 sur l’échelle CVSS. Le CERT-FR a résumé la situation en expliquant « cette vulnérabilité permet à un attaquant de provoquer une exécution de code arbitraire à distance s’il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l’évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d’une page d’authentification qui journalise les erreurs d’authentification ». Depuis log4j 2.15.0, ce comportement a été désactivé par défaut.
Cela signifie que si un utilisateur peut générer une requête spécifique et qu’elle est enregistrée par Log4j, la faille pourrait être exploitée. Comme la plupart des applications sont conçues pour accepter les requêtes de l’utilisateur de différentes manières, l’exploitation de la vulnérabilité apparaît triviale.
La brèche a été découverte en premier lieu par l’équipe de sécurité du cloud d’Alibaba et en particulier Chen Zhaojun en novembre dernier. D’après les commentaires des développeurs dans le système de suivi des bugs, la publication d’une version corrigée de Log4j aurait été retardée, car les chercheurs ont trouvé un moyen de contourner le correctif initialement proposé, nécessitant un travail et un examen supplémentaire.
Un impact durable
La vulnérabilité n’affecte pas seulement les applications et services basés sur Java qui se servent directement de la librairie, mais aussi de nombreux autres composants Java et framework populaires qui en dépendent, notamment Apache Struts2, Solr, Druid, Flink, ElasticSearch, Kafka et bien d’autres. La communauté travaille encore à l’évaluation de la surface d’attaque, mais il est probable que l’onde de choc soit énorme en raison des dépendances complexes au sein de l’écosystème. Certains des composants touchés sont utilisés par des millions d’applications et de services en entreprise. Des services gérés par Apple (iCloud), Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu et d’autres ont été signalés comme étant vulnérables. Cloudflare a créé des règles de détection dans son pare-feu d’application web pour bloquer les tentatives d’exploitation et a publié un avis. Le chercheur Florian Roth a également publié des règles de détection YARA.
« Je m’attends à ce que cela traîne pendant un long moment », a déclaré Chris Wysopal, directeur technique Veracode, lors d’un webinaire sur la faille. « ll peut y avoir des applications sur lesquelles vous avez une bonne visibilité et que vous trouvez assez rapidement, mais il est difficile de trouver toutes vos applications Java. » Il ajoute, « l’autre défi est, bien sûr, les applications des fournisseurs qui sont écrites en Java. Vous savez, nous avons vu cela avec Heartbleed il y a de nombreuses années - qui a en quelque sorte donné le coup d’envoi de tout le risque lié aux tiers - que beaucoup d’applications de fournisseurs étaient écrites avec la bibliothèque SSL ouverte et que vous deviez attendre que votre fournisseur applique un correctif. La même chose pourrait se produire ici. De nombreux terminaux et logiciels intégrés utilisent Java, et je m’attends donc à ce que les gens demandent aux constructeurs et éditeurs quand ils seront corrigés. »
Une aubaine pour les pirates
Les attaquants scrutent déjà l’internet à la recherche d’applications et de services susceptibles d’être vulnérables à CVE-2021-44228 et le service de surveillance du trafic GreyNoise signale que le nombre de tentatives d’exploitation s’accélère. Des cybercriminels se servent de botnet comme Mirai ou Mushtik pour installer Log4jshell sur des terminaux vulnérable, explique Netlab360. D’autres l’utilisent pour diffuser des cryptomineurs. Le centre de threat intelligence de Microsoft a observé des placements de balises Cobalt Strike. Cet outil de pentest est souvent un vecteur d’attaque dans le cadre des ransomwares.
Il est probable que les entreprises vont être occupées pendant des mois à rechercher et à corriger les applications vulnérables à ce problème, ce qui souligne l’importance pour les éditeurs de mettre en œuvre des nomenclatures logicielles. Malheureusement, le fait de ne pas patcher en temps voulu des failles activement exploitées peut conduire à des brèches majeures. Le piratage majeure d’Equifax en 2017 est le résultat de l’absence de correctifs pour une vulnérabilité Struts2 activement exploitée pendant deux mois dans une application destinée au public.
Des mesures d’atténuation
Dans certains cas, les exploits actuels peuvent ne pas fonctionner même si Log4j est vulnérable, par exemple si le système hôte utilise une version de Java supérieure à 6u212, 7u202, 8u192 ou 11.0.2. En effet, ces versions ont amélioré la protection du chargement de classe à distance JNDI (Java Naming and Directory Interface), qui est nécessaire pour que l’exploit fonctionne.
En outre, dans les versions de log4j supérieures à 2.10, le problème peut être atténué en définissant la propriété système formatMsgNoLookups sur true, en définissant le paramètre JVM -Dlog4j2.formatMsgNoLookups=true ou en supprimant la classe JndiLookup du classpath.
Cependant, la meilleure solution est de mettre à jour vers log4j 2.15.0 car quelqu’un pourrait trouver un chemin alternatif pour atteindre la vulnérabilité. Par ailleurs, plusieurs éditeurs et constructeurs ont annoncé des mises à jour pour corriger leurs services ou applications.
Article rédigé par
Lucian Constantin, CSO (adapté par Jacques Cheminat) -
-
undefined duBoudin marked this topic as a regular topic on
-
Apparemment la faille touche aussi des firewalls.
-
@arcturien a dit dans Faille Log4j : un cauchemar pour des millions d'applications Java :
Log4j
Avec un serveur à jour (Version 2.15) aucun problème.
apt policy liblog4j2-java
liblog4j2-java:
Installé : (aucun)
Candidat : 2.15.0-1~deb11u1
Table de version :
2.15.0-1~deb11u1 500
500 http://deb.debian.org/debian-security bullseye-security/main amd64 >Packages
2.15.0-1~deb10u1 500
500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
2.13.3-1 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
2.11.1-2 500
500 http://deb.debian.org/debian buster/main amd64 PackagesEt encore mieux quand c’est pas installé!
-
CrowdSec a déjà résolu le problème :
Détectez et bloquez les tentatives d’exploitation de Log4j avec CrowdSec
Si vous travaillez dans le domaine de la cybersécurité, le week-end dernier a probablement été moins relaxant que prévu. Et ce, à cause de la découverte de la vulnérabilité zero-day Log4j (CVE-2021-44228). L’équipe CrowdSec s’est retroussé les manches pour développer un scénario capable de détecter et bloquer les tentatives d’exploitation de cette vulnérabilité. Vous pouvez
.L’efficacité de CrowdSec se basant sur le pouvoir de la foule, et à la lumière de la taille de leur communauté en pleine expansion, la solution a déjà collecté un grand nombre d’adresses IP qui tentent d’exploiter la vulnérabilité. Vous pouvez consulter la liste ici. Elle est très fréquemment mise à jour et il va sans dire que vous devriez bloquer sans attendre celles qui sont marquées comme « validated ».
Ces adresses IP ont été sélectionnées par l’algorithme de consensus de la solution, ce qui signifie qu’elles ont reçu de nombreux votes défavorables de la part de leur réseau d’utilisateurs. Celles qui sont marquées comme « not enough data » sont très suspectes mais peuvent encore contenir quelques faux positifs. Les adresses classées dans la catégorie « benign » sont utilisées par des personnes qui sont généralement du bon côté de la force, pour aider, scanner, et non à des desseins malfaisants.
Vous pouvez également utiliser leur mode replay, ou forensics, pour analyser les logs de vos serveurs afin de vérifier si une exploitation Log4j a été tentée sur l’une de ces IP, par qui et quand, en utilisant le scénario approprié et la ligne de commande ci-dessous :
sudo cscli hub update sudo cscli scenarios install crowdsecurity/apache_log4j2_cve-2021-44228 sudo systemctl reload crowdsec # sudo crowdsec --dsn "file://<log_file_path>" -no-api --type <log_type> sudo crowdsec --dsn "file:///var/log/nginx/access.log" -no-api --type nginx sudo cscli alerts list --scenario crowdsecurity/apache_log4j2_cve-2021-44228Si vous souhaitez accéder à plus de détails concernant cet IPS open source et collaboratif, qui est capable de détecter et bloquer de nombreux comportements malveillants, tout en vous permettant de collaborer entre cyber défenseurs en échangeant les IPs bloquées, visitez leur site web ou leur dépôt GitHub.
Source : https://linuxfr.org
-
J’ajouterais l’excellent tuto de Crowdsec disponible ici
-
Ce que l’homme peut faire il peut le défaire, rien n’est infaillible
Et encore imaginez tout ce qu’il se vends sous le manteau et que les “noob” du grand public ne savent meme pas
-
Merci pour cette très belle info!
