e-Xpert Solutions Lausanne
Auteur : Gilliek
Date de publication : 21 décembre 2021 - Dernière mise à jour : 22 décembre 2021
La vulnérabilité impactant la librairie Open Source Log4j, CVE-2021-44228, a déjà fait couler beaucoup d’encre ces derniers jours ! En cause, sa criticité (CVSSv3 : 10) et sa portée : il s’agit en effet d’une librairie très largement utilisée par les applications écrites en Java (et autres langages s’appuyant sur la JVM). Cette vulnérabilité impacte les versions 2.0.0 à 2.15, soit potentiellement un grand nombre d’applications étant donné que la version 2.0.0 a été publiée en version stable en 2014.
Pour plus d’informations concernant cette vulnérabilité et comment elle fonctionne, consultez notre vidéo Youtube à travers le lien suivant :
Dans cet article, nous allons nous intéresser à comment mitiger cette vulnérabilité depuis les solutions F5 afin de protéger vos applications. Pour ce faire, nous allons présenter 2 approches différentes. La première se fera au niveau Local Traffic Manager (LTM -reverse proxy) à l’aide d’une iRule et ne nécessitera aucun autre module d’activé. La seconde va s’appuyer sur le Web Application Firewall (WAF) de F5, et va donc utiliser le module AWAF/ASM.
Le challenge à relever dans certains cas, c’est qu’il y a potentiellement un grand nombre de F5 et de Virtual Server à protéger et par conséquent déployer ces configurations peut vite prendre beaucoup de temps. De plus, il est difficile d’avoir une bonne visibilité sur ce qui est protégé et ce qui ne l’est pas. Pour pallier ces soucis, nous allons automatiser ces tâches et fournir de la visibilité à l’aide de nos 2 produits maison : Device Manager et Analytics Tool for F5.
Cette première approche consiste à utiliser une iRule qui va être attachée aux Virtual Servers de types HTTP.
Le contenu de l’iRule est disponible à l’URL suivante :
https://support.f5.com/csp/article/K59329043#proc2
Dans Device Manager, il nous faut tout d’abord uploader cette iRule dans le menu Tasks >> Hosted Content :
Puis de créer un nouveau script dans Tasks >> Scripts qui s’appelle patch-cve-log4j et qui est de type « iscript » avec le contenu suivant:
github.com/e-XpertSolutions/devmgr-resources/iscript/patch-cve-log4j.iscript.js
Nous voulons ici que l’utilisateur puisse saisir le device (ou les devices ayant un certain tag) sur lequel déployer l’iRule. Il nous faut donc créer un nouvel environnement de variables dans Tasks >> Variables :
Il ne reste plus qu’à créer la tâche qui va exécuter notre script, dans Tasks >> All Tasks :
Si un utilisateur exécute la tâche il sera prompté avec le formulaire suivant :
Il n’aura alors plus qu’à saisir le nom du device ou du tag et l’iRule sera provisionnée automatiquement la ou les destinations et sera rattachée à tous les VS qui ont un profile http.
Tournons-nous cette fois du côté de notre solution Analytics Tool for F5. Ce que nous proposons ici c’est un dashboard qui fournit la liste des VS par device avec leur niveau de protection : protégé par l’iRule ou non-protégé.
Voici à quoi ressemble le dashboard :
Afin d’éviter des requêtes inutiles sur les F5, ce dashboard récupère les informations directement sur le Device Manager et les présentes de façon unifiée. De plus, on s’appuie ici sur le Device Manager afin d’offrir la possibilité d’appliquer l’iRule via une action personnalisée :
Cette fois, plutôt que déployer une iRule qui analyse le payload des requêtes HTTP, nous allons déployer les signatures sur le Web Application Firewall.
L’idée consiste ici à activer la signature sur les différentes policies ASM. F5 fournit déjà un ensemble de signatures pour protéger contre la vulnérabilité de Log4j. Nous partons donc ici du principe que la liste des signatures est à jour sur les F5.
Comme avant, il nous faut créer un script dans Tasks >> Scripts qui s’appellera cette fois asm-signtatures-cve-log4j et qui est de type « iscript » avec le contenu suivant :
github.com/e-XpertSolutions/devmgr-resources/iscript/asm-signatures-cve-log4j.iscript.js
Il suffit maintenant de créer une nouvelle tâche pour appeler ce script :
Si un utilisateur exécute la tâche il sera prompté avec le formulaire suivant :
Il n’aura alors plus qu’à saisir le nom du device ou du tag et les signatures seront automatiquement activées sur les policies ASM.
Afin d’améliorer la visibilité des policies ASM qui sont équipées des signatures nous avons ce dashboard dans notre solution Analytics Tool for F5 :
Cela permet de rapidement identifier les policies qui ne protègent pas contre la vulnérabilité et d’y remédier à l’aide d’une action personnalisée qui permet d’appliquer les signatures directement depuis ce dashboard. Cette fonctionnalité s’appuie sur la tâche créée au niveau du Device Manager :
Ces 2 use-cases mettent en avant les capacités de nos 2 solutions, Device Manager et Analytics Tool for F5, pour mitiger la vulnérabilité Log4j. Ces use-cases fournissent un exemple de base et peuvent être facilement ajustés pour plus de flexibilité, comme par exemple restreindre la liste des objets (Virtual Server / politiques de sécurité WAF).
Il est aussi important de noter que nous avons implémenté cela pour la CVE-2021-44228, mais que ces approches sont génériques et pourraient tout à fait être réutilisées pour des vulnérabilités futures.
Events
Archives