vulnhuntr

Uno strumento per identificare vulnerabilità sfruttabili da remoto utilizzando LLM e analisi statica del codice.

Le prime vulnerabilità 0day al mondo scoperte autonomamente da un'IA

Descrizione

Vulnhuntr sfrutta la potenza degli LLM per creare e analizzare automaticamente intere catene di chiamate di codice a partire dall'input utente remoto fino all'output del server, per la rilevazione di vulnerabilità complesse, multi-step e che bypassano la sicurezza, andando ben oltre ciò che gli strumenti tradizionali di analisi statica del codice sono in grado di fare. Consulta tutti i dettagli, inclusi gli output di Vulnhuntr per tutti gli 0-day, qui: Protect AI Vulnhuntr Blog

Vulnerabilità Trovate

[!TIP] Hai trovato una vulnerabilità usando Vulnhuntr? Invia un report a huntr.com per ottenere $$ e invia una PR per aggiungerla alla lista qui sotto!

[!NOTE] Questa tabella è solo un esempio delle vulnerabilità trovate finora. Rimuoveremo i dati oscurati man mano che i periodi di responsible disclosure termineranno.

Limitazioni

• Sono supportati solo codebase Python.
• Può identificare solo le seguenti classi di vulnerabilità:
  • Local file include (LFI)
  • Arbitrary file overwrite (AFO)
  • Remote code execution (RCE)
  • Cross site scripting (XSS)
  • SQL Injection (SQLI)
  • Server side request forgery (SSRF)
  • Insecure Direct Object Reference (IDOR)

Installazione

[!IMPORTANT] Vulnhuntr richiede strettamente Python 3.10 a causa di numerosi bug in Jedi, che utilizza per analizzare il codice Python. Non funzionerà in modo affidabile se installato con altre versioni di Python.

Consigliamo di usare pipx o Docker per installare ed eseguire facilmente Vulnhuntr.

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

In alternativa puoi installarlo direttamente dal sorgente usando poetry:

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

Utilizzo

Questo strumento è progettato per analizzare un repository GitHub alla ricerca di potenziali vulnerabilità sfruttabili da remoto. Lo strumento richiede una chiave API e il percorso locale di un repository GitHub. Puoi anche specificare opzionalmente un endpoint personalizzato per il servizio LLM.

[!CAUTION] Imposta sempre limiti di spesa o monitora attentamente i costi con il provider LLM che utilizzi. Questo strumento ha il potenziale di generare bollette salate poiché cerca di inserire più codice possibile nella finestra di contesto dell'LLM.

[!TIP] Consigliamo di usare Claude come LLM. Durante i test abbiamo ottenuto risultati migliori rispetto a GPT.

Interfaccia a riga di 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)

Esempi

Da un'installazione pipx, analizza l'intero repository usando Claude:

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

[!TIP] Consigliamo di indicare a Vulnhuntr file specifici che gestiscono l'input utente remoto e di scansionarli singolarmente.

Da un'installazione pipx, analizza il file /path/to/target/repo/server.py usando GPT-4o. Puoi anche specificare una sottodirectory invece di un file:

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

Da un'installazione Docker, esegui usando Claude e un endpoint personalizzato per analizzare /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

Sperimentale

Ollama è incluso come opzione, tuttavia non abbiamo avuto successo con i modelli open source nella strutturazione corretta del loro output.

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

Flusso logico

• L'LLM riassume il README e lo include nel system prompt
• L'LLM esegue un'analisi iniziale su un intero file e segnala eventuali vulnerabilità potenziali
• Vulnhuntr fornisce quindi all'LLM un prompt specifico per la vulnerabilità per un'analisi secondaria
• Ogni volta che l'LLM analizza il codice, richiede funzioni/classi/variabili di contesto aggiuntive da altri file del progetto
• Continua così fino a quando l'intera catena di chiamate dall'input utente all'elaborazione sul server non è completa, quindi fornisce un'analisi finale
• L'analisi finale consiste nel suo ragionamento, in una proof of concept dell'exploit e in un punteggio di confidenza

[!TIP] Generalmente punteggi di confidenza < 7 indicano che probabilmente non c'è una vulnerabilità. I punteggi di confidenza di 7 significano che dovrebbe essere investigata, e i punteggi di confidenza di 8+ significano che è molto probabile che sia una vulnerabilità valida.

Output

Lo strumento genera un report dettagliato delle vulnerabilità trovate nei file analizzati. Il report include:

• Risultati della valutazione iniziale per ogni file.
• Risultati della valutazione secondaria con funzioni di contesto e riferimenti alle classi.
• Punteggi di confidenza per le vulnerabilità trovate.
• Log del processo di analisi.
• Exploit PoC

Di seguito è riportato un esempio di report di Vulnhuntr che descrive una vulnerabilità di remote code execution 0-day in Ragflow (ora corretta):

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
----------------------------------------

Logging

Lo strumento registra il processo di analisi e i risultati in un file chiamato vulnhuntr.log. Questo file contiene informazioni dettagliate su ogni fase dell'analisi, incluse le valutazioni iniziale e secondaria.

Autori

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