vulnhuntr

Uma ferramenta para identificar vulnerabilidades exploráveis remotamente usando LLMs e análise estática de código.

As primeiras vulnerabilidades 0day do mundo descobertas por IA autônoma

Descrição

O Vulnhuntr aproveita o poder dos LLMs para criar e analisar automaticamente cadeias de chamada de código inteiras, começando na entrada remota do usuário e terminando na saída do servidor, para a detecção de vulnerabilidades complexas, de múltiplas etapas e que contornam a segurança, indo muito além do que as ferramentas tradicionais de análise estática de código são capazes de realizar. Veja todos os detalhes, incluindo a saída do Vulnhuntr para todas as 0-days aqui: Blog Protect AI Vulnhuntr

Vulnerabilidades Encontradas

[!TIP] Encontrou uma vulnerabilidade usando o Vulnhuntr? Envie um relatório para huntr.com para ganhar $$ e envie um PR para adicioná-la à lista abaixo!

[!NOTE] Esta tabela é apenas uma amostra das vulnerabilidades encontradas até agora. Removeremos o sigilo à medida que os períodos de divulgação responsável terminarem.

Limitações

• Somente bases de código Python são suportadas.
• Só é possível identificar as seguintes classes de vulnerabilidades:
  • Inclusão local de arquivo (LFI)
  • Sobrescrita arbitrária de arquivo (AFO)
  • Execução remota de código (RCE)
  • Cross-site scripting (XSS)
  • Injeção de SQL (SQLI)
  • Falsificação de solicitação no servidor (SSRF)
  • Referência direta insegura a objeto (IDOR)

Instalação

[!IMPORTANT] O Vulnhuntr exige estritamente Python 3.10 por causa de uma série de bugs no Jedi, que ele usa para analisar código Python. Ele não funcionará de forma confiável se for instalado com qualquer outra versão do Python.

Recomendamos usar pipx ou Docker para instalar e executar o Vulnhuntr facilmente.

Usando Docker:

docker build -t vulnhuntr https://github.com/protectai/vulnhuntr.git#main

Usando pipx:

pipx install git+https://github.com/protectai/vulnhuntr.git --python python3.10

Alternativamente, você pode instalar diretamente da fonte usando poetry:

git clone https://github.com/protectai/vulnhuntr
cd vulnhuntr && poetry install

Uso

Esta ferramenta foi projetada para analisar um repositório do GitHub em busca de possíveis vulnerabilidades exploráveis remotamente. A ferramenta requer uma chave de API e o caminho local de um repositório do GitHub. Você também pode, opcionalmente, especificar um endpoint personalizado para o serviço de LLM.

[!CAUTION] Sempre defina limites de gastos ou monitore de perto os custos com o provedor de LLM que você usa. Esta ferramenta tem potencial para gerar contas altas, pois tenta encaixar o máximo de código possível na janela de contexto dos LLMs.

[!TIP] Recomendamos usar Claude como LLM. Em nossos testes, obtivemos melhores resultados com ele do que com GPT.

Interface de Linha de Comando

usage: vulnhuntr [-h] -r ROOT [-a ANALYZE] [-l {claude,gpt,ollama}] [-v]

Analyze a GitHub project for vulnerabilities. Export your ANTHROPIC_API_KEY/OPENAI_API_KEY before running.

options:
  -h, --help            show this help message and exit
  -r ROOT, --root ROOT  Path to the root directory of the project
  -a ANALYZE, --analyze ANALYZE
                        Specific path or file within the project to analyze
  -l {claude,gpt,ollama}, --llm {claude,gpt,ollama}
                        LLM client to use (default: claude)
  -v, --verbosity       Increase output verbosity (-v for INFO, -vv for DEBUG)

Exemplos

A partir de uma instalação via pipx, analise o repositório inteiro usando Claude:

export ANTHROPIC_API_KEY="sk-1234"
vulnhuntr -r /path/to/target/repo/

[!TIP] Recomendamos fornecer ao Vulnhuntr arquivos específicos que lidam com entrada remota do usuário e escaneá-los individualmente.

A partir de uma instalação via pipx, analise o arquivo /path/to/target/repo/server.py usando GPT-4o. Você também pode especificar um subdiretório em vez de um arquivo:

export OPENAI_API_KEY="sk-1234"
vulnhuntr -r /path/to/target/repo/ -a server.py -l gpt 

A partir de uma instalação via docker, execute usando Claude e um endpoint personalizado para analisar /local/path/to/target/repo/repo-subfolder/target-file.py:

docker run --rm -e ANTHROPIC_API_KEY=sk-1234 -e ANTHROPIC_BASE_URL=https://localhost:1234/api -v /local/path/to/target/repo:/repo vulnhuntr:latest -r /repo -a repo-subfolder/target-file.py

