wpscanteam/wpscanScanner de segurança WordPress que detecta vulnerabilidades, enumera plugins/temas/usuários e verifica senhas fracas. Integra-se com a API do WPScan para dados de vulnerabilidade em tempo real.
Scanner de Segurança WordPress
Base de Dados de Vulnerabilidades WordPress do WPScan - Plugin de Segurança WordPress
Stream error in the HTTP/2 framing layer em alguns casosAo usar uma distribuição de pentest (como Kali Linux), é recomendado instalar/atualizar o wpscan através do gerenciador de pacotes se disponível.
brew install wpscanteam/tap/wpscan
O WPScan depende de gems com extensões nativas (ex.: yajl-ruby, nokogiri, ffi), portanto, uma toolchain C funcional e cabeçalhos de desenvolvimento Ruby devem estar presentes antes do gem install wpscan. Sem eles, a instalação falha com erros como Failed to build gem native extension ou make: x86_64-linux-gnu-gcc: No such file or directory (veja #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).Em seguida, instale a gem:
gem install wpscan
No MacOSX, se um Gem::FilePermissionError for levantado devido à Proteção de Integridade do Sistema (SIP) da Apple, instale o RVM e instale o wpscan novamente, ou execute sudo gem install -n /usr/local/bin wpscan (veja #1286)
Você pode atualizar a base de dados local usando wpscan --update
A atualização do próprio WPScan é feita via gem update wpscan ou pelo gerenciador de pacotes (isso é bastante importante para distribuições como Kali Linux: apt-get update && apt-get upgrade) dependendo de como o WPScan foi (pré)instalado
Baixe o repositório com docker pull wpscanteam/wpscan
Enumeração de nomes de utilizador
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u
Enumeração de uma faixa de nomes de utilizador
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --url https://target.tld/ --enumerate u1-100
** substitua u1-100 por uma faixa à sua escolha.
A imagem inclui uma cópia da base de dados local incorporada no momento da compilação. Como os comandos de exemplo acima usam --rm, qualquer atualização da base de dados realizada durante a execução é descartada quando o contêiner é encerrado, então a próxima execução começa novamente a partir da cópia incorporada (potencialmente desatualizada).
Montar um volume nomeado em /wpscan/.cache/wpscan/db (o diretório de cache do usuário wpscan dentro do contêiner) mantém a base de dados entre execuções, então o wpscan --update só baixa novamente os arquivos cujos checksums realmente mudaram e o aviso de desatualização de 5 dias se comporta como em uma instalação local:
docker run -it --rm -v wpscan-db:/wpscan/.cache/wpscan/db wpscanteam/wpscan --update
O volume nomeado é criado automaticamente no primeiro uso se ainda não existir.
A documentação completa do usuário pode ser encontrada aqui; https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation
wpscan --url blog.tld Isso irá escanear o blog usando opções padrão com um bom compromisso entre velocidade e precisão. Realiza deteção de versão, deteção de temas e descoberta de achados interessantes. Para enumerar plugins, temas, utilizadores, pastas de backup, etc., use a opção -e (ex.: -e ap para todos os plugins, -e vp para plugins vulneráveis, -e bf para pastas de backup).
Se for necessária uma abordagem mais furtiva, então wpscan --stealthy --url blog.tld pode ser usado.
Como resultado, ao usar a opção --enumerate, não se esqueça de definir o --plugins-detection adequadamente, pois seu padrão é 'passive'.
Para mais opções, abra um terminal e digite wpscan --help (se você compilou o wpscan a partir do código-fonte, deve digitar o comando fora do repositório git)
A localização da base de dados segue a Especificação do Diretório Base XDG:
~/.cache/wpscan/db (ou $XDG_CACHE_HOME/wpscan/db se definido)~/.wpscan/db (caminho legado, mantido para retrocompatibilidade)Os arquivos de tempo de execução, como o cache HTTP padrão e o cookie jar, são armazenados em $TMPDIR/wpscan quando $TMPDIR está definido. Caso contrário, eles usam o mesmo diretório de cache XDG por usuário, por exemplo ~/.cache/wpscan/cache e ~/.cache/wpscan/cookie_jar.txt. Esses padrões podem ser sobrescritos com --cache-dir e --cookie-jar.
Para migrar uma instalação existente para o caminho XDG:
mv ~/.wpscan ~/.cache/wpscan
A ferramenta CLI do WPScan usa a API da Base de Dados de Vulnerabilidades WordPress para obter dados de vulnerabilidades WordPress em tempo real. Para que o WPScan recupere os dados de vulnerabilidade, um token de API deve ser fornecido através da opção --api-token ou através de um arquivo de configuração, conforme discutido abaixo. Um token de API pode ser obtido registrando uma conta em WPScan.com.
Até 25 solicitações de API por dia são oferecidas gratuitamente, o que deve ser suficiente para escanear a maioria dos sites WordPress pelo menos uma vez por dia. Quando as 25 solicitações diárias de API forem esgotadas, o WPScan continuará funcionando normalmente, mas sem dados de vulnerabilidade.