Détection de CMS avec Wig

Wig est un outil écrit en python qui permet d’aider à la détection et l’identification de CMS (Content Management System) ainsi que de certaines informations et vulnérabilités du service web scanné.

Wig est un projet assez récent puisque les premiers commits sur le Github du projet datent de début 2014 et il est aujourd’hui en version 0.5.

Détecter la version d’un CMS, qu’est ce que ça apporte ?

Comme la majeure partie des actions dans la phase d’information gathering (prise d’empreinte ou prise d’information), la détection du CMS va avoir pour but, lors d’un pentest ou d’un audit, de mieux cibler et cerner la structure du site web visé. Avoir un CMS WordPress en version 3 n’entraînera pas les mêmes actions d’attaques que d’avoir un CMS Joomla à jour.

La détection du CMS, et plus généralement des types de services et serveurs, permet à l’attaquant de dresser une cartographie et une liste de ce qui il peut attaquer. Chaque version ayant ses vulnérabilités, la connaissance du service et de sa version facilitera au final la travail de l’attaquant.

Télécharger Wig

Nous allons commencer par récupérer le projet sur son Github : https://github.com/jekyc/wig

On va donc le télécharger sur notre machine d’audit :

wget https://github.com/jekyc/wig/archive/master.zip
unzip master.zip

On trouvera alors dans le dossier wig-master le script Python 3 (entre autres).

Utilisation de Wig

Pour utiliser Wig, il vous faut bien sûr une cible (un service web) :

python3 wig.py information-security.fr --verbosity

On voit alors (parce que l’on positionne l’option “verbosity”), les différents tests et analyses effectués et le résultat de ceux-ci :

wig-cms-analyse-01

Résultat d’un scan Wig

On voit par exemple la détection des cookies échangés, des services et leurs versions (WordPress, Apache) ainsi que certains fichiers qui pourraient être intéressants. On voit alors que Wig ne se “limite” pas vraiment au CMS, il essaie également de détecter des informations sur l’environnement du CMS en allant grappiller un peu en dessous (Serveur web, OS) et au-dessus (fichier et répertoires intéressants) du CMS.

Note : On voit ici l’intérêt de bien cacher la version de son CMS et plus généralement des outils web mis en place. Ici, Wig pense que je suis en version 4.0 de WordPress (version vulnérable). Un attaquant va donc chercher à exploiter les failles de WordPress 4.0 alors qu’en réalité, j’ai la dernière version de WordPress. Mais nous en reparlerons un peu plus bas 😉 .

Comment fonctionne Wig ?

Wig fonctionne en essayant de repérer l’empreinte d’un CMS. Par empreinte, il faut comprendre une caractéristique, une ou plusieurs traces spécifiques à la présence d’un CMS particulier. Par exemple, la présence d’un CMS WordPress sera trahie par la présence d’un répertoire wp-content juste à la racine du serveur web. À partir de la détection d’un OS, Wig va alors essayer d’aller plus loin en regardant d’autres sous répertoires ou fichiers spécifiques à ce CMS comme le répertoire /wp-admin.

Par défaut, Wig va stopper son exécution après avoir détecté un premier CMS. Ce comportement peut être changé en utilisant l’option  “-a” qui permet de continuer l’exploration après avoir trouvé et identifié un premier CMS. Cela est particulièrement utile lorsque l’on demande à Wig de scanner plusieurs URL différentes, par exemple dans le cadre d’une lecture de fichier.

On peut en effet créer un fichier contenant une URL par ligne, puis donner ce fichier à Wig pour qu’il scanne unes à unes ces URL. Après avoir créé notre fichier contenant une URL valide par ligne, nous pourrons le spécifier à Wig de la façon suivante :

python3 wig.py -l monfichier

Afin de ne pas se faire tromper par du cache, le plus simple est de ne pas l’utiliser. Cela permet également de pouvoir retester rapidement après avoir fait une correction sans avoir à vider tous les caches qui pourraient fausser le résultat. On peut donc utiliser pour cela l’option “–no_cache_load” qui permet d’éviter l’utilisation du cache et l’option “–no_cache_save” qui permet d’éviter de mettre quoi que ce soit en cache ! Ces options peuvent être combinées via l’option “-N”

Protections : Qu’est ce que cela nous apprend ?

La première chose à distinguer est le fait que, plus l’on chercher à cacher des choses, plus le travail de l’attaquant sera long et fastidieux. Bien que la présence d’un CMS WordPress peut souvent se repérer juste en visualisant la structure d’un site web, d’autres CMS sont moins évident à deviner.

Également, il peut être intéressant de connaitre Wig pour savoir ce qu’un attaquant pourra voir de l’extérieur et ainsi mieux s’en protéger.

Le fait de cacher la véritable version d’un CMS va par exemple fausser le jugement d’un attaquant qui va alors tester des exploits sur des versions qui ne sont plus vulnérables et ainsi générer des logs, trahir sa présence, et pourquoi pas se fatiguer et se décourager 😉 Au-delà de la protection par l’obscurité, un principe de sécurité quelque peu dépassé qui consiste à dire que, si on ne peut pas le voir, cela est protégé, le but est plus de trahir la présence de l’attaquant en le faisant essayer des attaques et des exploits sans qu’il ne sache réellement ce qu’il attaque (qu’il n’ait pas la version exacte du CMS par exemple).

Au-delà de ces principes de sécurité, il peut également être utile, selon vos CMS, d’opter pour des protections supplémentaires. Si vous disposez d’un site web avec un CMS joomla, il serait par exemple intéressant de positionner une .htaccess restreignant l’accès au dossier “/administrator” ou au fichier “readme.html” qui peuvent trahir la présence et la diffusion de la version de certains CMS et plug-ins.

En voyant comment les outils comme Wig s’y prennent pour fournir des informations aux attaquants, on apprend d’autant mieux comment s’en protéger.

Et vous, quelles sont vos astuces pour dissimuler et protéger vos CMS ?

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *