IT-Connect » Actualités » Sécurité » wafw00f – étude et utilisation d’un outil de détection de WAF

 

 

 

Sécurité 

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

Mickael Dorigny Aucun commentaire

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 :

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 :