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

Par Benedikt Langer · 22 juillet 2022 · 5 min de lecture

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

Les points clés en bref

Toujours active : 6 mois après la découverte, environ 30% des instances Log4j ne sont toujours pas patchées.
Dépendances profondes : Log4j est intégré dans des milliers d’applications Java, souvent profondément dans la chaîne de dépendances.
Acteurs étatiques : Des groupes APT de Chine, d’Iran et de Corée du Nord exploitent Log4Shell à des fins d’espionnage.
CVSS 10.0 : La note de gravité maximale – exécution de code à distance sans authentification.
Débat SBOM : Log4Shell a accéléré l’exigence d’une Software Bill of Materials.

Pourquoi Log4Shell reste un problème durable

Lorsque la faille Log4Shell a été rendue publique le 9 décembre 2021, les experts ont parlé de la faille de sécurité la plus grave de la décennie. Log4j, une bibliothèque de journalisation Java, est intégrée dans des millions d’applications – des serveurs Minecraft aux logiciels d’entreprise de VMware, Cisco et IBM. Le problème : de nombreuses entreprises ne savent même pas où Log4j est utilisé dans leurs systèmes.

Six mois plus tard, le constat est décevant. Selon Qualys, environ 30 pour cent des instances Log4j ne sont toujours pas patchées. Les raisons sont multiples : Log4j se cache comme dépendance transitive dans des piles logicielles complexes, les systèmes legacy ne peuvent pas être mis à jour simplement 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 cryptominers et les botnets qui exploitaient la faille, des acteurs étatiques ont depuis 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 de longue durée.

Ce que les entreprises doivent faire maintenant

La première étape consiste en un scan complet de tous les systèmes pour identifier les versions de Log4j – y compris les dépendances intégrées et transitives. Des outils comme Syft, Grype ou le CISA Log4j Scanner y aident. Ensuite, toutes les instances doivent être mises à jour au minimum vers la version 2.17.1. Là où le patching n’est pas possible, des contournements (suppression de la classe JndiLookup) et une segmentation réseau doivent être mis en place.

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, et bien d’autres)

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

Fait : Seuls 43 pour cent des PME allemandes disposent d’un plan d’urgence IT selon Bitkom.

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

Foire aux questions

Qu’est-ce qui rend Log4Shell si dangereuse ?

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 log. La faille a 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é comme dépendance transitive dans des logiciels qui n’utilisent pas directement Java. Vérifiez également les images de conteneurs, les applications embarquées et les appareils IoT.

Un patch vers la version 2.17.1 suffit-il ?

Oui, la version 2.17.1 corrige toutes les variantes connues de Log4Shell. Toutefois, toutes les instances doivent être patchées – y compris les instances embarquées. Pour les logiciels de tiers, vous dépendez de leurs mises à jour. Vérifiez l’état des correctifs auprès de tous les fabricants.

Pourquoi le patching prend-il autant de temps ?

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

Quel est le lien entre Log4Shell et les SBOM ?

Log4Shell a considérablement accéléré le débat autour des Software Bill of Materials (SBOM). Un SBOM répertorie l’ensemble des composants logiciels et de leurs dépendances. Si les entreprises avaient disposé de SBOM, elles auraient su en quelques minutes où Log4j était utilisé. Le gouvernement américain exige désormais les SBOM par décret présidentiel.

Lectures complémentaires dans le réseau

Sécurité 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 image de titre : Pexels / Tima Miroshnichenko

Source de l’image : Pexels / Tima Miroshnichenko

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.