Fermer

décembre 15, 2021

Ne paniquez pas : Log4Shell – Blogs performants


Comme beaucoup d'entre vous, nous avons passé notre week-end et le début de cette semaine à trier les risques posés par CVE-2021-44228 (alias Log4Shell).

Comme nous l'avons vérifié et en corrigeant nos systèmes internes, nos produits et nos systèmes clients, certains collègues et moi avons fait quelques observations que nous voulions partager.

Tout d'abord, cependant. Si vous êtes préoccupé par les risques posés par cette vulnérabilité log4j, nous vous recommandons de vous assurer que vous avez corrigé les produits du fournisseur conformément aux instructions du fournisseur et de vous assurer que tous vos systèmes sont mis à jour pour utiliser log4j 2.16.0 ou une version plus récente. En outre, voici quelques autres ressources provenant de sources et de partenaires de confiance que nous trouvons utiles :

Quelques autres notes techniques…

  1. log4j 2.15.0 semble être pour la plupart sûr, mais il existe plusieurs situations où ce correctif est incomplet car décrit dans CVE-2021-45046nous vous recommandons d'utiliser 2.16.0 dans la mesure du possible. Il s'agit d'une situation dynamique, et cela peut à nouveau changer à mesure que des tests plus approfondis continuent d'être effectués.
  2. log4j 1.2.x a une vulnérabilité similaire mais plus limitée et aucun correctif ne sera disponible car cette version de log4j a dépassé la fin de vie . Le score CVSS 3.0 pour CVE-2021-4104 est toujours en attente, mais nous nous attendons à ce que le niveau de risque soit inférieur compte tenu des chemins de code limités qui semblent être affectés, mais il existe encore une certaine incertitude ici. Plus d'informations devraient être disponibles bientôt, mais le TL;DR est que vous devriez être d'accord si vous n'utilisez pas JMSAppenders, mais cela peut encore évoluer.
  3. N'oubliez pas que log4j peut ne pas être une dépendance directe de votre code, il peut être une dépendance d'une dépendance ou plus bas dans l'arbre des dépendances. Il est important d'utiliser votre outil de gestion des dépendances (c'est-à-dire Maven, Gradle, etc.) pour rechercher dans l'arborescence complète des références à log4j.
  4. La vulnérabilité elle-même est assez simple et incroyablement facile à exploiter. Il utilise la magie des recherches JNDI, une fonctionnalité de Java qui vous permet d'interagir de manière transparente avec une variété de services d'annuaire et de nommage. Dans ce cas, l'exploit utilise LDAP (Lightweight Directory Access Protocol) et une petite astuce pour obtenir la recherche JNDI pour extraire ce qu'il pense être un objet d'un serveur LDAP via une redirection vers un point de terminaison https mais c'est vraiment du code qui sera exécuté sur le serveur vulnérable. Le risque ici est que n'importe quel endroit dans une application pour lequel un utilisateur peut transmettre une entrée textuelle et que le texte est enregistré tel quel, sera susceptible de recevoir un code arbitraire qui lui sera transmis et exécuté dans cette entrée de texte.

Passons maintenant à la partie intéressante. Alors que nous en discutions en interne, nous avons réalisé quelques points sur le risque posé par la vulnérabilité log4shell : . " Il y a deux manières principales que cette pensée est imparfaite. Premièrement, empêcher parfaitement un acteur malveillant d'accéder à votre réseau est impossible. Non seulement les pare-feu ne sont pas parfaits, mais l'ingénierie sociale et les employés en colère peuvent les contourner complètement. Deuxièmement, ce type de vulnérabilité peut être exploité en cascadant une chaîne incriminée d'un système à l'autre via des appels de service le long de la chaîne jusqu'à ce qu'il en trouve une qui soit vulnérable.

  • Chaque fournisseur de logiciels adopte une approche différente. Même ceux qui conviennent que l'échange des pots est la bonne décision ne sont pas d'accord sur la façon dont ils veulent livrer cela aux clients. Nous trouvons qu'il est important de prendre le temps d'évaluer l'approche de chaque fournisseur et de suivre attentivement leurs instructions pour vous assurer de ne pas créer plus de problèmes que vous n'en résolvez. Cela dit, il faut de la patience pour laisser aux fournisseurs le temps non seulement d'identifier les produits vulnérables et de publier un correctif, mais également de tester ce correctif et de s'assurer qu'il ne provoque pas de régressions problématiques.
  • Il n'est pas du tout surprenant de voir comment. c'est répandu, mais il est surprenant qu'il ait été trouvé à cause de Minecraft. Il s'avère que Minecraft est écrit en Java et utilise log4j2. Il semble que les serveurs Minecraft enregistraient, par défaut, tous les messages saisis dans le chat. Cela signifiait que n'importe qui pouvait mettre une recherche JNDI malveillante dans le chat sur un serveur multijoueur Minecraft et exploiter cette vulnérabilité. Voici une excellente vidéo montrant comment cela fonctionne y compris comment obtenir un shell distant sur un serveur Minecraft.
  • Si vous avez besoin d'aide pour résoudre les problèmes ou pour concevoir une stratégie d'optimisation réponse la prochaine fois (car il y aura certainement une prochaine fois), en tant que partenaire et conseiller de confiance, nous sommes prêts, disposés et capables de vous aider.

    N'oubliez pas votre serviette.

    À propos de l'auteur <!–:   ewalk, Director–>

    10 ans d'expérience, spécialisé dans l'architecture et la planification du système, les installations et mises à niveau de plate-forme, et la formation d'administrateur système pour un large éventail de contenus, de processus et Plateformes de données.

    En savoir plus sur cet auteur




    Source link