Comment protéger au mieux votre organisation contre Log4j, une vulnérabilité basée sur Java

Ce Noël, les administrateurs du monde entier ont reçu un cadeau empoisonné et les acteurs malveillants ont eu une surprise avant l'heure : la vulnérabilité Log4j. Cette faille touche un composant très utilisé dans de nombreux services et applications logiciels. Elle ne concerne pas une entreprise en particulier, mais pourrait toucher des centaines ou des milliers de produits : équipement réseau, logiciels de gestion des serveurs, applications grand public ou spécialisées pour les entreprises, pour n'en nommer que quelques-uns. Les fournisseurs devront se précipiter pour mettre à jour les logiciels vulnérables avec les correctifs adaptés aux vulnérabilités découvertes.

Dans cet article de blog, Jamf vise à informer les utilisateurs qui ne connaissent pas cette vulnérabilité critique (et toute vulnérabilité ultérieure), et à offrir à ceux qui connaissent le problème des conseils basés sur les bonnes pratiques de sécurité visant à corriger ces vulnérabilités.

• Qu'est-ce que Log4j et pourquoi est-ce un problème majeur ?
• Quels produits Jamf sont concernés par la vulnérabilité et comment Jamf la traite-t-elle ?
• Comment les produits Jamf peuvent-ils aider votre organisation à répondre aux menaces ?

Partie 1 : Qu'est-ce que Log4j ?

Prononcée « Log Forge » en anglais, la vulnérabilité critique est une faille qui existe dans la célèbre bibliothèque de journalisation basée sur Java, Log4j. Elle est susceptible d'être exploitée pour une exécution de code à distance (RCE). Initialement désignée par l'identifiant CVE CVE-2021-44228, la vulnérabilité fait référence à la faille dans le logiciel Apache Log4J, une bibliothèque utilisée par différentes applications pour journaliser des informations pendant l'exécution d'applications Java. C'est l'une des bibliothèques les plus utilisées, sinon la plus utilisée, par les développeurs, aussi bien pour les logiciels open source que pour les logiciels commerciaux.

Partie 2 : Pourquoi est-ce un problème majeur ?

Cette bibliothèque étant utilisée et implémentée par de nombreux fournisseurs et appareils, l'impact réel de cette menace grave n'est pas quantifiable. Ce que nous savons, c'est que les vulnérabilités de type RCE la classent comme une menace sévère, car l'exploitation de cette faille permet aux acteurs malveillants d'exécuter du code à distance sur les systèmes concernés sans y être nécessairement autorisés. Ces types d'attaques permettent aux pirates d'exploiter les appareils et potentiellement les données qu'ils contiennent. La vulnérabilité initiale permettait à un pirate de demander à la bibliothèque Log4j de télécharger un code arbitraire à partir d'un serveur que ce pirate contrôlait et de l'exécuter comme s'il faisait partie de l'application elle-même. Un fraudeur pouvait ainsi prendre le contrôle de toute application qui utilisait Log4j, même s'il ne s'était jamais authentifié sur le service à l'aide de la bibliothèque.

Et lorsque nous avons parlé de « vulnérabilités » ci-dessus, ce n'était pas une faute de frappe. Ce pluriel fait référence à une deuxième vulnérabilité (CVE-2021-45046) découverte à la suite d'une correction de la vulnérabilité initiale qui s'est avérée incomplète en raison de certaines configurations non standards. Le point positif est que cette vulnérabilité supplémentaire semble être du type attaque par déni de service (DoS) plutôt qu'attaque de prise de contrôle du service.

Que cela signifie-t-il pour la résolution de Log4j, vous demandez-vous ? Eh bien, c'est déjà un peu mieux, même si cela reste compliqué. Dans des cas comme celui-ci, il n'est pas rare que plusieurs niveaux de mises à jour soient nécessaires pour corriger complètement la menace. Cette deuxième vulnérabilité identifiée n'autorise plus les exploitations RCE, même si elle permet toujours aux pirates de créer des données d'entrée malveillantes résultant en une attaque DoS.

Partie 3 : Comment cette vulnérabilité affecte-t-elle Jamf ?

Comme ceux de nombreux autres fournisseurs, dont Apple, Google et Microsoft, certains produits Jamf ont malheureusement été touchés par la vulnérabilité Log4j. En raison de la nature des vulnérabilités CVE-2021-44228 et CVE-2021-45046, de leur sévérité critique et de leur potentiel impact sur les services, Jamf a rapidement réagi. Aaron Kiemele, responsable de la sécurité informatique de Jamf, a créé une publication dédiée sur Jamf Nation, afin de donner aux utilisateurs Jamf les dernières informations sur la manière dont Log4j impacte les services Jamf et sur les stratégies mises en œuvre par Jamf pour remédier à cette menace.

