wpscanteam/wpscanScanner de sécurité WordPress qui détecte les vulnérabilités, énumère les plugins/thèmes/utilisateurs et vérifie les mots de passe faibles. S'intègre avec l'API WPScan pour des données de vulnérabilité en temps réel.
Scanner de sécurité WordPress
WPScan WordPress Vulnerability Database - Plugin de sécurité WordPress
Stream error in the HTTP/2 framing layer dans certains casLors de l'utilisation d'une distribution de pentest (comme Kali Linux), il est recommandé d'installer/mettre à jour wpscan via le gestionnaire de paquets si disponible.
brew install wpscanteam/tap/wpscan
WPScan dépend de gems avec des extensions natives (ex. yajl-ruby, nokogiri, ffi), donc une chaîne d'outils C fonctionnelle et les en-têtes de développement Ruby doivent être présents avant gem install wpscan. Sans eux, l'installation échoue avec des erreurs comme Failed to build gem native extension ou make: x86_64-linux-gnu-gcc: No such file or directory (voir #1844).
sudo apt install build-essential ruby-dev
sudo dnf install @development-tools ruby-devel
sudo pacman -S base-devel ruby
sudo apk add build-base ruby-dev
xcode-select --install).Ensuite, installez la gem :
gem install wpscan
Sous MacOSX, si une Gem::FilePermissionError est levée en raison de la protection d'intégrité du système (SIP) d'Apple, installez RVM et réinstallez wpscan, ou exécutez sudo gem install -n /usr/local/bin wpscan (voir #1286)
Vous pouvez mettre à jour la base de données locale en utilisant wpscan --update
La mise à jour de WPScan elle-même se fait soit via gem update wpscan, soit via le gestionnaire de paquets (ceci est important pour des distributions comme Kali Linux : apt-get update && apt-get upgrade) selon la façon dont WPScan a été (pré)installé
Tirez l'image avec docker pull wpscanteam/wpscan
Énumération des noms d'utilisateur
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u
Énumération d'une plage de noms d'utilisateur
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u1-100
** remplacez u1-100 par une plage de votre choix.
L'image est livrée avec une copie de la base de données locale intégrée au moment de la construction. Étant donné que les exemples de commandes ci-dessus utilisent --rm, toute mise à jour de la base de données effectuée lors d'une exécution est supprimée lorsque le conteneur se termine, donc la prochaine exécution repart à partir de la copie intégrée (potentiellement obsolète).
Monter un volume nommé à /wpscan/.cache/wpscan/db (le répertoire de cache de l'utilisateur wpscan dans le conteneur) conserve la base de données entre les exécutions, donc wpscan --update ne télécharge à nouveau que les fichiers dont les sommes de contrôle ont réellement changé et l'invite de péremption de 5 jours se comporte comme pour une installation locale :
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --update
Le volume nommé est créé automatiquement lors de la première utilisation s'il n'existe pas déjà.
La documentation complète de l'utilisateur se trouve ici ; https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation
wpscan --url blog.tld Cela analysera le blog en utilisant les options par défaut avec un bon compromis entre vitesse et précision. Il effectue la détection de version, la détection de thème et la découverte de résultats intéressants. Pour énumérer les plugins, thèmes, utilisateurs, dossiers de sauvegarde, etc., utilisez l'option -e (par ex., -e ap pour tous les plugins, -e vp pour les plugins vulnérables, -e bf pour les dossiers de sauvegarde).
Si une approche plus discrète est nécessaire, alors wpscan --stealthy --url blog.tld peut être utilisé.
En conséquence, lors de l'utilisation de l'option --enumerate, n'oubliez pas de définir --plugins-detection en conséquence, car sa valeur par défaut est 'passive'.
Pour plus d'options, ouvrez un terminal et tapez wpscan --help (si vous avez compilé wpscan à partir des sources, vous devez taper la commande en dehors du dépôt git).
L'emplacement de la base de données suit la spécification des répertoires de base XDG :
~/.cache/wpscan/db (ou $XDG_CACHE_HOME/wpscan/db si défini)~/.wpscan/db (chemin hérité, conservé pour la compatibilité ascendante)Les fichiers d'exécution tels que le cache HTTP par défaut et le cookie jar sont stockés sous $TMPDIR/wpscan lorsque
$TMPDIR est défini. Sinon, ils utilisent le même répertoire de cache XDG par utilisateur, par exemple
~/.cache/wpscan/cache et ~/.cache/wpscan/cookie_jar.txt. Ces valeurs par défaut peuvent être remplacées
avec --cache-dir et --cookie-jar.
Pour migrer une installation existante vers le chemin XDG :
mv ~/.wpscan ~/.cache/wpscan
L'outil en ligne de commande WPScan utilise l'API de base de données de vulnérabilités WordPress pour récupérer les données de vulnérabilité WordPress en temps réel. Pour que WPScan récupère les données de vulnérabilité, un jeton API doit être fourni via l'option --api-token, ou via un fichier de configuration, comme discuté ci-dessous. Un jeton API peut être obtenu en créant un compte sur WPScan.com.