Os três scripts

Eles são independentes. Execute um ou todos os três — o script de regex entrega suas descobertas automaticamente aos outros dois.

Instalação

macOS, Linux, Kali, WSL — uma linha, sem argumentos:

curl -fsSL https://raw.githubusercontent.com/vulnersCom/nmap-vulners/master/install.sh | sh

Windows — PowerShell como Administrador:

irm https://raw.githubusercontent.com/vulnersCom/nmap-vulners/master/install.ps1 | iex

O instalador pergunta ao nmap onde ele guarda seus dados, copia os scripts e seus arquivos de dados para lá, reconstrói o banco de dados de scripts e então verifica se --script vulners realmente resolve para o que acabou de instalar — o nmap traz um vulners.nse próprio, e este o substitui.

# into ~/.nmap, no sudo; the installer prints the NMAPDIR line to add to your profile
curl -fsSL https://raw.githubusercontent.com/vulnersCom/nmap-vulners/master/install.sh | sh -s -- --user

# a specific directory
./install.sh --prefix /usr/local/share/nmap

# a specific release
./install.sh --ref v1.5

# remove everything it installed
./install.sh --uninstall

git clone https://github.com/vulnersCom/nmap-vulners
cd nmap-vulners
./install.sh

nmap -sV --script "$PWD/vulners.nse" <target>

nmap -d2 --script-help probe 2>&1 | grep nse_main.lua

Uso

vulners — nenhuma chave necessária

nmap -sV --script vulners [--script-args mincvss=<score>] <target>

Cada CPE que o nmap reporta é consultado; cada vulnerabilidade é impressa com sua pontuação, a escala em que essa pontuação se baseia e um link. Entradas com um exploit conhecido são marcadas *EXPLOIT* e são exibidas independentemente do limite, porque uma falha de baixa severidade já explorada ainda compromete você.

vulners_enterprise — chave da API do Vulners

export VULNERS_API_KEY=<token>
nmap -sV --script vulners_enterprise [--script-args mincvss=<score>] <target>

O endpoint enterprise responde com métricas CVSS v3 e com as referências de exploits que o Vulners coletou; assim, um CVE explorado é marcado como *HAS EXPLOIT* e o exploit em si é listado ao lado dele. Todos os CPEs de uma porta viajam em uma requisição.

http-vulners-regex — identificar o que o -sV não consegue nomear

nmap -sV --script http-vulners-regex [--script-args paths={"/"}] <target>

178 padrões mapeiam cabeçalhos HTTP e marcação de páginas — Server, X-Powered-By, tags de gerador, URLs de assets — para CPEs: servidores web, CMSs, frameworks, plugins do WordPress e bibliotecas JavaScript. Tudo o que ele encontra é publicado na porta, para que vulners e vulners_enterprise consultem na mesma varredura.

Argumentos dos scripts

vulners

vulners_enterprise

http-vulners-regex

Toda a lista de caminhos viaja em um único pipeline HTTP. Um arquivo que não pode ser lido interrompe o script em vez de recorrer à lista que acompanha a ferramenta, então um erro de digitação no nome do arquivo não pode transformar uma varredura de três caminhos em uma de 125.

Onde guardar a chave da API

Em ordem de preferência:

1. VULNERS_API_KEY no ambiente
2. --script-args vulners_enterprise.api_key_file=/absolute/path
3. --script-args vulners_enterprise.api_key=<token>

A terceira é conveniente e vazada: o nmap copia sua própria linha de comando para todos os relatórios, então o token acaba no atributo args da saída -oX e no seu histórico de shell. O script em si nunca grava o token em lugar nenhum, inclusive na sua saída de depuração — há um teste de regressão que garante isso.

Os tokens ficam na sua conta do vulners.com. Sem um, o vulners_enterprise permanece em silêncio e não envia nada.

Como os três se encaixam

nmap -sV
   |
   +-- service fingerprint --> port.version.cpe ------------+
   |                                                        |
   +-- http-vulners-regex.nse                               |
         requests the path list in one pipeline             |
         matches headers and bodies against 178 patterns    |
         publishes the CPEs it found for that port ---------+
                                                            |
                                                            v
                                     vulners.nse / vulners_enterprise.nse
                                        one batched request per port
                                        answers cached for the whole scan
                                        sorted by CVSS, exploits marked

