vulnhuntr

Инструмент для выявления удаленно эксплуатируемых уязвимостей с помощью LLM и статического анализа кода.

Первые в мире автономно обнаруженные ИИ 0-day уязвимости

Описание

Vulnhuntr использует мощь LLM для автоматического создания и анализа полных цепочек вызовов кода, начиная с удаленного пользовательского ввода и заканчивая выводом сервера, для обнаружения сложных, многошаговых уязвимостей, обходящих защиту, которые выходят далеко за пределы возможностей традиционных инструментов статического анализа кода. Все подробности, включая вывод Vulnhuntr для всех 0-day уязвимостей, см. в блоге: Protect AI Vulnhuntr Blog

Найденные уязвимости

[!TIP] Нашли уязвимость с помощью Vulnhuntr? Отправьте отчет на huntr.com, чтобы получить вознаграждение, и отправьте PR, чтобы добавить ее в список ниже!

[!NOTE] Эта таблица — лишь образец найденных на данный момент уязвимостей. Мы будем раскрывать детали по мере завершения периодов ответственного раскрытия.

Ограничения

• Поддерживаются только кодовые базы на Python.
• Можно выявить только следующие классы уязвимостей:
  • Локальное включение файла (LFI)
  • Произвольная перезапись файла (AFO)
  • Удаленное выполнение кода (RCE)
  • Межсайтовый скриптинг (XSS)
  • SQL-инъекция (SQLI)
  • Подделка серверных запросов (SSRF)
  • Небезопасная прямая ссылка на объект (IDOR)

Установка

[!IMPORTANT] Vulnhuntr строго требует Python 3.10 из-за ряда ошибок в Jedi, используемом для разбора кода Python. При установке с другими версиями Python он не будет работать надежно.

Мы рекомендуем использовать pipx или Docker для простой установки и запуска Vulnhuntr.

С помощью Docker:

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

С помощью pipx:

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

Также можно установить напрямую из исходного кода с помощью poetry:

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

Использование

Этот инструмент предназначен для анализа репозитория GitHub на предмет потенциальных удаленно эксплуатируемых уязвимостей. Инструменту требуется ключ API и локальный путь к репозиторию GitHub. При желании вы также можете указать собственную конечную точку для сервиса LLM.

[!CAUTION] Всегда устанавливайте лимиты расходов или внимательно контролируйте затраты при использовании провайдера LLM. Этот инструмент может привести к значительным расходам, так как он пытается уместить как можно больше кода в окно контекста LLM.

[!TIP] Мы рекомендуем использовать Claude в качестве LLM. В ходе тестирования мы получили лучшие результаты с ним по сравнению с GPT.

Интерфейс командной строки

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)

Примеры

Из установки через pipx, проанализируйте весь репозиторий с помощью Claude:

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

[!TIP] Мы рекомендуем указывать Vulnhuntr конкретные файлы, которые обрабатывают удаленный пользовательский ввод, и сканировать их по отдельности.

Из установки через pipx, проанализируйте файл /path/to/target/repo/server.py с помощью GPT-4o. Вместо файла можно указать подкаталог:

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

Из установки Docker, запустите с помощью Claude и пользовательской конечной точки для анализа /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

Экспериментально

Ollama включен как опция, однако у нас не было успеха с моделями с открытым исходным кодом в правильной структуризации вывода.

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

Логика работы

• LLM обобщает README и включает это в системный промпт
• LLM выполняет первоначальный анализ всего файла и сообщает о любых потенциальных уязвимостях
• Затем Vulnhuntr передает LLM промпт, специфичный для уязвимости, для вторичного анализа
• Каждый раз, когда LLM анализирует код, она запрашивает контекстные функции/классы/переменные из других файлов проекта
• Это продолжается до тех пор, пока вся цепочка вызовов от пользовательского ввода до обработки на сервере не будет завершена, затем выдается окончательный анализ
• Окончательный анализ включает обоснование, подтверждение концепции эксплуатации и оценку уверенности

[!TIP] Как правило, оценки уверенности < 7 означают, что уязвимость маловероятна. Оценки уверенности 7 означают, что ее следует проверить, а оценки 8+ — что уязвимость, скорее всего, является действительной.

Вывод

Инструмент генерирует подробный отчет об уязвимостях, найденных в проанализированных файлах. Отчет включает:

• Результаты первоначальной оценки для каждого файла.
• Результаты вторичной оценки с контекстными функциями и ссылками на классы.
• Оценки уверенности для найденных уязвимостей.
• Журналы процесса анализа.
• PoC эксплойт.

Ниже приведен примера отчета Vulnhuntr, описывающего 0-day уязвимость удаленного выполнения кода в Ragflow (теперь исправлено):

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

Логирование

Инструмент записывает процесс анализа и результаты в файл с именем vulhuntr.log. Этот файл содержит подробную информацию о каждом этапе анализа, включая первоначальную и вторичную оценки.

Авторы

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