Avec le dernier mois de 2021 dominé par la découverte, la publication et les correctifs des vulnérabilités log4J qui se succèdent rapidement, il y a de fortes chances que vous ayez corrigé votre système contre les tentatives d’exploitation de Log4J. Au moins certains systèmes, sinon tous. Vous avez peut-être même installé le dernier correctif – au moment de la rédaction, c’est-à-dire 2.17.1, mais, si le dernier cycle de correctifs rapide persiste, il peut avoir changé au moment de sa publication.
Pendant ce temps, les défenseurs ont peut-être fait des heures supplémentaires pour combler les failles de sécurité nées de Log4J, mais les cyber-attaquants aussi. La renommée bien méritée de Log4J a également alerté les cyber-attaquants sur une voie d’entrée potentielle dans leur cible. Et, alors que log4J disparaîtra, espérons-le, des gros titres, les cyber-attaquants vont probablement continuer à essayer de l’exploiter dans l’espoir de trouver des cibles non corrigées ou incomplètement corrigées.
Comme l’erreur humaine représente toujours 95 % de toutes les failles de sécurité, les cyber-attaquants s’appuient activement sur ces erreurs humaines pour les exploiter et tirer parti d’un faux sentiment de sécurité dérivé, en supposant que les correctifs ont été appliqués avec succès.
La saga Log4J est une tempête parfaite pour générer un grand nombre d’erreurs de patch car elle combine :
1 — Stress aigu: Log4J a été nommé la pire vulnérabilité depuis des décennies et qualifié par Cloudflare de « tellement mauvais que nous allons essayer de déployer au moins une protection pour tous les clients @Cloudflare par défaut, même les clients gratuits qui n’ont pas notre WAF ».
La pression pour corriger avant qu’une vulnérabilité puisse être exploitée par un cyber-attaquant était intense. Alors que la crise s’aggravait avec la combinaison de la publication de nouveaux patchs et d’un liste croissante de fournisseurs concernés, le niveau de stress n’a fait que s’intensifier. Pourtant, un Étude de la NASA de 2015 démontre que « le stress situationnel peut nuire à la cognition et aux performances des pilotes, ainsi que des experts dans d’autres domaines ».
2 — Cycles de correctifs frénétiques: Entre le 6 et le 27 décembre, quatre patchs distincts ont été publiés, chacun consistant en une nouvelle version du Log4J, chacun nécessitait donc une mise à niveau vers une nouvelle version, et le faire sans rien casser. Tant de mises à jour en si peu de temps ont un impact négatif sur le niveau de confiance dans la valeur du correctif et j’augmente les risques d’erreurs de correctif ou d’oubli.
C’est une bonne nouvelle pour les cyber-attaquants qui sont susceptibles de continuer à armer les vulnérabilités de Log4J pendant des mois et des années à venir.
La meilleure défense contre les exploits actuels et futurs liés à Log4J est de valider que votre correctif est complet et correctement appliqué. L’exécution d’analyseurs de vulnérabilité mis à jour Log4J est un bon point de départ mais, malheureusement, aucun analyseur ne peut détecter toutes les dépendances indirectes ou transitives de Log4J, en particulier lorsqu’il est intégré en tant que dépendance transitive sans définition explicite de Log4J.
Angles morts Log4J des scanners signifient que la validation de l’efficacité du processus de correction par le biais de tests offensifs est une nécessité non facultative. Cette méthodologie détermine si les règles que vous avez définies pour dévier les demandes malformées de Log4J sont efficaces ou si un réglage supplémentaire est nécessaire. Une méthode d’exécution log4J pourrait être utilisée par les red teamers prêts à l’emploi.
En utilisant ces techniques de test offensives, certains clients ont efficacement détecté les vulnérabilités Log4J induites par la chaîne d’approvisionnement avant que le fournisseur n’ait publié un correctif.
L’avantage de exécution d’une validation de sécurité continue et complète est que le resserrement résultant des contrôles de sécurité propriétaires et tiers limite l’exposition à des inconnues inconnues, car il expose les points faibles et fournit des recommandations exploitables pour les fermer.
Pour éviter les risques résultant de la combinaison mortelle d’un stress aigu, d’un cycle de correctifs frénétique et d’instances cachées, que ce soit pour Log4J ou le prochain grand – et même petit – il vaut la peine d’effectuer une validation continue qui non seulement recherche les vulnérabilités, mais aussi des tests en toute sécurité si la charge utile sécurisée pour la production a été détectée et arrêtée efficacement, et évalue en profondeur l’efficacité de vos politiques et contrôles de sécurité avant et après l’application des correctifs.
Pour plus d’informations, visitez cymulate.com.
