Log4Shell six mois après : pourquoi la faille de sécurité reste dangereuse

Par Tobias Massow · 22 juillet 2022 · 5 min de lecture

Six mois après la découverte de Log4Shell (CVE-2021-44228), la vulnérabilité est toujours présente dans des millions de systèmes. Les attaquants continuent de l’exploiter activement. Pourquoi le patching est si difficile et ce que les entreprises doivent faire maintenant.

Les points clés en bref

Toujours actif : 6 mois après la découverte, on estime que 30 % des instances Log4j ne sont pas patchées.
Dépendances profondes : Log4j se trouve dans des milliers d’applications Java, souvent très bas dans la chaîne de dépendances.
Acteurs étatiques : Des groupes APT de Chine, d’Iran et de Corée du Nord exploitent Log4Shell pour de l’espionnage.
CVSS 10.0 : La note de sévérité maximale – exécution de code à distance sans authentification.
Débat SBOM : Log4Shell a accéléré la demande de « Software Bill of Materials ».

Pourquoi Log4Shell est un problème durable

Le 9 décembre 2021, lorsque la vulnérabilité Log4Shell a été révélée, les experts ont parlé de la faille de sécurité la plus grave de la décennie. Log4j, une bibliothèque de journalisation Java, se trouve dans des millions d’applications – des serveurs Minecraft aux logiciels d’entreprise de VMware, Cisco et IBM. Le problème : de nombreuses entreprises ignorent tout simplement où Log4j est utilisé dans leurs systèmes.

Six mois plus tard, le constat est préoccupant. Selon Qualys, environ 30 % des instances Log4j ne sont toujours pas patchées. Les raisons sont multiples : Log4j se cache en tant que dépendance transitive dans des piles logicielles complexes, les systèmes legacy ne peuvent pas être mis à jour facilement et certains fabricants n’ont pas encore fourni de correctifs.

Qui exploite Log4Shell aujourd’hui

Alors que dans les premières semaines, ce sont surtout les cryptomineurs et les botnets qui exploitaient la faille, les acteurs étatiques ont désormais pris le relais. La CISA documente une exploitation active par des groupes APT de Chine (Deep Panda), d’Iran (TunnelVision) et de Corée du Nord (Lazarus). Ces groupes utilisent Log4Shell comme vecteur d’accès initial pour des campagnes d’espionnage à long terme.

Ce que les entreprises doivent faire maintenant

La première étape consiste à scanner complètement tous les systèmes à la recherche des versions de Log4j – y compris les dépendances intégrées et transitives. Des outils comme Syft, Grype ou le scanner CISA Log4j aident à cela. Ensuite, toutes les instances doivent être mises à jour au moins vers la version 2.17.1. Là où le patching n’est pas possible, des solutions de contournement (suppression de la classe JndiLookup) et la segmentation réseau doivent être mises en œuvre.

Faits clés en un coup d’œil

CVE : CVE-2021-44228 (Log4Shell), CVSS 10.0

Découverte : 9 décembre 2021

Non patché (juillet 2022) : Environ 30 % de toutes les instances

Logiciels concernés : Des milliers d’applications Java (VMware, Cisco, IBM, Apache, etc.)

Source : CISA Advisory, Qualys Research, Sonatype, juillet 2022

Fait : Selon Bitkom, seules 43 % des PME allemandes disposent d’un plan d’urgence informatique.

Fait : Selon l’Allianz Risk Barometer 2025, les cyberattaques sont le plus grand risque commercial au monde.

Foire aux questions

Qu’est-ce qui rend Log4Shell si dangereux ?

Log4Shell permet l’exécution de code à distance sans authentification – un attaquant peut exécuter du code arbitraire sur le serveur en insérant une chaîne spécialement conçue dans un champ de journal. La vulnérabilité a obtenu le score CVSS maximal de 10,0 et est triviale à exploiter.

Comment savoir si mes systèmes sont concernés ?

Utilisez des scanners comme le CISA Log4j Scanner, Syft ou Grype. Important : Log4j peut être caché en tant que dépendance transitive dans des logiciels qui n’utilisent pas directement Java. Vérifiez également les images de conteneurs, les applications intégrées et les appareils IoT.

Un correctif vers la version 2.17.1 suffit-il ?

Oui, la version 2.17.1 corrige toutes les variantes connues de Log4Shell. Cependant, toutes les instances doivent être patchées – y compris les intégrées. Pour les logiciels tiers, vous dépendez de leurs mises à jour. Vérifiez le statut des correctifs chez tous les fournisseurs.

Pourquoi le patching prend-il autant de temps ?

Log4j est l’une des bibliothèques Java les plus utilisées et se trouve souvent en tant que dépendance transitive à plusieurs niveaux de profondeur dans les piles logicielles. Les systèmes legacy ne peuvent pas être mis à jour facilement, et certains fabricants n’ont pas encore fourni de correctifs. De plus, de nombreuses entreprises manquent de visibilité sur tous les composants logiciels utilisés.

Quel est le lien entre Log4Shell et les SBOM ?

Log4Shell a massivement accéléré les discussions autour de la nomenclature logicielle, ou Software Bill of Materials (SBOM). Un SBOM répertorie tous les composants et dépendances d’un logiciel. Si les entreprises avaient disposé de SBOM, elles auraient su en quelques minutes où Log4j était déployé. Le gouvernement américain exige désormais les SBOM par décret.

Lectures complémentaires au sein du réseau

Sécurité de l’open source dans le cloud sur cloudmagazin : cloudmagazin.com

Stratégies de gestion des correctifs sur mybusinessfuture : mybusinessfuture.com

Pourquoi les DSI investissent désormais dans les SBOM sur Digital Chiefs : digital-chiefs.de

Plus d’articles du réseau MBF Media

cloudmagazin | MyBusinessFuture | Digital Chiefs

Source de l’image à la une : Pexels / Tima Miroshnichenko