Skip to content

Scan et sécurité du CMS WordPress avec WPscan

Comme je le dis souvent, pour avoir une bonne sécurité, il faut avant tout penser et agir comme un attaquant. C’est dans cette optique que l’on va aujourd’hui découvrir WPscan, un outil de scan de sécurité WordPress.

WordPress est aujourd’hui le CMS le plus utilisé pour les blogs, les sites web en général et surtout par les entreprises. Cela est dû à sa simplicité d’installation, de configuration et de maintenance. La popularité de WordPress fait qu’il est également le CMS le plus visé et le plus sensible aux failles de sécurité. Cela pour une raison simple, plus un outil est utilisé, plus une faille de sécurité sur cet outil peut toucher de monde.

WPscan, Scan de sécurité de votre WordPress

WPscan est un outil qui s’utilise en ligne de commande, sous Linux. Il est présent nativement sur les distributions suivantes :

  • BackBox Linux
  • Kali Linux
  • Pentoo
  • SamuraiWTF
  • ArchAssault

Il est important de souligner que, comme pour la majorité des outils de sécurité et de scanning, WPscan ne sécurisera pas votre WordPress pour vous. Également, avoir effectué un check de sécurité avec WPscan qui ne vous remonte pas de failles visibles ne signifie pas que votre WordPress est à 100% sécurisé. C’est une notion qui doit être constamment en tête lorsque l’on parle de sécurité.

Installation de WPscan

Si vous souhaitez faire l’installation manuellement, voici les prérequis :

  • Ruby >= 1.9.2 – Recommended: 2.2.0
  • Curl >= 7.21 – Recommended: latest – FYI the 7.29 has a segfault
  • RubyGems – Recommended: latest
  • Git

Sur Debian, voici la procédure d’installation :

 sudo apt-get install git ruby ruby-dev libcurl4-gnutls-dev make
 git clone https://github.com/wpscanteam/wpscan.git
 cd wpscan
 sudo gem install bundler
 bundle install --without test --path vendor/bundle

Sur les distributions Fedora/CentOS/RHEL :

 sudo yum install gcc ruby-devel libxml2 libxml2-devel libxslt libxslt-devel libcurl-devel
 git clone https://github.com/wpscanteam/wpscan.git
 cd wpscan
 sudo gem install bundler && bundle install --without test

Nous pouvons maintenant utiliser WPscan.

Utilisation de WPscan

Passons à l’action, comme je l’ai dit, WPscan est présent nativement sous Kalilinux, c’est la distribution que j’utilise dans cette démonstration.

Avant toute analyse, il convient de mettre à jour la base de données de wp-scan. Cela est important, car si l’on décide de scanner notre WordPress avec une base de données de vulnérabilités qui n’est pas à jour, certaines failles de sécurité relatives au thème, à la version de WordPress ou aux versions des plug-ins par exemple, ne vous seront pas reportées, on risque donc de passer à côté d’éléments critiques à sécuriser. Pour mettre à jour la base de données WPscan :

wpscan --update

Pour information, voici la base d’information sur laquelle se base wpscan : https://www.wpvulndb.com/

wpscan-wordpress01
Maintenant que notre base de données est à jour, nous allons pouvoir commencer à scanner notre site WordPress :

wpscan --URL www.wp.loc

Voici un scan WordPress complet, WPscan va ici regarder différentes choses :

wpscan-wordpress02

J’ai donc effectué un scan sur mon propre site. Différentes informations sont relevées :

– Le contenu du fichier « robots.txt » : le fichier robots.txt perme d’indiquer à Google et aux autres moteurs de recherches les pages ou répertoires qu’il ne faut pas indexer. Dans la plupart des cas, les pages que nous ne souhaitons pas indexer sont précisées dans ce fichier, car il serait dangereux que les informations qu’ils contiennent se retrouvent sur un moteur de recherches. La restriction de la diffusion d’informations sensibles est en vérité une mauvaise manière de procéder, car le fichier robots.txt est par définition lisible par tout le monde. On donne alors simplement à l’attaquant une liste de répertoires qui pourraient potentiellement l’intéresser, justement car nous avons spécifié aux moteurs de recherches « ne diffuse pas ces informations !« . Attention donc à ce que vous mettez dans le fichier robots.txt.

– Des données « headers » concernant le serveur : on voit différentes données comme des informations relatives aux cookies fournis par le site, la version de PHP et d’Apache qui sont récupérées via ce que l’on appelle le banner grabbing (voir ce billet : Qu’est-ce que le banner grabbing ?).

– La détection de la version de WordPress, ce qui peut être intéressant pour un attaquant et également la liste des plug-ins disponibles et leurs versions.

Comment ces données sont-elles récoltées ?

Il est particulièrement facile sous WordPress de récupérer la liste (pas forcément exhaustive) des plug-ins installés, simplement car ceux-ci sont systématiquement mis dans le répertoire « wp-content/plug-ins/ » du site web en question. WPscan possède donc une liste des plug-ins WordPress et il se charge juste de tester par des requêtes web la présence ou non d’un dossier de plug-in comme on peut le voir sur le screenshot plus haut, pour  un répertoire testé, si le code de retour est 404, le plug-in n’existe pas. En revanche s’il s’agit d’une erreur 403 (Forbidden) ou 200 (OK), le plug-in existe. La version des plug-ins, elle, est souvent récupérée dans le fichier « readme.txt » qui accompagne beaucoup d’applications, sous WordPress, il est recommandé de le supprimer justement pour éviter la détection d’une version de plug-in obsolète, bien qu’il ne soit pas le seul moyen de la détecter.

