wpscanteam/wpscanScanner di sicurezza WordPress che rileva vulnerabilità, enumera plugin/temi/utenti e verifica la presenza di password deboli. Si integra con l'API WPScan per dati sulle vulnerabilità in tempo reale.
Scanner di Sicurezza per WordPress
Database delle Vulnerabilità WordPress di WPScan - Plugin di Sicurezza per WordPress
Stream error in the HTTP/2 framing layer in alcuni casiQuando si utilizza una distribuzione di pentesting (come Kali Linux), si consiglia di installare/aggiornare wpscan tramite il gestore pacchetti, se disponibile.
brew install wpscanteam/tap/wpscan
WPScan dipende da gem con estensioni native (es. yajl-ruby, nokogiri, ffi), quindi una toolchain C funzionante e gli header di sviluppo Ruby devono essere presenti prima di gem install wpscan. Senza di essi, l'installazione fallisce con errori come Failed to build gem native extension o make: x86_64-linux-gnu-gcc: No such file or directory (vedi #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).Quindi installa la gem:
gem install wpscan
Su MacOSX, se viene sollevato un Gem::FilePermissionError a causa della System Integrity Protection (SIP) di Apple, installa RVM e re-installa wpscan, oppure esegui sudo gem install -n /usr/local/bin wpscan (vedi #1286)
Puoi aggiornare il database locale usando wpscan --update
L'aggiornamento di WPScan stesso si effettua tramite gem update wpscan oppure tramite il gestore pacchetti (questo è piuttosto importante per distribuzioni come Kali Linux: apt-get update && apt-get upgrade) a seconda di come WPScan è stato (pre)installato
Scarica il repository con docker pull wpscanteam/wpscan
Enumerazione degli username
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u
Enumerazione di un intervallo di username
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u1-100
** sostituisci u1-100 con un intervallo a tua scelta.
L'immagine include una copia del database locale integrata al momento della build. Poiché i comandi di esempio sopra utilizzano --rm, qualsiasi aggiornamento del database effettuato durante un'esecuzione viene scartato all'uscita del container, quindi l'esecuzione successiva riparte dalla copia integrata (potenzialmente obsoleta).
Montare un volume con nome in /wpscan/.cache/wpscan/db (la directory cache dell'utente wpscan all'interno del container) mantiene il database tra le varie esecuzioni, così wpscan --update riscarica solo i file i cui checksum sono effettivamente cambiati e il prompt di obsolescenza di 5 giorni si comporta come per un'installazione locale:
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --update
Il volume con nome viene creato automaticamente al primo utilizzo se non esiste già.
La documentazione completa per l'utente si trova qui; https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation
wpscan --url blog.tld Questa scansione analizza il blog utilizzando le opzioni predefinite con un buon compromesso tra velocità e accuratezza. Esegue il rilevamento della versione, il rilevamento del tema e la scoperta di risultati interessanti. Per enumerare plugin, temi, utenti, cartelle di backup, ecc., usa l'opzione -e (es. -e ap per tutti i plugin, -e vp per i plugin vulnerabili, -e bf per le cartelle di backup).
Se è necessario un approccio più furtivo, si può usare wpscan --stealthy --url blog.tld.
Di conseguenza, quando si usa l'opzione --enumerate, non dimenticare di impostare --plugins-detection di conseguenza, poiché il suo valore predefinito è 'passive'.
Per maggiori opzioni, apri un terminale e digita wpscan --help (se hai compilato wpscan dal sorgente, dovresti digitare il comando fuori dalla repository git)
La posizione del database segue la XDG Base Directory Specification:
~/.cache/wpscan/db (o $XDG_CACHE_HOME/wpscan/db se impostato)~/.wpscan/db (percorso legacy, mantenuto per compatibilità con le versioni precedenti)I file runtime come la cache HTTP predefinita e il cookie jar vengono memorizzati in $TMPDIR/wpscan quando
$TMPDIR è impostato. In caso contrario, utilizzano la stessa directory cache XDG per utente, ad esempio
~/.cache/wpscan/cache e ~/.cache/wpscan/cookie_jar.txt. Questi valori predefiniti possono essere sovrascritti
con --cache-dir e --cookie-jar.
Per migrare un'installazione esistente al percorso XDG:
mv ~/.wpscan ~/.cache/wpscan
Lo strumento CLI di WPScan utilizza la WordPress Vulnerability Database API per recuperare i dati sulle vulnerabilità di WordPress in tempo reale. Affinché WPScan possa recuperare i dati sulle vulnerabilità, è necessario fornire un token API tramite l'opzione --api-token, oppure tramite un file di configurazione, come discusso di seguito. Un token API può essere ottenuto registrando un account su WPScan.com.
Fino a 25 richieste API al giorno sono fornite gratuitamente, un numero sufficiente per scansionare la maggior parte dei siti WordPress almeno una volta al giorno. Quando le 25 richieste API giornaliere sono esaurite, WPScan continuerà a funzionare normalmente ma senza dati sulle vulnerabilità.