wafw00f – étude et utilisation d’un outil de détection de WAF

I. Présentation

Nous allons dans cet article nous intéresser à l'outil wafw00f, son utilisation (basique) et surtout son fonctionnement, car il est toujours intéressant de savoir comment fonctionnement nos outils, et notamment quelles sont leurs limites.

wafw00f est un outil détection de pare-feu applicatif web (ou WAF, Web Application Firewall). Son rôle est d'aider a identifier la présence d'un pare-feu, mais aussi sa technologie.

Un Web Application Firewall (WAF) est un type de pare-feu qui protège le serveur d'applications Web dans le backend contre diverses attaques. Le WAF garantit que la sécurité du serveur Web n'est pas compromise en examinant les paquets de requête HTTP / HTTPS et les modèles de trafic Web.  

II. Détecter un WAF, pour quoi faire ?

Encore une fois, la cartographie et l'identification des technologies utilisées est une étape importante qui va "guider" l'attaquant dans ses attaques. La version X.X d'Apache Tomcat est vulnérable à une attaque de type exécution de commande à distance ? Il me suffit d'identifier si ma cible utilise cette version et cette techno et le tour est joué. Au contraire, si je n'ai aucune idée des technologies utilisées, je vais devoir exécuter un grand nombre d'attaques et de tests (dont la majorité sont inutiles) et ainsi augmenter mes chances de me faire détecter.

Pour les WAF, leur identification a plusieurs objectifs :

• Il est toujours intéressant de savoir si nos attaques peuvent être menées librement sur l'application web visée ou si un système en amont est présent pour les bloquer, il faudra alors trouver des contournements ou des astuces pour passer outre ce système (encodage simple, encodage multiple, etc. ). Les méthodes de contournement de WAF peuvent faire l’objet de plusieurs longs articles tellement c'est un sujet vase.
• Identifier la technologie précise d'un WAF nous permet potentiellement d’utiliser des méthodes contournement connues pour cette technologie
• Comme les services et applications web, les WAF peuvent eux aussi être la cible de vulnérabilités connues. Prenons par exemple les pare-feu Big IP qui, dans leur configuration par défaut, faisaient fuiter les IP internes des serveurs web qu'ils étaient censé protéger (voir mon article BigIP_backendScan : cookies BigIP et fuite d’information)
• Enfin, lorsque l'attaquant souhaite être discret, la présence ou non d'un WAF est une information importante à prendre en compte car ceux-ci peuvent lever des alertes en direction des administrateurs et journaliser les accès et requêtes suspects.

III. Utilisation standard de wafw00f

wafw00f est installé par défaut sur la distribution KaliLinux. Vous pouvez également l'installer depuis les dépôts Debian par exemple :

apt-get install wafw00f

Ou depuis le Github du projet :

git clone https://github.com/EnableSecurity/wafw00f
cd  wafw00f  
python setup.py install 

L'utilisation de wafw00f est tout aussi simple, si je souhaite repérer la présence d'un WAF sur wikipedia.org :

wafw00f https://wikipedia.org

La même chose sur mon propre blog, hébergé par OVH :

On voit ici que mon blog semble ici être derrière un pare-feu Juniper WebApp Secure. Différentes options sont à notre disposition. On peut notamment lister toutes les technologies WAF pouvant être identifiées par wafw00f avec l'option --list :

En date d'écriture de cet article, 123 technologies différentes peuvent être identifiées par wafw00f.

IV. Fonctionnement de wafw00f

La méthodologie de détection de wafw00f peut ironiquement être comparée à celle d'un antivirus. Nous allons en effet voir que principalement deux méthodes sont utilisées.

Commençons par regarder comment il fonctionne de manière globale, son code étant en source ouverte (open source), rien de plus simple que d'aller sur le Github du projet : https://github.com/EnableSecurity/wafw00f

En parcourant le code de wafw00f , on observe dans le répertoire plugins un grand nombre de fichiers qui possèdent en général moins de 3 ou 4 tests :

Ces grâce à ces tests que wafw00f détecte une signature, technique ou comportement d'un WAF, ils sont joués les uns à uns auprès d'une cible jusqu'à détection d'une technologie. Tous les pare-feu ne réagissent, par défaut, pas aux mêmes charges utiles et pas de la même façon, certains ajoutent des en-têtes ou des cookies dans la réponse du serveur, d'autres ont des pages d'erreurs spécifiques, etc. Wafw00f se base sur les deux méthodes suivantes pour détecter la présence d'un WAF et en déduire sa technologie.

A. L'analyse par "signature"

L’outil va se baser sur la présence d'un cookie ou d'un en-tête dans les réponses du serveur lors de l'envoi de requêtes "normales" (ne contenant pas de charges utiles malveillantes) et de requêtes malveillantes . Ces cookies sont ajoutés non pas par l'application web, mais par le WAF lui-même parfois sans que la requête n'atteigne l'application web (si elle est bloquée), parfois juste pour montrer que le pare-feu a bien analysé la requête. On peut par exemple voir cela pour cloudflare ou barracuda :

Pour ceux qui ont du mal à comprendre ces différents bouts de code. il s'agit d'une simple recherche dans la réponse du serveur pour voir si un cookie ou un en-tête portant un nom spécifique est présent. Par exemple l'en-tête "Server: cloudflare-nginx" (ligne 12, page de gauche) pour un pare-feu Cloudflare, qui peut apparaitre dans la page de blocage d'un pare-feu CloudFlare si on lui envoie un charge utile malveillante détectée.