Mes plug-ins ne sont pas à jour, et alors ?

La réponse à cette question est simple, la détection de la version d’un plug-in ou du CMS WordPress n’a qu’un but : voir s’il est vulnérable.

Le fait est que les mises à jour servent, entre autres, à corriger des failles de sécurité détectées et publiques sur un plug-in donné. Un plug-in non à jour a de bonnes chances de contenir une faille de sécurité connue et qui peut donc être exploitée par un attaquant contre votre site web. Il existe alors différentes méthodes de protection :

  • La première consiste simplement à mettre à jour les plug-ins, un plug-in à jour contient la dernière version de code et de protection connue
  • On peut également ralentir l’avancée d’un attaquant en essayant de cacher nos plug-ins et leur version, cela peut se faire en supprimant le fichier readme.txt des plug-ins par exemple
  • Il est plus complexe de cacher la détection d’un répertoire de plug-in. Les navigateurs web des clients doivent pouvoir les lire depuis l’extérieur, car ils contiennent des scripts et des données qui doivent être lues pour le bon fonctionnement du site.

Voyons maintenant une autre utilisation de WPScan : le brute force. La procédure d’authentification est commune à tous les WordPress, elle passe par le fichier wp-login.php. WPscan est alors capable de mettre en place un brute force à partir d’un identifiant que nous lui fournissons et d’une liste de mot de passe à fournir également :

wpscan --URL www.wp.loc --wordlist /root/rockyoulight.txt --username admin --user-agent "Mozilla/5.0 (Windows NT 6.3; rv;36.0) Gecko/20100101 Firefox/36.0"

Voici le résultat qu’il ne faut surtout pas avoir :

 Ici, mon brute force à abouti, j’ai donc réussi à m’authentifier sur le WordPress en tant qu’admin ( « –username admin« ) avec un mot de passe contenu dans le dictionnaire que j’ai fournis ( « –wordlist /root/rockyoulight.txt » ). J’ai bien précisé le site web visé avec « –URL www.wp.loc«   et j’ai également précisé un user-agent différent.

Pourquoi changer le user-agent ?

Il est intéressant de voir qu’il est très facilement possible de changer l’user-agent (l’identité du navigateur web qui fait la requête auprès du serveur). Certains plug-ins de sécurité WordPress comme better-wp-security, mettent en place une restriction d’accès au site web selon certains user-agent. Voici par exemple le navigateur indiqué par WPscan lorsqu’il fait un scan ou un brute force auprès du serveur web :

On voit ici en fin de chaîne en tant que user-agent « WPscan v2.5.1 (http://wpscan.org) » , on peut donc se douter qu’il s’agit d’une attaque et les plug-ins mettant en place une restriction par rapport à ce genre d’user-agent mettent une protection supplémentaire en place. Néanmoins, l’user-agent est une donnée très facilement falsifiable, il est donc intéressant de savoir et de garder en tête que ce genre de plug-in ne vous sécurise pas à 100% et que leur simple présence ne suffit pas à garantir une sécurité certaine de votre WordPress.

Sur beaucoup de tutoriels, il est recommandé de changer le nom des répertoires wp-content et wp-content/plug-ins, spécifiques aux WordPress. Cela est justement fait dans l’optique de cacher certaines informations. Néanmoins, il est important de savoir que cela ne vous sécurise pas à 100% non plus. Au mieux, cela permettra de se cacher des scans faits par des robots qui scannent en masse beaucoup de WordPress, mais dans le code source de votre WordPress, il est facilement possible de retrouver les noms personnalisés des répertoires wp-content et wp-content/plug-ins, par exemple :

On peut alors, à partir de WPscan, spécifier des répertoires personnalisés plutôt que d’utiliser ceux par défaut. Par exemple, pour spécifier un répertoire « wp-content » personnalisé :

wpscan -u www.wp.loc --wp-content-dir wp-content-custom

Pour spécifier un répertoire de plug-in personnalisé :

wpscan -u www.wp.loc - --wp-plugins-dir wp-content/plugins-custom

C’est tout pour la présentation de ce petit outil qui permettra de vérifier la sécurité de votre WordPress ! Soyez attentif au fait de ne pas utiliser ce genre d’outil sur des sites web qui ne vous appartiennent pas ou sans le consentement de leur propriétaire. Il existe d’autres options d’utilisation de WPscan, mais nous avons ici vu son fonctionnement général.

Il est important de savoir comment fonctionnent WPscan et les outils similaires pour bien comprendre que certaines règles de sécurité indiquées (et même toutes) ne permettent pas de garantir une sécurité sûre à 100%. Mieux comprendre les outils et les stratégies et attaquants permet de mieux s’en défendre.

Partager :
Published inOutils

Be First to Comment

Laisser un commentaire

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