• Jamf Pro (sur site) : version corrigée disponible
• Jamf Pro (Cloud) : atténué et corrigé
• Jamf Connect : non concerné
• Jamf Now : non concerné
• Jamf Protect : non concerné
• Jamf School : non concerné
• Jamf Threat Defense : non concerné
• Jamf Data Policy : non concerné
• Jamf Private Access : non concerné
• Health Care Listener : non vulnérable
• Gestionnaire d’infrastructure Jamf : non vulnérable

D'après Matthias Wollnik, responsable de marketing produit spécialisé en sécurité chez Jamf, « le Gestionnaire d’infrastructure Jamf (JIM, Jamf Infrastructure Manager) ne journalise que des données opérationnelles internes, et aucune information non fiable ou fournie par le client. Ainsi, un pirate n'a pas la possibilité de fournir un message à Log4j qui lui permettrait d'exploiter les vulnérabilités récentes. »

...et quelles stratégies d'atténuation ont été mises en place par Jamf ?

Pour les instances Jamf Pro qui sont sur site ou hébergées par votre organisation, le problème est entièrement résolu à partir de la version 10.34.2, qui inclut log4j 2.16. Une version précédente (10.34.1) a été lancée avec log4j 2.15. Les dernières informations indiquent que log4j 2.15 nécessite une configuration supplémentaire pour être protégé de CVE-2021-45046. Jamf conseille aux administrateurs sur site de mettre à jour leur système vers la version 10.34.2 dès que possible.

Si votre organisation ne peut pas passer à cette dernière version pour l'instant, vous pouvez opter pour une solution alternative en mettant à jour manuellement l'instance Log4j sur les systèmes concernés et en définissant la configuration correspondante, comme indiqué dans la documentation technique de Jamf. Cette solution temporaire n'empêchera pas les futures mises à jour.

Les instances Jamf Pro hébergées sur le Cloud ont été atténuées par le biais des contrôles de sécurité appropriés et ne sont pas vulnérables pour le moment. Cependant, par précaution supplémentaire, Jamf Pro 10.34.2 est également déployé pour ces clients également.

Partie 4 : Que pouvons-nous faire pour nous protéger ?

Application de correctifs

La vulnérabilité Log4j a une telle portée mondiale que, aux États-Unis, l'agence Cybersecurity & Infrastructure Security Agency (CISA) a créé un site web et un dépôt GitHub pour suivre cette faille touchant la bibliothèque Apache Log4j et y répondre. De plus, la CISA a fourni des informations sur les vulnérabilités sous la forme d'un document régulièrement mis à jour qui propose aux administrateurs et équipes de sécurité des informations actualisées sur la manière de protéger les systèmes concernés : sources continues de règles de détection pour percer les exploitations, hachages Log4Shell, guides d'atténuation pour les développeurs et fournisseurs de logiciels, et ressources supplémentaires pour les agences internationales, telles que celles d'Amérique du Nord, d'Europe et d'Asie.

« Installez rapidement et souvent les correctifs » - Jamf

Vous devez appliquer les correctifs obtenus sur le site web de votre développeur de logiciels pour corriger la vulnérabilité Log4j, ou, au moins, mettre en place une solution alternative permettant de mettre à jour les bibliothèques Log4j vulnérables qui peuvent être intégrées dans des composants de l'application ou du service qui en dépend.

Grâce à Jamf Pro, les administrateurs informatiques peuvent facilement identifier quels systèmes ont d'anciennes versions des applications concernées. Ils peuvent également créer des Groupes intelligents pour regrouper dynamiquement ces systèmes et utiliser la fonctionnalité de déploiement de logiciels pour mettre à jour directement les apps concernées ou déployer à distance les correctifs, selon les besoins.

En outre, ils peuvent (et doivent) suivre certaines procédures de sécurité fondamentales pour limiter l'exposition de l'organisation aux menaces de sécurité ou tenter d'atténuer les risques découlant des vulnérabilités Log4j.

Évaluation des risques

Comment savoir quels produits et systèmes sont vulnérables si vous ne connaissez pas votre infrastructure ? C'est la première étape : déterminer quels appareils, apps et services forment l'infrastructure de votre organisation. Un inventaire à jour vous permet de connaître précisément les ressources dont votre organisation dispose, la manière dont elles sont utilisées et pourquoi elles sont utilisées exactement. Grâce à ces informations, les administrateurs peuvent facilement déterminer quels éléments sont à risque, et le niveau de risque, avant de déployer des stratégies d'atténuation.

