Skip to main content
BlogSécuritéDigest de sécurité Linode 19-26 décembre 2021

Digest de sécurité Linode du 19 au 26 décembre 2021

Digest de sécurité Linode

Cette semaine, nous parlerons de l'évolution des vulnérabilités de Log4j2 et des mesures d'atténuation utiles que vous pouvez utiliser pour vous en protéger. 

L'évolution de la vulnérabilité

Les vulnérabilités "Log4Shell" ont commencé par la découverte d'une vulnérabilité critique d'exécution de code à distance dans la manière dont Log4j2 gérait les recherches lors de l'enregistrement d'événements sur les systèmes concernés. Cette vulnérabilité critique(CVE-2021-44228) a obtenu un score de 10 sur 10 dans le CVSS. Apache a déclaré que les versions 1.x de Log4j étaient moins susceptibles d'être vulnérables à cette découverte puisque JNDI devrait être délibérément activé. Apache a publié la version 2.15.0 pour remédier à cette vulnérabilité.

Après que Apache a publié des méthodes d'atténuation pour les utilisateurs qui ne pouvaient pas mettre à niveau Log4j2 vers la version 2.15.0, une autre vulnérabilité a été découverte grâce à l'attention que ce projet open source a reçue du fait qu'il était dans le collimateur du public. Cette vulnérabilité(CVE-2021-45046) était initialement une vulnérabilité DOS qui a obtenu un score de 3,7 sur 10, mais plus tard, elle a également été déclarée comme une vulnérabilité critique d'exécution de code, et le score a été relevé à 9 sur 10 sur CVSS. Apache a déclaré que les versions 1.x n'étaient pas vulnérables et a recommandé aux utilisateurs de Log4j2 de mettre à jour vers la version 2.16.0 pour résoudre ce deuxième problème. La méthode de suppression de la classe JNDI Lookup a été recommandée pour les utilisateurs qui ne pouvaient pas mettre à jour.

Puis vint la troisième vulnérabilité. Bien que (au 22 décembre) il n'y ait aucune mention d'exécution de code à distance dans la page de sécurité de la version 2.16.0 de Log4j2, cette vulnérabilité(CVE-2021-45105) a été notée 7,5 sur 10 dans CVSS, et elle pourrait seulement causer une attaque par déni de service sur les systèmes vulnérables. Apache a publié la version 2.17.0 et a recommandé à ses utilisateurs de faire une mise à jour pour résoudre le problème. Ils ont également partagé de nouvelles mesures d'atténuation pour les utilisateurs qui ne peuvent pas mettre à jour.

Il est important de noter que ces vulnérabilités étaient exploitées ou tentaient d'être exploitées pendant les phases de découverte et d'atténuation. Selon le blog de 360 Netlab, plusieurs familles de logiciels malveillants ont tenté de se propager en utilisant ces vulnérabilités. Les acteurs malveillants qui ont réussi à exploiter la vulnérabilité ont été vus en train d'implanter des mineurs de monnaie et d'installer des ransomwares. Ces rapports soulignent l'importance d'atténuer ces vulnérabilités dès que possible.

Méthodes officielles d'atténuation

Selon la page de sécurité de Log4j2, la mise à jour du composant vers la version 2.17 atténue les trois problèmes de sécurité connus. Pour les personnes qui ne peuvent pas mettre à jour leur Log4j2, Apache recommande de supprimer la classe JNDI Lookup de leur fichier vulnérable log4j2-core-*.jar. Cependant, cela n'est pas suffisant pour atténuer la vulnérabilité de déni de service découverte plus récemment(CVE-2021-45105). Vous pouvez atténuer cette vulnérabilité DOS en modifiant le PatternLayout dans la configuration de la journalisation. Vous pouvez consulter la page de sécurité Log4j2 de Apache, dont le lien figure au début de ce paragraphe, pour connaître les détails de ces méthodes d'atténuation.

Recherche des composants vulnérables

Si vous recherchez des composants vulnérables, vous pouvez utiliser les Log4j-Tools de jfrog. Les outils de ce dépôt sont utiles pour rechercher les appels vulnérables de Log4j JNDI Lookup sur une base de code où vous n'êtes pas sûr qu'un morceau de code appelle Log4j pour fonctionner. Il peut également vous aider à déterminer l'état de vulnérabilité des fichiers locaux. Vous pouvez également consulter les règles d'utilisation et d'exploitation de Log4j par Cisco CX Security Labs pour analyser vos fichiers locaux avec des règles YARA afin de déterminer si un fichier contient les classes Java vulnérables ; bien que cette méthode puisse fournir des résultats plus rapides, elle peut entraîner davantage de faux positifs ; cependant, ces règles peuvent également vous aider à localiser les composants dépendants de Log4j. 

Le dépôt Log4Shell Hashes de mubix contient les hachages MD5, SHA1 et SHA256 des fichiers log4j2-core vulnérables à la vulnérabilité RCE critique initiale(CVE-2021-44228). Enfin, vous pouvez consulter la base de données des logiciels vulnérables de la CISA (qui ne s'applique qu'à CVE-2021-44228) pour obtenir une liste complète des logiciels vulnérables par fournisseur.

Protection contre les attaques

Si vous ne pouvez pas mettre à jour votre installation de Log4j2 et si vous utilisez Fail2Ban sur votre serveur, Fail2Ban regex against Log4Shell par Jay Gooby peut vous aider à bloquer les tentatives de Log4Shell. Si vous utilisez CloudFlare, vous pouvez utiliser leurs règles WAF pour vous protéger contre ces attaques. Cependant, selon les conseils de CISA, il est recommandé de mettre à jour vers Log4j 2.17.0 ou d'appliquer immédiatement les mesures d'atténuation recommandées. Il est également important de consulter les déclarations des fournisseurs concernant les autres logiciels qui utilisent Log4j2, car certains logiciels peuvent être livrés avec une version vulnérable de Log4j qui pourrait nécessiter une attention particulière.

Trouver des CIO et scanner

Si vous recherchez des indicateurs de compromission dans vos journaux, il peut être difficile de déterminer s'il y a eu des tentatives d'exploitation de cette vulnérabilité, principalement parce qu'il existe de nombreuses charges utiles différentes qui peuvent être envoyées pour exploiter le vecteur d'attaque JNDI connu. Un attaquant peut coder les chaînes de caractères dans la charge utile, les obscurcir ou les rendre difficiles à détecter lors de la recherche de charges utiles simples. C'est là que Log4Shell-Rex de back2root peut s'avérer utile. Log4Shell-Rex est une expression régulière créée pour correspondre à d'éventuelles charges utiles malveillantes encodées avec différentes méthodes. Vous pouvez l'utiliser sur vos fichiers journaux locaux ou dans votre SIEM pour faire correspondre les résultats. Il convient toutefois de noter que les recherches effectuées à l'aide de cette expression régulière (ou de toute autre expression régulière) peuvent générer des faux positifs ou des faux négatifs.

Vous pouvez également consulter l'outil Log4j-scan de FullHunt qui peut vous aider à découvrir la vulnérabilité RCE(CVE-2021-44228). Vous pouvez également utiliser cet outil pour tester les contournements du WAF afin d'obtenir des résultats de balayage plus complets.

Nous espérons aider nos clients en partageant des informations utiles dans ces bulletins de sécurité. Comme toujours, n'hésitez pas à nous faire part de vos réflexions en laissant un commentaire ci-dessous.


Commentaires

Laissez un commentaire

Votre adresse électronique ne sera pas publiée. Les champs obligatoires sont marqués d'un *.