Log4Shell six mois après : pourquoi la faille de sécurité reste dangereuse
Six mois après la découverte de Log4Shell (CVE-2021-44228), la faille de sécurité est encore présente dans des millions de systèmes. Les attaquants continuent de l’exploiter activement. Pourquoi le correctif est-il si difficile à appliquer et que doivent faire les entreprises maintenant.
L’essentiel
- Toujours actif : 6 mois après la découverte, environ 30 % des instances de Log4j ne sont pas corrigé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 utilisent Log4Shell pour l’espionnage.
- CVSS 10.0 : La note de gravité maximale – Exécution de code à distance sans authentification.
- Débat sur le SBOM : Log4Shell a accéléré la demande de Software Bill of Materials.
Pourquoi Log4Shell est un problème persistant
Lorsqu’en 9 décembre 2021 la faille de sécurité Log4Shell a été rendue publique, les experts parlaient 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 ignorent où Log4j est utilisé dans leurs systèmes.
Six mois plus tard, la situation est décevante. Selon Qualys, environ 30 % des instances de Log4j ne sont toujours pas corrigées. Les raisons sont multiples : Log4j se cache comme dépendance transitive dans des piles logicielles complexes, les systèmes hérités ne peuvent pas être mis à jour facilement et certains fabricants n’ont pas encore fourni de correctifs.
Qui exploite Log4Shell maintenant
Alors qu’au cours des premières semaines, les mineurs de cryptomonnaies et les botnets étaient les principaux à exploiter 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 à long terme.
Que doivent faire les entreprises maintenant
La première étape consiste à effectuer un scan complet de tous les systèmes pour détecter les versions de Log4j – y compris les dépendances intégrées et transitives. Des outils comme Syft, Grype ou le scanner Log4j de la CISA peuvent aider à cet égard. Ensuite, toutes les instances doivent être mises à jour au moins à la version 2.17.1. Lorsque le correctif n’est pas possible, des contournements (suppression de la classe JndiLookup) et la segmentation du réseau doivent être utilisés.
Key Facts auf einen Blick
CVE : CVE-2021-44228 (Log4Shell), CVSS 10.0
Découverte : 9 décembre 2021
Non corrigé (juillet 2022) : Environ 30 % de toutes les instances
Logiciels concernés : Des milliers d’applications Java (VMware, Cisco, IBM, Apache, etc.)
Source : Avis de la CISA, Recherche Qualys, Sonatype, juillet 2022
Fait : Seulement 43 % des PME allemandes disposent d’un plan d’urgence informatique selon Bitkom.
Fait : Selon le Allianz Risk Barometer 2025, les cyberattaques sont le plus grand risque commercial au monde.
Questions fréquentes
Qu’est-ce qui rend Log4Shell si dangereux ?
Log4Shell permet l’exécution de code à distance sans authentification – un attaquant peut exécuter n’importe quel code sur le serveur en insérant une chaîne spécialement conçue dans un champ de journalisation. 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 scanneurs comme le scanner Log4j de la CISA, 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 intégrées et les appareils IoT.
La version 2.17.1 est-elle suffisante ?
Oui, la version 2.17.1 corrige toutes les variantes connues de Log4Shell. Cependant, toutes les instances doivent être corrigées – y compris les instances intégré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 correctif 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 dans les piles logicielles. Les systèmes hérités ne peuvent pas être mis à jour facilement et certains fabricants n’ont pas encore fourni de correctifs. De plus, de nombreuses entreprises n’ont pas une vue d’ensemble de toutes les composantes logicielles utilisées.
Quel est le lien entre Log4Shell et le SBOM ?
Log4Shell a considérablement accéléré la discussion sur les Software Bill of Materials (SBOM). Un SBOM liste toutes les composantes logicielles et dépendances. Si les entreprises avaient eu des SBOM, elles auraient su en quelques minutes où Log4j est utilisé. Le gouvernement américain exige désormais des SBOM par ordre exécutif.
Weiterführende Lektüre im Netzwerk
Sécurité open-source dans le cloud sur cloudmagazin : cloudmagazin.com
Stratégies de gestion des correctifs sur mybusinessfuture : mybusinessfuture.com
Pourquoi les CIO doivent investir dans le SBOM sur Digital Chiefs : digital-chiefs.de
Articles similaires
- SOC basé sur l’IA : comment les opérations de sécurité automatisées résolvent la pénurie de main-d’œuvre
- ChatGPT et cybersécurité : pourquoi l’IA transforme l’attaque et la défense
- Directive NIS2 adoptée : ce qui attend maintenant les entreprises
Source de l’image : Pexels / Tima Miroshnichenko
