vulnhuntr

Ein Tool zur Identifizierung remote ausnutzbarer Schwachstellen mithilfe von LLMs und statischer Codeanalyse.

Erste autonome KI-entdeckte 0-Day-Schwachstellen der Welt

Beschreibung

Vulnhuntr nutzt die Leistungsfähigkeit von LLMs, um automatisch vollständige Code-Aufrufketten zu erstellen und zu analysieren, die von entfernten Benutzereingaben bis zur Serverausgabe reichen. Dadurch werden komplexe, mehrstufige, sicherheitsumgehende Schwachstellen erkannt, die weit über das hinausgehen, was traditionelle statische Codeanalysetools leisten können. Alle Details einschließlich der Vulnhuntr-Ausgabe für alle 0-Days finden Sie hier: Protect AI Vulnhuntr Blog

Gefundene Schwachstellen

[!TIP] Eine Schwachstelle mit Vulnhuntr gefunden? Reichen Sie einen Bericht bei huntr.com ein, um $$ zu erhalten, und reichen Sie einen PR ein, um sie zur folgenden Liste hinzuzufügen!

[!NOTE] Diese Tabelle ist nur ein Beispiel der bisher gefundenen Schwachstellen. Wir werden die Informationen nach Ablauf der verantwortungsvollen Offenlegungsfristen freigeben.

Einschränkungen

• Es werden nur Python-Codebasen unterstützt.
• Es können nur die folgenden Schwachstellenklassen identifiziert werden:
  • 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)

Installation

[!IMPORTANT] Vulnhuntr erfordert ausdrücklich Python 3.10 aufgrund einer Reihe von Fehlern in Jedi, das zum Parsen von Python-Code verwendet wird. Bei Installation mit anderen Python-Versionen funktioniert es nicht zuverlässig.

Wir empfehlen die Verwendung von pipx oder Docker, um Vulnhuntr einfach zu installieren und auszuführen.

Verwendung mit Docker:

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

Verwendung mit pipx:

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

Alternativ können Sie es direkt aus dem Quellcode mit poetry installieren:

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

Verwendung

Dieses Tool dient zur Analyse eines GitHub-Repositorys auf potenziell remote ausnutzbare Schwachstellen. Das Tool benötigt einen API-Schlüssel und den lokalen Pfad zu einem GitHub-Repository. Optional können Sie auch einen benutzerdefinierten Endpunkt für den LLM-Dienst angeben.

[!CAUTION] Legen Sie immer Ausgabenlimits fest oder überwachen Sie die Kosten genau bei dem von Ihnen verwendeten LLM-Anbieter. Dieses Tool kann hohe Kosten verursachen, da es versucht, so viel Code wie möglich in den Kontextfenster des LLMs unterzubringen.

[!TIP] Wir empfehlen die Verwendung von Claude als LLM. In Tests haben wir damit bessere Ergebnisse erzielt als mit GPT.

Befehlszeilenschnittstelle

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)

Beispiele

Bei einer pipx-Installation das gesamte Repository mit Claude analysieren:

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

[!TIP] Wir empfehlen, Vulnhuntr bestimmte Dateien zu übergeben, die Remote-Benutzereingaben verarbeiten, und diese einzeln zu scannen.

Bei einer pipx-Installation die Datei /path/to/target/repo/server.py mit GPT-4o analysieren. Es kann auch ein Unterverzeichnis anstelle einer Datei angegeben werden:

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

Bei einer Docker-Installation mit Claude und einem benutzerdefinierten Endpunkt ausführen, um /local/path/to/target/repo/repo-subfolder/target-file.py zu analysieren:

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

Experimentell

Ollama ist als Option enthalten, jedoch hatten wir mit Open-Source-Modellen keinen Erfolg bei der korrekten Strukturierung ihrer Ausgaben.

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

Logikablauf

• Das LLM fasst die README zusammen und fügt diese Zusammenfassung in den System-Prompt ein.
• Das LLM führt eine erste Analyse einer gesamten Datei durch und meldet mögliche Schwachstellen.
• Vulnhuntr übergibt dem LLM dann einen schwachstellenspezifischen Prompt für eine zweite Analyse.
• Jedes Mal, wenn das LLM den Code analysiert, fordert es zusätzliche Kontextfunktionen/-klassen/-variablen aus anderen Dateien des Projekts an.
• Dies wird so lange fortgesetzt, bis die gesamte Aufrufkette von der Benutzereingabe bis zur Serververarbeitung vollständig ist. Dann erfolgt eine abschließende Analyse.
• Die abschließende Analyse besteht aus der Begründung, einem Proof-of-Concept-Exploit und einem Konfidenzwert.

[!TIP] Im Allgemeinen deuten Konfidenzwerte < 7 darauf hin, dass wahrscheinlich keine Schwachstelle vorliegt. Konfidenzwerte von 7 sollten untersucht werden, und Konfidenzwerte von 8+ bedeuten, dass es sich sehr wahrscheinlich um eine gültige Schwachstelle handelt.

Ausgabe

Das Tool erstellt einen detaillierten Bericht über die in den analysierten Dateien gefundenen Schwachstellen. Der Bericht umfasst:

• Ergebnisse der ersten Bewertung für jede Datei.
• Ergebnisse der zweiten Bewertung mit Kontextfunktionen und Klassenreferenzen.
• Konfidenzwerte für gefundene Schwachstellen.
• Protokolle des Analyseprozesses.
• PoC-Exploit

Nachfolgend ein Beispiel eines Vulnhuntr-Berichts, der eine 0-Day-Remote-Code-Execution-Schwachstelle in Ragflow (inzwischen behoben) beschreibt:

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

Protokollierung

Das Tool protokolliert den Analyseprozess und die Ergebnisse in einer Datei namens vulhuntr.log. Diese Datei enthält detaillierte Informationen zu jedem Schritt der Analyse, einschließlich der ersten und zweiten Bewertungen.

Autoren

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