Faille Apache Log4j : les applications tierces sous le feu des projecteurs
par Robert Huber
Page d'accueil des blogs / Alertes de cyber-exposition
Alors que les organisations du monde entier agissent de manière impulsive pour tenter de gérer la vulnérabilité critique Log4j, connue sous le nom de Log4Shell, la question numéro 1 que se pose chaque responsable de la sécurité est : Comment est-ce que je peux savoir si je suis impacté ?
Mise à jour du 17 décembre : Apache a mis à jour la sévérité de CVE-2021-45046, une deuxième vulnérabilité Log4j, en la faisant passer de faible à critique (9.0 CVSSv3) citing possible RCE under certain configurations. Pour plus d'informations, veuillez consulter cet article dans la Tenable Community.
L'omniprésence d'Apache Log4j, un framework de journalisation open-source, rend cette question particulièrement difficile à répondre.
Non seulement bon nombre d'organisations utilisent Log4j dans leur propre code source, mais il est également présent dans de nombreux produits acquis de sources tierces. Les entreprises ayant adopté le modèle « shift left » sur leur cycle de vie de développement logiciel sécurisé (SSDL) peuvent analyser leur propre code source pour retrouver et corriger la faille dans leur propre système.
Une approche SSDL qui inclut des tests statiques de sécurité des applications (SAST), des tests dynamiques de la sécurité des applications (DAST), des vérifications de dépendances tierces, un scan de sécurité des conteneurs, une gestion des vulnérabilités et une Infrastructure as Code (IaC) est requise. Mais même en mettant en place toutes ces pratiques, les organisations peineront toujours à saisir tout ce qui reste. La gestion des vulnérabilités et le scan des applications web sont également essentiels, surtout en ce qui concerne vos applications tierces. Il ne suffit pas de découvrir si la faille existe ou non, vous devez également appréhender le niveau de risque encouru dans le contexte d'une combinaison d'applications, d'assets et de processus métier au sein de votre organisation.
En dépit du récent décret émanant de l'administration Biden appelant les entreprises à développer des nomenclatures logicielles (SBOM), la plupart des fournisseurs n'en proposent pas pour leurs propres applications. Et même s'ils le faisaient, la plupart des organisations seraient à des années lumières de détenir les process et fonctionnalités adaptées afin d'en faire bon usage. Ainsi, lorsqu'un incident comme log4j se produit, les leaders en cyber-sécurité n'ont plus qu'une solution : appeler leurs fournisseurs d'applications tierces et le leur demander. Cette méthode est à la fois laborieuse, redondante et chronophage, laissant les organisations se perdre dans l'urgence tandis que les attaquants se ruent pour exploiter la faille.
FAQ : CVE-2021-45046, CVE-2021-4104 :Frequently Asked Questions About Log4Shell and Associated Vulnerabilities.
Même dans les organisations les plus matures, où les pratiques SSDL et les SBOMS sont enracinés dans les processus, les angles morts demeurent, mettant les entreprises au défit de répondre à ces cinq questions :
- Est-ce qu'elles sont exécutées dans mon environnement ?
- Et dans mon infrastructure ?
- Et dans nos pipelines de build ?
- Et qu'en est-il des fournisseurs de notre infrastructure ? Ce point est particulièrement pertinent si vous avez recours à des services de fournisseur de services cloud.
- Puisque l'analyse de composition des logiciels (SCA) ne pourra pas découvrir toutes les instances de Log4J, avons-nous effectué d'autres contrôles, tels que l'Infrastructure as Code (IaC), la gestion des vulnérabilités et le scan des applications par rapport à tous les composants de notre code ?
En conclusion : Il n'existe pas de solution simple pour venir à bout de Log4j. Une option évidente, la mise en oeuvre d'un pare-feu pour applications web, s'est avérée relativement facile à contourner. Une organisation responsable se doit de faire l'effort de mettre à jour son logiciel principal et de comprendre comment cette faille peut impacter le profil de risque global. Les entreprises qui réagissent maintenant prennent des décisions en mode gestion de crise ; une fois la crise initiale passée, la tentation sera grande de déclarer la « mission accomplie » et de passer son chemin. De notre point de vue, il s'agit là d'une erreur catastrophique. Le temps est révolu où les entreprises devaient corriger elles-mêmes leur infrastructure et maintenir leurs systèmes à l'aide d'une approche security-first intégrée.
Chez Tenable, nous restons attachés à SSDL et prenons les mesures suivantes pour répondre à Log4j :
- Nous disposons de portes bloquantes et, dans ce cas, nous condamnons l'utilisation de toute instance vulnérable de logiciel, en y incluant Log4j.
- Nous procédons activement et constamment à des scans de gestion des vulnérabilités et d'applications web sur toutes nos infrastructures et nous pré-publions du code produit avant de le livrer aux clients.
- En outre, nous avons actionné tous les indicateurs de compromission et d'attaque, et mis en œuvre des contrôles au niveau du réseau et de l'hôte.
Nous continuerons à surveiller la threat intelligence afin de suivre le paysage des menaces et d'apporter les corrections requises. En définitive, répondre à un incident revient à savoir ce qui constitue votre environnement, à connaître votre surface d'attaque, y compris tous les éléments tiers, et à réduire rapidement le risque. Le temps presse. Les attaquants sont toujours prêts à se lancer sur la moindre vulnérabilité et à la détourner pour leur propre cas d'usage. Les organisations doivent faire tout leur possible pour examiner dès maintenant leurs pratiques au plus près, car les répercussions de cet incident seront dévastatrices sur les logiciels d'entreprise pendant encore plusieurs années.
Pour en savoir plus
- /blog/brazen-unsophisticated-and-illogical-understanding-the-lapsus-extortion-group Visitez le centre de solutions Tenable Log4j : https://fr.tenable.com/log4j
- Lisez l’alerte SRT : CVE-2021-44228 : Démonstration de faisabilité (PoF) pour la vulnérabilité d'exécution de code à distance (RCE) Apache Log4j (Log4Shell)
- Lire la FAQ :CVE-2021-44228, CVE-2021-45046, CVE-2021-4104 : Frequently Asked Questions About Log4Shell and Associated Vulnerabilities
- Lisez le point de vue du CTO : Faille Apache Log4j : Un moment digne de Fukushima pour l'industrie de la cyber sécurité
- Visitez notre communauté d’utilisateurs pour découvrir comment Tenable peut vous aider : https://community.tenable.com/s/
Articles connexes
How the regreSSHion Vulnerability Could Impact Your Cloud Environment
July 5, 2024With growing concern over the recently disclosed regreSSHion vulnerability, we’re explaining here what it is, why it’s so significant, what it could mean for your cloud environment and how Tenable Cloud Security can help.
Cybersecurity Snapshot: Memory Bugs Pervasive in Open Source SW, While Car Dealership Chaos Persists After Ransomware Attack
June 28, 2024Check out why memory vulnerabilities are widespread in open source projects. Plus, get the latest on the ransomware attack that’s disrupted car sales in North America. In addition, find out why a majority of organizations grew their cyber budgets this year. And learn how confidential data from U.S. chemical facilities may have been accessed by hackers. And much more!
Tag, You’re IT! Tagging Your Way to Cloud Security Excellence
June 26, 2024To manage your cloud resources effectively and securely, you need to consistently tag assets across all your cloud platforms. Here we explain tagging’s main benefits, as well as proven strategies and best practices for tagging success.
How Risk-based Vulnerability Management Boosts Your Modern IT Environment's Security Posture
July 11, 2024Vulnerability assessments and vulnerability management sound similar – but they’re not. As a new Enterprise Strategy Group white paper explains, it’s key to understand their differences and to shift from ad-hoc vulnerability assessments to continuous, risk-based vulnerability management (RBVM). Read on to check out highlights from this Tenable-commissioned study and learn how RBVM helps organizations attain a solid security and risk posture in hybrid, complex and multi-cloud environments.
Microsoft’s July 2024 Patch Tuesday Addresses 138 CVEs (CVE-2024-38080, CVE-2024-38112)
July 9, 2024Microsoft addresses 138 CVEs in its July 2024 Patch Tuesday release, with five critical vulnerabilities and three zero-day vulnerabilities, two of which were exploited in the wild.
How the regreSSHion Vulnerability Could Impact Your Cloud Environment
July 5, 2024With growing concern over the recently disclosed regreSSHion vulnerability, we’re explaining here what it is, why it’s so significant, what it could mean for your cloud environment and how Tenable Cloud Security can help.
- Cloud
- Container security
- Continuous Monitoring
- Incident Response
- Log Analysis
- Threat Intelligence
- Threat Management
- Vulnerability Management
- Vulnerability Scanning