Saída legível por máquina

Tudo o que os scripts imprimem também é estruturado, então a saída -oX pode ser analisada sem tocar no texto legível por humanos:

<script id="vulners_enterprise">
  <table key="cpe:/a:apache:http_server:2.4.7">
    <table>
      <elem key="id">CVE-2021-44790</elem>
      <elem key="type">cve</elem>
      <elem key="cvss">9.8</elem>
      <elem key="cvss_type">cvss3.1</elem>
    </table>
    <table>
      <elem key="id">EDB-ID:51193</elem>
      <elem key="type">exploitdb</elem>
      <elem key="cvss">9.8</elem>
      <elem key="cvss_type">cvss3.1</elem>
      <elem key="is_exploit">true</elem>
    </table>
  </table>
</script>

As chaves são id, type, cvss, cvss_type e is_exploit, que está presente apenas em entradas que o possuem. As tabelas de resultados são indexadas pelo CPE para o qual foram encontradas. Um boletim sem pontuação não traz nem cvss nem cvss_type.

Varredura educada

Uma varredura de uma rede faz muito menos requisições à API do que parece:

• cada CPE de uma porta vai em uma requisição em lote
• as respostas ficam em cache durante toda a varredura, então cem servidores idênticos custam uma consulta, não cem
• uma consulta já em andamento é aguardada em vez de repetida
• a varredura de 125 caminhos roda sobre 5 conexões TCP em vez de 126 e solicita páginas compactadas quando o servidor as oferece
• um limite de taxa ou uma queda interrompe as requisições da varredura em vez de tentar novamente por host

Desenvolvimento

Os testes, a verificação de higiene e o CONTRIBUTING.md estão apenas no repositório git; o arquivo de release acompanha os scripts e seus dados. Três verificações, todas offline exceto onde indicado:

nmap -sn -Pn --script ./tests/run.nse --script-args testdir=tests,root=. 127.0.0.1
python3 tests/e2e/run_e2e.py
python3 tools/check.py

110 casos de teste unitário rodam dentro do nmap contra as bibliotecas NSE reais; 33 casos de ponta a ponta usam o binário real do nmap contra um servidor web local e uma API do Vulners simulada; a verificação de higiene mantém segredos, saídas de varredura e lixo de editores fora da árvore. python3 tests/e2e/run_e2e.py --live adiciona seis verificações contra o serviço real. Veja CONTRIBUTING.md.

FAQ

Ele explora alguma coisa? Não. Os scripts leem banners e páginas e consultam um banco de dados. Eles estão na categoria safe do nmap.

Funciona sem uma chave de API? Sim — vulners e http-vulners-regex não precisam de nenhuma. vulners_enterprise precisa.

Por que uma vulnerabilidade mostra cvss2.0 enquanto outra mostra cvss3.1? O rótulo nomeia a escala em que a pontuação se baseia. O Vulners retorna o que a fonte publicou; uma pontuação v2 de 9.3 não é uma pontuação v3 de 9.3.

Por que uma entrada com pontuação baixa é exibida quando eu defino mincvss? Porque ela tem um exploit conhecido, ou porque a fonte nunca a pontuou. Ambas as situações são intencionais.

Não encontrou nada em um host que eu sei que é vulnerável. Execute com -d2: os scripts registram cada CPE que consultaram. Normalmente o nmap nomeia o serviço, mas não a versão, e não há versão para consultar.

Licença

Os scripts são licenciados da mesma forma que o próprio Nmap — veja LICENSE para a Nmap Public Source License e nmap.org/npsl para saber o que ela significa.

Os dados de vulnerabilidades vêm do Vulners e estão sujeitos aos seus termos.

Relacionados

• vulners.com — o banco de dados por trás desses scripts
• vulnersCom/api — o cliente Python
• vulnersCom/burp-vulners-scanner — os mesmos dados dentro do Burp Suite
• nmap.org/book/nse.html — como os scripts NSE funcionam