B. L'analyse comportementale

L'outil wafw00f regarde comment le service web ciblé réagit à telle ou telle charge utile (payload) et va en déduire la présence d'un pare-feu et la technologie de celui-ci, c'est par exemple le cas pour les pare-feu Juniper :

Ici le script Python fait un requête "normale" (sans charge utile malveillante, ligne 9) puis une requête contenant une charge utile considérée comme malveillante par les WAF Juniper (ligne 15). Pour chaque réponse, il regarde si un WAF a retourné un réponse indiquant une détection ou non. Si c'est le cas pour la requête contenant la charge utile malveillante, il annonce avoir été détecté (lignes 20 et 21).

Dans leur configuration par défaut, les pare-feu peuvent contenir des expressions régulières ou des mots spécifiques dans leur blacklist (liste de mots sur lesquels ils se basent afin de statuer sur le caractère malveillante d'une requête). Il peut également s'agir d'éléments plus subtiles comme la taille maximale d'un fichier envoyé ainsi que son type (extension, contenu, etc.). Ces éléments peuvent donc eux aussi servir d'éléments de détection, qui deviennent moins fiable si le pare-feu n'est plus dans sa configuration par défaut.

Si l'outil ne parvient pas à identifier une technologie précise, il peut tout de même nous indiquer si une différence est observée entre les réponses aux requêtes contenant des charges utiles malveillantes et celles considérée comme "saines". Si une différence est observée, c'est un qu'un élément de sécurité est présent.

V. Fiabilité des tests

J'ai fait mon test précédent avec la version 0.9.5 de wafw00f, depuis une KaliLinux non mise à jour depuis quelques mois et l'outil m’indiquait que mon site web se trouvait derrière un pare-feu Juniper. En téléchargeant la version 1.0.0 depuis le Github et en rejouant le même test, voici ce que j’obtiens :

wafw00f ne détecte plus la même chose, il m'indique qu'un pare-feu applicatif est bien présent, sans trouver lequel. Que c'est-il passé ? Je commence par regarder dans les deux cas, et grâce à un proxy, quels tests sont joués à par wafw00f.

Petite chose à savoir, un option --proxy est présente dans wafw00f mais celui-ci ne gère pas l'utilisation d'un proxy HTTP pour une cible en HTTPS . Je doit donc passer par un proxy transparent et une modification de mon fichier host pour lui faire croire que ma cible est en faite en locale et qu'il s'agit de mon proxy BurpSuite en écoute. Celui-ci redirige ensuite le flux vers ma vraie cible en HTTPS.

Bref, premier test avec la version 0.9.5 :

Ce qui correspond au test inscrit dans le plugin webscurity.py du dépôt Github pour la version 0.9.5 :

Second test avec la version 1.0.0 :

Envoyer la charge utile "nx=@@" semble provoquer une réaction dans le premier cas, mais pas dans le second où l'outil s'arrête à une requête différente. Wafw00f arrête son exécution dés la première conclusion et ne continue pas ses tests. L'option -a ou --findall permet de contourner ce comportement et de continuer les tests même après une première détection. Après quelques recherches sur le Github du projet, je remarque cette modification :

La détection de la réaction nx=@@ n'est plus interprété par wafw00f de la même manière pour la raison suivante : Les contributeurs ont remarqué que les pare-feu Juniper ne réagissaient plus de la même manière dans leur dernière version. Cela signifie que si j'ai en face de moi un Juniper non mis à jour ou dans une ancienne version, sa présence ne sera plus détectée avec la version 1.0.0.0 de wafw00f.

Nous pouvons également facilement duper wafw00f lorsqu'il se base sur une analyse par signature. Si l'on regarde comment wafw00f détecte un pare-feu de type CloudFlare, on remarque qu'il recherche dans la réponse du serveur plusieurs en-têtes ou cookies, ce qui revient à faire du banner grabbing comme pour identifier un WAF :

Je configure donc mon Apache pour ajouter l'une de ces bannières, par exemple cf-ray, dans toutes ses réponses, et j'exécute wafw00f :

Il me retourne comme attendu une détection d'un pare-feu de type Cloudflare alors que ce n'est pas le cas. On peut donc facilement orienter un outil ou un attaquant (qui ne se baserait que sur les résultats de ses outils) vers une mauvaise direction et ainsi augmenter ses chances de détection.

wafw00f est un outil très utile lors de la phase de reconnaissance/cartographie. J'espère que vous avez à présent un meilleur aperçu de son utilité, de son fonctionnement et de ses limites. Attention toutefois, nous avons vu qu'il prend en compte un grand nombre de technologies mais qu'il ne s'agit pas d'un outil magique, comme tout outil automatisé, ses résultats sont à analyser et à vérifier.

Également, attention à bien prendre la dernière version de wafw00f, comme d'habitude, les outils d'attaque évoluent aussi bien que les outils de défense. Les contributeurs de wafw00f mettent à jour leurs tests identification régulièrement. Enfin, vous pouvez également écrire vos propres tests et éventuellement les partager à la communauté en suivant les instructions suivantes sur le Wiki de l'outil : https://github.com/EnableSecurity/wafw00f/wiki/How-to-write-new-WAF-checks