WPScan

WordPress-Sicherheitsscanner

WPScan WordPress-Schwachstellendatenbank - WordPress-Sicherheits-Plugin

INSTALLATION

Voraussetzungen

• (Optional, aber sehr empfohlen: rbenv)
• Ruby >= 3.3 - Empfohlen: neueste stabile Version
• Curl >= 7.72 - Empfohlen: neueste stabile Version
  • Die 7.29 hat einen Segfault
  • Die < 7.72 kann in einigen Fällen zu Stream error in the HTTP/2 framing layer führen
• RubyGems - Empfohlen: neueste stabile Version
• Nokogiri erfordert möglicherweise die Installation von Paketen über Ihren Paketmanager, abhängig von Ihrem Betriebssystem, siehe https://nokogiri.org/tutorials/installing_nokogiri.html

In einer Pentesting-Distribution

Wenn Sie eine Pentesting-Distribution (wie Kali Linux) verwenden, wird empfohlen, wpscan über den Paketmanager zu installieren/aktualisieren, falls verfügbar.

In macOSX über Homebrew

brew install wpscanteam/tap/wpscan

Von RubyGems

WPScan ist von Gems mit nativen Erweiterungen abhängig (z.B. yajl-ruby, nokogiri, ffi), daher müssen vor gem install wpscan eine funktionierende C-Toolchain und Ruby-Entwicklungsheader vorhanden sein. Ohne sie schlägt die Installation mit Fehlern wie Failed to build gem native extension oder make: x86_64-linux-gnu-gcc: No such file or directory fehl (siehe #1844).

• Debian / Ubuntu:

  sudo apt install build-essential ruby-dev
  

• Fedora / RHEL / CentOS:

  sudo dnf install @development-tools ruby-devel
  

• Arch Linux:

  sudo pacman -S base-devel ruby
  

• Alpine:

  sudo apk add build-base ruby-dev
  

• macOS: installieren Sie die Xcode Command Line Tools (xcode-select --install).

Dann installieren Sie das Gem:

gem install wpscan

Unter MacOSX, falls ein Gem::FilePermissionError aufgrund von Apples System Integrity Protection (SIP) ausgelöst wird, installieren Sie entweder RVM und installieren wpscan erneut, oder führen Sie sudo gem install -n /usr/local/bin wpscan aus (siehe #1286)

Aktualisierung

Sie können die lokale Datenbank mit wpscan --update aktualisieren.

Die Aktualisierung von WPScan selbst erfolgt entweder über gem update wpscan oder den Paketmanager (dies ist besonders wichtig für Distributionen wie Kali Linux: apt-get update && apt-get upgrade), abhängig davon, wie WPScan (vor)installiert wurde.

Docker

Holen Sie das Repository mit docker pull wpscanteam/wpscan

Aufzählen von Benutzernamen

docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u

Aufzählen eines Bereichs von Benutzernamen

docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u1-100

** Ersetzen Sie u1-100 durch einen Bereich Ihrer Wahl.

Persistieren der lokalen Datenbank

Das Image wird mit einer Kopie der lokalen Datenbank ausgeliefert, die zur Build-Zeit eingebaut wurde. Da die obigen Beispielbefehle --rm verwenden, wird jede während eines Laufs durchgeführte Datenbankaktualisierung verworfen, wenn der Container beendet wird, sodass der nächste Lauf wieder mit der (möglicherweise veralteten) eingebauten Kopie beginnt.

Das Einbinden eines benannten Volumes unter /wpscan/.cache/wpscan/db (dem Cache-Verzeichnis des wpscan-Benutzers im Container) behält die Datenbank über mehrere Läufe hinweg bei, sodass wpscan --update nur Dateien erneut herunterlädt, deren Prüfsummen sich tatsächlich geändert haben, und die 5-Tage-Verfallserinnerung verhält sich wie bei einer lokalen Installation:

docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --update

Das benannte Volume wird bei der ersten Verwendung automatisch erstellt, falls es noch nicht existiert.

Verwendung

Die vollständige Benutzerdokumentation finden Sie hier; https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation

wpscan --url blog.tld Dies wird den Blog mit Standardoptionen scannen und einen guten Kompromiss zwischen Geschwindigkeit und Genauigkeit bieten. Es führt Versionserkennung, Theme-Erkennung und die Ermittlung interessanter Funde durch. Um Plugins, Themes, Benutzer, Backup-Ordner usw. aufzuzählen, verwenden Sie die -e-Option (z.B. -e ap für alle Plugins, -e vp für anfällige Plugins, -e bf für Backup-Ordner).

Falls ein heimlicherer Ansatz erforderlich ist, kann wpscan --stealthy --url blog.tld verwendet werden. Wenn Sie die --enumerate-Option verwenden, vergessen Sie nicht, --plugins-detection entsprechend zu setzen, da der Standardwert 'passive' ist.

Für weitere Optionen öffnen Sie ein Terminal und geben Sie wpscan --help ein (wenn Sie wpscan aus dem Quellcode erstellt haben, sollten Sie den Befehl außerhalb des Git-Repositorys eingeben).

Datenbank-Speicherort

Der Datenbank-Speicherort folgt der XDG Base Directory Specification:

• Neue Installationen: ~/.cache/wpscan/db (oder $XDG_CACHE_HOME/wpscan/db, falls gesetzt)
• Bestehende Installationen: ~/.wpscan/db (alter Pfad, aus Gründen der Abwärtskompatibilität beibehalten)

Laufzeitdateien wie der Standard-HTTP-Cache und der Cookie-Jar werden unter $TMPDIR/wpscan gespeichert, wenn $TMPDIR gesetzt ist. Ansonsten verwenden sie dasselbe benutzerspezifische XDG-Cache-Verzeichnis, z.B. ~/.cache/wpscan/cache und ~/.cache/wpscan/cookie_jar.txt. Diese Standardeinstellungen können mit --cache-dir und --cookie-jar überschrieben werden.

Um eine bestehende Installation zum XDG-Pfad zu migrieren:

mv ~/.wpscan ~/.cache/wpscan

Optional: WordPress-Schwachstellendatenbank-API

Das WPScan-CLI-Tool verwendet die WordPress-Schwachstellendatenbank-API, um WordPress-Schwachstellendaten in Echtzeit abzurufen. Damit WPScan die Schwachstellendaten abrufen kann, muss ein API-Token über die --api-token-Option oder über eine Konfigurationsdatei bereitgestellt werden, wie unten beschrieben. Ein API-Token kann durch die Registrierung eines Kontos auf WPScan.com erworben werden.

Bis zu 25 API-Anfragen pro Tag werden kostenlos zur Verfügung gestellt, was ausreichen sollte, um die meisten WordPress-Websites mindestens einmal täglich zu scannen. Wenn die täglichen 25 API-Anfragen erschöpft sind, arbeitet WPScan normal weiter, jedoch ohne Schwachstellendaten.