Experimental

Ollama está incluído como uma opção; no entanto, não tivemos sucesso com os modelos de código aberto estruturando sua saída corretamente.

export OLLAMA_BASE_URL=http://localhost:11434/api/generate
export OLLAMA_MODEL=llama3.2
vulnhuntr -r /path/to/target/repo/ -a server.py -l ollama

Fluxo Lógico

• O LLM resume o README e inclui isso no prompt do sistema
• O LLM faz uma análise inicial de um arquivo inteiro e relata quaisquer vulnerabilidades potenciais
• O Vulnhuntr então fornece ao LLM um prompt específico para a vulnerabilidade para análise secundária
• Cada vez que o LLM analisa o código, ele solicita funções/classes/variáveis de contexto adicionais de outros arquivos do projeto
• Ele continua fazendo isso até que toda a cadeia de chamadas, da entrada do usuário ao processamento no servidor, esteja completa e então fornece uma análise final
• A análise final consiste em seu raciocínio, um exploit de prova de conceito e uma pontuação de confiança

[!TIP] Geralmente, pontuações de confiança < 7 significam que provavelmente não há uma vulnerabilidade. Pontuações de confiança 7 significam que ela deve ser investigada, e pontuações de confiança 8+ significam que é muito provável que seja uma vulnerabilidade válida.

Saída

A ferramenta gera um relatório detalhado das vulnerabilidades encontradas nos arquivos analisados. O relatório inclui:

• Resultados da avaliação inicial para cada arquivo.
• Resultados da avaliação secundária com funções de contexto e referências de classe.
• Pontuações de confiança para as vulnerabilidades encontradas.
• Registros (logs) do processo de análise.
• Exploit de PoC

Abaixo está um exemplo de um relatório do Vulnhuntr descrevendo uma vulnerabilidade de execução remota de código 0-day no Ragflow (agora corrigida):

scratchpad:
  1. Analyzing the add_llm function in llm_app.py. 2. Identified user input used as keys to access dictionaries: EmbeddingModel, ChatModel, RerankModel,
CvModel, and TTSModel. 3. These dictionaries contain class references, which are instantiated with user-supplied parameters. 4. The factory variable is 
directly used from user input (req['llm_factory']) without proper validation. 5. The llm_name is also derived from user input in most cases. 6. The 
instantiation of these classes occurs in try-except blocks, but exceptions are only used for error messages, not preventing execution. 7. The api_key 
and other sensitive information are passed directly to these instantiated classes. 8. There's no comprehensive input validation or sanitization for the 
factory or llm_name variables. 9. The vulnerability is in a route decorated with @login_required, indicating it's accessible to authenticated users. 10.
Reviewing the EmbeddingModel, ChatModel, RerankModel, CvModel, and TTSModel dictionaries to understand their contents and potential for exploitation.
----------------------------------------

analysis:
  The add_llm function in llm_app.py contains a critical Remote Code Execution (RCE) vulnerability. The function uses user-supplied input 
(req['llm_factory'] and req['llm_name']) to dynamically instantiate classes from the EmbeddingModel, ChatModel, RerankModel, CvModel, and TTSModel 
dictionaries. This pattern of using user input as a key to access and instantiate classes is inherently dangerous, as it allows an attacker to 
potentially execute arbitrary code. The vulnerability is exacerbated by the lack of comprehensive input validation or sanitization on these 
user-supplied values. While there are some checks for specific factory types, they are not exhaustive and can be bypassed. An attacker could potentially
provide a malicious value for 'llm_factory' that, when used as an index to these model dictionaries, results in the execution of arbitrary code. The 
vulnerability is particularly severe because it occurs in a route decorated with @login_required, suggesting it's accessible to authenticated users, 
which might give a false sense of security.
----------------------------------------

poc:
  POST /add_llm HTTP/1.1
  Host: target.com
  Content-Type: application/json
  Authorization: Bearer <valid_token>
  
  {
      "llm_factory": "__import__('os').system",
      "llm_name": "id",
      "model_type": "EMBEDDING",
      "api_key": "dummy_key"
  }
  
  This payload attempts to exploit the vulnerability by setting 'llm_factory' to a string that, when evaluated, imports the os module and calls system. 
The 'llm_name' is set to 'id', which would be executed as a system command if the exploit is successful.
----------------------------------------

confidence_score:
  8
----------------------------------------

vulnerability_types:
  - RCE
----------------------------------------

Registro

A ferramenta registra o processo e os resultados da análise em um arquivo chamado vulnhuntr.log. Este arquivo contém informações detalhadas sobre cada etapa da análise, incluindo as avaliações inicial e secundária.

Autores

• Dan McInerney: [email protected], @DanHMcinerney
• Marcello Salvati: [email protected], @byt3bl33d3r