Patcher Log4j vers la version 2.17.1 peut probablement attendre

décembre 29, 2021 Par admin 0
Patcher Log4j vers la version 2.17.1 peut probablement attendre

Crédit image: The Apache Software Foundation

Écoutez les DSI, les directeurs techniques et d'autres cadres supérieurs et cadres supérieurs sur les stratégies de données et d'IA lors du sommet sur l'avenir du travail du 12janvier. 2022. En savoir plus

Un certain nombre de professionnels de la sécurité affirment que la dernière vulnérabilité d'Apache Log4j, divulguée mardi, ne pose pas de risque de sécurité accru pour la majorité des organisations. Par conséquent, pour de nombreuses organisations qui ont déjà appliqué un correctif à la version 2.17.0 de Log4j, publiée le 17 décembre, il ne devrait pas être nécessaire d'appliquer immédiatement un correctif à la version 2.17.1, publiée mardi.

Bien que la dernière vulnérabilité « ne doive pas être ignorée », bien sûr, pour de nombreuses organisations, elle « devrait être déployée à l'avenir dans le cadre du déploiement habituel des correctifs », a déclaré Ian McShane, directeur de la technologie chez Arctic Wolf. , dans des commentaires partagés par e-mail avec VentureBeat.

Casey Ellis, fondateur et directeur de la technologie chez Bugcrowd, l'a décrit comme une « faible vulnérabilité de sauce » et a déclaré que sa divulgation semble ressemble plus à un effort de marketing pour des produits de test de sécurité qu'à un «effort réel pour améliorer la sécurité».

malheurs

La divulgation de la dernière vulnérabilité intervient alors que les équipes de sécurité traitent un correctif après l'autre depuis le premier divulgation d'une exécution critique de code à distance (R CE) dans le logiciel de journalisation Log4j largement utilisé le 9 décembre.

La dernière vulnérabilité apparaît dans la liste des vulnérabilités et expositions communes (CVE) en tant que 2021-44832, et a une cote de gravité «moyenne» (6,6). Il permet à « un attaquant autorisé à modifier le fichier de configuration de journalisation construire une configuration malveillante », selon la description officielle.

Cependant, pour les équipes qui ont travaillé sans arrêt pour résoudre les vulnérabilités de Log4j ces dernières semaines, il est important de comprendre que le les risques posés par la dernière vulnérabilité de Log4j sont beaucoup plus faibles que les failles précédentes – et peuvent ne pas être le moment de « tout laisser tomber et de corriger », selon les professionnels de la sécurité. Bien qu'il soit possible qu'une organisation dispose des configurations requises pour exploiter CVE-2021-44832, ce serait en fait un indicateur d'un problème de sécurité beaucoup plus important pour l'organisation.

La dernière vulnérabilité est techniquement une RCE, mais elle « ne peut être exploitée que si l'adversaire a déjà obtenu l'accès par un autre moyen », a déclaré McShane. En comparaison, la vulnérabilité RCE initiale, connue sous le nom de Log4Shell, est considérée comme triviale à exploiter et a été classée comme une faille de gravité inhabituellement élevée (10.0).

Un problème de niche

La dernière vulnérabilité Log4j nécessite les mains- sur l'accès au clavier à l'appareil exécutant le composant, afin que l'acteur malveillant puisse modifier le fichier de configuration pour exploiter la faille, a déclaré McShane.

« Si un attaquant a un accès administrateur pour éditer un fichier de configuration, alors vous êtes déjà en difficulté et ils n'ont même pas utilisé l'exploit », a-t-il déclaré. « Bien sûr, c'est un problème de sécurité, mais c'est un créneau. Et il semble exagéré qu'un attaquant laisse des miettes de pain inutiles comme la modification d'un fichier de configuration. La balise RCE pourrait amener les gens à interpréter », a déclaré McShane.

En effet, a déclaré Ellis, la nouvelle vulnérabilité « nécessite un ensemble de conditions assez obscur pour se déclencher. »

« Bien qu'il soit important pour les gens de garder un œil sur les CVE nouvellement publiés pour la connaissance de la situation, ce CVE ne semble pas augmenter le risque déjà élevé de compromis via Log4j », il a déclaré dans une déclaration partagée avec VentureBeat.

Surhyping?

Dans un tweet mardi, Katie Nickels, directrice du renseignement chez Red Canary, a écrit à propos de la nouvelle vulnérabilité Log4j qu'il est préférable de «se rappeler que toutes les vulnérabilités ne sont pas créé de manière égale. »

« Notez qu'un adversaire *devrait pouvoir modifier la configurationpour que cela fonctionne… ce qui signifie qu'ils ont déjà accéder d'une manière ou d'une autre », a écrit Nickels. fichier de configuration' ou vous surestimez cette vulnérabilité », a ajouté Chris Wysopal, cofondateur et directeur de la technologie chez Veracode, dans un tweet mardi. «C'est ainsi que vous ruinez les relations avec les équipes de développement.»

Log4j 2.17 RCE CVE-2021-44832 en quelques mots pic.twitter.com/GPaHcDHlj0

— Florian Roth ⚡️ (@cyb3rops) 28 décembre 2021

  • « Dans la chaîne d'attaque la plus compliquée de tous les temps, l'attaquant a utilisé un autre vuln pour accéder au serveur, puis a fait fonctionner CS, puis a utilisé CS pour éditer le fichier de configuration/redémarrer le service pour ensuite exploiter à distance le vuln », a tweeté Rob Morgan, fondateur de Factory Internet. «Oui, totalement la meilleure méthode!»

    Une vulnérabilité généralisée

    De nombreuses applications d'entreprise et services cloud écrits en Java sont potentiellement vulnérables aux failles de Log4j. On pense que la bibliothèque de journalisation open source est utilisée sous une forme ou une autre – directement ou indirectement en tirant parti d'un framework Java – par la majorité des grandes organisations.

    Version 2.17.1 de Log4j est le quatrième correctif pour les vulnérabilités dans le logiciel Log4j depuis la découverte initiale de la vulnérabilité RCE, mais les trois premiers correctifs ont été considérés comme bien plus essentiels.

    Version 2.17 .0 résout le potentiel d'attaques par déni de service (DoS) dans la version 2.16, et la gravité de la vulnérabilité a été classée comme élevée.

    La version 2.16, à son tour, avait corrigé un problème avec le correctif de la version 2.15 pour Log4Shell qui ne résolvait pas complètement le problème RCE dans certaines configurations. La vulnérabilité initiale pourrait être utilisée pour permettre l'exécution à distance de code par des utilisateurs non authentifiés.

    VentureBeat

    La mission de VentureBeat est d'être une place publique numérique pour les décideurs techniques afin d'acquérir des connaissances sur la technologie transformatrice et d'effectuer des transactions. Notre site fournit des informations essentielles sur les technologies et les stratégies de données pour vous guider dans la gestion de vos organisations. Nous vous invitons à devenir membre de notre communauté, pour accéder à :

  • des informations à jour sur les sujets qui vous intéressent

  • nos newsletters

    contenu de leader d'opinion et accès à prix réduit à nos événements prisés, tels que Transformer 2021

    : Apprendre encore plus

    fonctionnalités de mise en réseau, et plus

    Devenir membre