WPScan: le scanneur de vulnérabilités Wordpress

Wordpress est sans doute - je pense - l'application Web de blog la plus populaire; inhérent à cette popularité est le nombre de vulnérabilités qui sont soit attribuées à une version non mise à jour soit à un plugin ou un thème vulnérable non mis à jour.

Pour "tester" son blog (et celui de son prochain si affinité ) et savoir s'il y a des failles de sécurité qui devraient être comblées il y a 2 solutions soit: passer par des lectures infinies sur plein de forums et sites, soit utiliser WPScan.

WPScan est un scanneur écrit en Ruby qui permet de trouver les vulnérabilités présentes sur l’installation d’un blog WordPress. Il est destiné aussi bien aux professionnels de la sécurité qu’aux administrateurs de blogs en herbe sous WordPress.

C'est un scanner de faille Web pour WordPress, capable de lister les plugins utilisés et d'afficher les failles de sécurités associées.

Actuellement WPScan est livré préinstallé sur BackBox Linux, BackTrack Linux, Kali, Pentoo et SamuraiWTF.

Je vais détailler l'installation et l'utilisation sous Ubuntu (pareil pour tout Debian). Si vous voulez l'avoir sur votre distribution à vous lisez le guide!

Pour installer WPScan commencez par instaler les dépendances via un petit:

sudo apt-get install libcurl4-gnutls-dev libopenssl-ruby libxml2 libxml2-dev libxslt1-dev ruby-dev git

Ensuite clonez le répertoire git de l'application sur votre machine: (après avoir navigué là où vous voulez le mettre)

git clone https://github.com/wpscanteam/wpscan.git

Vous pouvez ne pas utiliser git - ni l'installer d'ailleurs - et dans ce cas téléchargez le fichier zip ou tar du répertoire et décompressez-le quelque part.

Maintenant dirigez-vous à l'intérieur du répertoire wpscan

cd wpscan

Vous ne pouvez pas dire que je vous tiens pas par la main là..

Continuez l'installation des gems nécessaires par un petit:

sudo gem install bundler && bundle install --without test development

Voilà WPScan est maintenant installé. Passons à la configuration et à l'utilisation de WPScan!

D'abord configurons quelque peu votre WPScan pour une meilleure furtivité si vous voyez ce que je veux dire!

Ce tutorial est basé sur la version 2.1rNA actuellement disponible de WPScan. Votre version est peut-être différente. S'il y a un problème reportez-le-moi!