Nomenclature logicielle

La nomenclature logicielle, ou SBOM (Software Bill of Materials) est un inventaire des composants logiciels, qui propose aux organisations et aux développeurs une description précise et claire des éléments fondamentaux des composants intégrés aux applications et aux services logiciels. Son avantage pour l'entreprise est qu'elle permet aux équipes de sécurité de déterminer facilement quels composants peuvent être exposés à une vulnérabilité donnée dans les apps internes et tierces utilisées.

Défense en profondeur

Cette bonne pratique de sécurité a prouvé qu'elle pouvait protéger les ressources en empilant plusieurs couches de sécurité. Chaque couche est basée sur la solution précédente pour renforcer la sécurité globale des systèmes, des apps et des services. Bien que les stratégies de défense en profondeur ne résolvent pas la vulnérabilité sous-jacente, elles peuvent contrer ses effets en limitant la surface d'attaque d'une application concernée ou en contenant l'exposition.

Par exemple, Jamf Protect peut être utilisé pour identifier les pirates qui tirent parti de la vulnérabilité. Depuis hier, les clients disposent d'une nouvelle détection appelée SuspiciousJavaActivity (activité Java suspecte) dans leur interface. Cette détection recherche les commandes curl ou bash -i qui s'exécutent sous Java. Il s'agit d'un comportement que de nombreux pirates adoptent pour exploiter la vulnérabilité Log4j. S'il est détecté, cela peut indiquer qu'une exploitation Log4j a eu lieu. Cependant, certaines applications Java légitimes peuvent également effectuer ces actions (rarement, espérons-nous). Il appartient à l'analyste de sécurité de déterminer ce qui est normal ou non pour l'application en question.

Notez bien que les systèmes macOS personnels sont peu susceptibles d'avoir une application active (et encore moins plusieurs) utilisant Log4j avec laquelle un pirate peut interagir à distance. Les analystes peuvent garder cela à l'esprit lorsqu'ils tentent de déterminer si une alerte doit être étudiée ou ignorée.

Moindre privilège

Le principe du moindre privilège est largement considéré comme un élément de base que les administrateurs intègrent à leurs processus de sécurité pour limiter l'accès des utilisateurs au strict nécessaire afin d'assurer leur productivité, ni plus, ni moins. Ce principe s'applique au niveau de l'hôte, de l'application et du réseau, et tous ces niveaux peuvent être renforcés pour empêcher les systèmes victimes de l'exploitation RCE de Log4j de lancer des connexions en tant que commande de sortie. Ce type de sécurité permet aux administrateurs de verrouiller et de contenir les systèmes compromis jusqu'à ce que la vulnérabilité soit corrigée.

Pare-feux d'applications web

Les pare-feux d'applications web (WAF) sont d'excellents logiciels de protection qui bloquent efficacement les tentatives de communication avec les services et les applications affectés par la vulnérabilité Log4j. En résumé, les chaînes non masquées, ainsi que celles avec des techniques d'évasion simples devraient être facilement arrêtées par un WAF efficace. Cependant, comme les chercheurs l'ont remarqué, les acteurs malveillants adaptent de plus en plus leur utilisation du langage Log4j et incluent des chaînes de clé encodées pour échapper à la détection utilisant des recherches plus complexes afin de masquer les chaînes critiques. Les équipes de sécurité doivent prendre soin de faire évoluer leurs règles de WAF pour identifier et bloquer ces chaînes masquées, afin d'empêcher les tentatives d'exploitation des systèmes essentiels.

Surveillance et rapports

Les recherches actives de systèmes vulnérables à Log4j n'ont jamais été aussi nombreuses, selon plusieurs agences de sécurité. Et pour aggraver encore la situation, des éléments laissent à penser que certaines nations soutiennent les acteurs malveillants, alors que les attaques continuent à évoluer. Il est essentiel pour protéger la posture de sécurité de votre organisation de surveiller activement votre infrastructure, non seulement pour identifier les systèmes et applications vulnérables, mais également pour évaluer la santé des appareils. En outre, consultez les rapports pour détecter les indicateurs clés de compromission, notamment les hachages associés à l'exploit « Log4Shell », afin d'obtenir les informations sur les menaces nécessaires pour ajuster les protections, comme les WAF, et atténuer les risques en cours.