Allez éditer le fichier conf/browser.conf.json. C'est un fichier json comme son nom l'indique donc.. Dans ce fichier vous pouvez configurer un certain nombre de paramètres de WPScan à savoir:

  • user_agent: vous pouvez ici mettre votre user agent que WPScan utilisera si vous avez mis l'option suivante à static.
  • user_agent_mode: vous pouvez choisir de mettre soit
    • static: utilisera le user agent que vous avez mis dans l'option d'avant
    • semi-static: utilisera un user agent différent depuis la liste available_user_agents à chaque scan
    • random: utilisera un user agent différent depuis la liste available_user_agents à chaque requête.
  • proxy: si vous voulez utiliser un proxy décommentez cette ligne (en enlevant les //) et mettez l'adresse de votre proxy entre double guillemets. (Exemple: moi j'utilise Privoxy avec Tor: "proxy": "127.0.0.1:8118")
  • proxy_auth: l'authentification si jamais c'est nécessaire pour le proxy; décommentez la ligne et mettez votre authentification dans la forme "login:mot de passe".
  • cache_ttl: le temps en secondes avant que le cache soit supprimé entre deux scans. Mettez à 0 pour supprimer le cache. Par défaut il est mis à 10 minutes ("cache_ttl": 600).
  • request_timeout: le temps en secondes avant que WPScan déclare qu'une requête a échoué; par défaut 2s ("request_timeout": 2000).
  • max_threads: le nombre maximum d'instances concurrentes du programme; par défaut mis à 20 ("max_threads": 20). L'augmentation de ce nombre n'est pas forcément synonyme d'une accélération du scan.
  • available_user_agents: c'est un tableau d'user agents que WPScan pourra utiliser si vous avez mis random ou semi-static dans user_agent_mode. Vous pouvez trouver une bonne liste sur ce fichier xml (liste de l'extension User Agent Switcher de Firefox)

Pour l'utilisation de WPScan rien de plus facile il suffit de taper dans un terminal:

ruby wpscan.rb --url www.adressedelinstallationdewordpress.com

Pour mettre à jour WPScan:

ruby wpscan.rb --update

Pour avoir de l'aide concernant l'utilisation:

ruby wpscan.rb --help

Le scan qu'on a vu plus haut est un simple scan non intrusif; vous pouvez affiner ce scan via les switchs:

  • --verbose ou -v: pour que WPScan soit un peu plus bavard..
  • --force ou -f: force WPScan à ne pas vérifier si le site a WordPress installé ou pas.
  • --threads ou -t: le nombre d'instances du programme. Par défaut c'est spécifié à 20 dans le fichier conf/browser.conf.json. Une augmentation n'est pas forcément synonyme d'une accélération du scan.
  • --enumerate ou -e option(s): Les options peuvent être:

    • u: énumérer les noms des utilisateurs du blog de l'id 1 à 10
    • u[10-20]: énumérer les noms des utilisateurs du blog de l'id 10 à 20. (vous devez mettre les [ ])
    • p: énumérer les plugins WordPress installés
    • vp: énumérer seulement les plugins vulnérables retrouvés
    • ap: énumérer tous les plugins retrouvés (prend plus de temps)
    • t: énumérer les thèmes
    • vt: énumérer seulement les thèmes vulnérables
    • at: énumérer tous les thèmes (prend plus de temps)
    • tt: énumérer les fichiers timthumbs retrouvés.

    Vous pouvez mettre plusieurs options à la fois, exemple: -e t,p. Si aucune option n'a été mise, par défaut c'est vt,tt,u,vp qui s'exécute.

  • --config-file ou -c si vous voulez spécifier un fichier de configuration autre que celui par défaut (conf/browser.conf.json)
  • --follow-redirection: si l'url contient une redirection elle sera suivie sans poser de questions.
  • --wp-content-dir chemin: WPScan essaye par défaut de retrouver le dossier wp-content sur la page index même s'il a été renommé; mais s'il ne l'a pas retrouvé (qu'il été modifié par soucis de sécurité par l'administrateur du blog) vous pouvez spécifier le dossier ici. (le chemin peut contenir des sous-dossiers)
  • --wp-plugins-dir chemin: même chose que le switch précédent pour le dossier des plugins
  • --exclude-content-based: une option bidon, je passe! Non mais bon c'est trop affiner ça..
  • --proxy: pour spécifier un proxy protocole://hôte:port ou hôte:port et dans ce cas le protocole sera automatiquement HTTP.
  • --proxy-auth: l'authentification pour le proxy si jamais c'est nécessaire sous la forme: login:mot de passe
  • --basic-auth: si jamais le site utilise une authentification HTTP: login:mot de passe

WPScan permet aussi de faire un bruteforce via un dictionnaire pour essayer de retrouver le mot de passe des utilisateurs retrouvés via le switch --wordlist (-w) ou d'un utilisateur spécifique si vous utilisez le switch --username (-U) avec --wordlist.

Exemple:

ruby ./wpscan.rb --url www.example.com --wordlist darkc0de.lst --username admin

Biensûr cela va sans dire le bruteforce est la technique des brutes; il peut se couler des années lumières avant que vous ayez retrouvé le mot de passe.. ça s'il figure déjà dans le dictionnaire que vous utilisez!

Voilà tout! J'espère que j'ai rien oublié.. Ah oui juste un truc! WPScan ne fait pas dans la magie: il peut "détecter" les failles CONNUES en se basant sur les versions de WordPress, des plugins et des thèmes mais il ne fait pas dans l'exploitation de ces failles et il lui arrive de se tromper! WPScan vous permet de pointer les failles connues afin de les combler.. ou de les exploiter; c'est à vous de voir!

Des remarques? Des questions? N'hésitez pas!


Lire aussi: