CVE-2025-4396 — Набор инструментов для Time-Based Blind SQL-инъекции WordPress Relevanssi

Обзор

Этот репозиторий содержит практическое исследование и набор инструментов для проверки CVE-2025-4396 — неаутентифицированной Time-Based Blind SQL-инъекции, затрагивающей плагин WordPress Relevanssi через параметр cats.

Проект был создан для авторизованных Purple Team-задач с целью:

• проверить эксплуатацию в контролируемой среде,
• продемонстрировать разные уровни техники атакующего,
• измерить покрытие обнаружения SOC,
• извлечь хеш пароля WordPress реалистичным способом,
• и автоматизировать офлайн-взлом после получения хеша.

Репозиторий включает:

• стандартный скрипт извлечения,
• более быстрый скрипт извлечения с бинарным поиском,
• и вспомогательный скрипт для подготовки и взлома извлечённого хеша WordPress 6.8+ с помощью Hashcat.

Отказ от ответственности
Данный проект предоставляется только для образовательных целей, защитной проверки и авторизованного тестирования безопасности.
Не используйте его против систем, которые вам не принадлежат или на проверку которых у вас нет явного письменного разрешения.

Тестовая среда

• Сервер: Debian 11
• WordPress 6.9.1,
• Плагин Relevanssi 4.24.4 (скачан с https://wordpress.org/plugins/relevanssi/advanced/),
• POC использовался с ОС Kali Linux.

Описание CVE

CVE-2025-4396 — это уязвимость SQL-инъекции, затрагивающая функциональность поиска Relevanssi в WordPress.

В протестированном сценарии проблема достигается через рабочий процесс поиска и, в частности, через параметр cats. Уязвимый участок кода позволяет вводимым данным, контролируемым атакующим, влиять на SQL-запрос, генерируемый плагином.

Поскольку уязвимая конечная точка доступна без предварительной аутентификации, удалённый злоумышленник может использовать эту ошибку для выполнения неаутентифицированной SQL-инъекции.

Практические последствия включают:

• манипуляцию запросами к базе данных,
• Time-Based Blind SQL-инъекцию,
• извлечение конфиденциальных данных, таких как хеши паролей,
• и, в зависимости от среды, возможное повышение привилегий через восстановление валидных учётных данных.

Как работает уязвимость

Коренная причина

Уязвимость существует потому, что вводимые пользователем данные из параметра, связанного с поиском, не обрабатываются безопасно перед включением в SQL-запрос.

На практике это означает, что атакующий может внедрить SQL-выражения в логику backend-запроса и заставить базу данных выполнить дополнительные условия.

Почему она слепая

Уязвимость эксплуатируется в слепом режиме, то есть приложение не отображает напрямую ошибки SQL или необработанные результаты базы данных.

Вместо чтения вывода запроса со страницы атакующий задаёт базе данных серию вопросов «истина/ложь» и наблюдает за одним побочным эффектом:

• если условие истинно, база данных «засыпает» на несколько секунд,
• если условие ложно, ответ возвращается немедленно.

Почему она основана на времени

Эксплуатация основана на SQL-функциях, таких как SLEEP(), чтобы создать измеримую разницу во времени ответа сервера.

Это позволяет атакующему извлечь данные, не видя их напрямую.

Например, атакующий может задать такие вопросы:

• «Первый символ равен a?»
• «ASCII-значение второго символа больше 77?»
• «Первые N символов соответствуют этому шаблону?»

Повторяя этот процесс, атакующий может восстановить полный хеш посимвольно.

Как работает эксплуатация

Логика стандартного извлечения

Стандартный подход перебирает известный набор символов и проверяет каждого кандидата по одному.

Для каждой позиции в целевом хеше:

1. Строится SQL-условие, нацеленное на один символ.
2. Задержка на сервере вызывается только если догадка верна.
3. Измеряется время отклика.
4. Тот же запрос отправляется повторно для уменьшения ложных срабатываний из-за сетевого джиттера.
5. Подтверждённый символ добавляется к извлекаемому хешу.
6. Переход к следующей позиции.

Этот метод прост и надёжен, но относительно медленен, поскольку может потребовать много запросов на символ.

Логика извлечения с бинарным поиском

Более быстрый подход использует бинарный поиск по ASCII-значению каждого символа.

Вместо вопросов:

• «Символ равен a?»
• «Символ равен b?»
• «Символ равен c?»

задаются вопросы:

• «ASCII-значение больше 79?»
• «Больше 55?»
• «Больше 43?»

Это делит пространство поиска пополам на каждом запросе и значительно сокращает количество HTTP-запросов.

Практический результат

Атака позволяет оператору извлечь значение user_pass из таблицы wp_users, обычно для выбранного ID пользователя WordPress, такого как:

• 1 для администратора по умолчанию,
• или любой другой ID, переданный в командной строке.

В последних версиях WordPress это значение может использовать новый конвейер паролей WordPress 6.8+, который объединяет:

• этап предварительного хеширования с помощью HMAC-SHA384,
• кодирование Base64,
• и окончательный хеш bcrypt.

Включённые скрипты

1. CVE_2025_4396.py

Это стандартный скрипт извлечения.

Назначение:

Он выполняет классическую Time-Based Blind SQL-инъекцию и извлекает целевой хеш посимвольно, используя линейный поиск по фиксированному набору символов.

Ключевые характеристики:

• простой и лёгкий для понимания,
• надёжный в стабильных средах,
• двойная проверка для уменьшения ложных срабатываний,
• полезен как база для инженерии обнаружения и демонстрации PoC.

Как работает:

Для каждой позиции символа:

• перебирает предопределённый набор символов,
• строит SQL-условие, соответствующее одному символу,
• ожидает ответа сервера,
• подтверждает попадание вторым запросом.

Требования:

• python3
• requests
• urllib3

Установка:

pip3 install requests urllib3

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

python3 CVE_2025_4396.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Аргументы:
    -t, --target : URL уязвимой цели, включая инжектируемый параметр
    -u, --userid : ID пользователя WordPress для атаки
    -s, --sleep : порог задержки в секундах
    -v, --verbose : включить отладочный вывод

2. CVE_2025_4396_Stealth.py

Это версия с бинарным поиском.

Назначение:

Она выполняет ту же задачу извлечения, что и стандартный скрипт, но заменяет линейный посимвольный поиск бинарным поиском по ASCII-значениям.

Ключевые характеристики:

• значительно меньше HTTP-запросов,
• меньший сетевой след,
• по-прежнему включает этап двойной проверки для предотвращения ложных срабатываний.

Как работает:

Для каждой позиции:

• Определяется диапазон печатных ASCII-символов.
• Проверяется средняя точка.
• Задаётся вопрос, больше ли целевой символ этой средней точки.
• Диапазон соответственно сужается.
• Продолжается до тех пор, пока не будет определён точный символ.

Требования:

• python3
• requests
• urllib3

Установка:

pip3 install requests urllib3

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

python3 CVE_2025_4396_Stealth.py -t "https://target.local/?s=test&cats=" -u 1 -s 3 -v

Когда использовать:

• цель подтверждена как уязвимая,
• задержка достаточно стабильна,
• и цель — сократить объём запросов.

Рабочий процесс офлайн-взлома хеша

После извлечения хеша пароля из WordPress следующим шагом является его офлайн-взлом.

Примечания по хешированию WordPress 6.8+. В протестированном рабочем процессе извлечённое значение может выглядеть так:

$wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Для Hashcat используемая часть bcrypt:

$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Однако этот bcrypt применяется не напрямую к сырому паролю. WordPress сначала применяет этап предварительной обработки:

• обрезка пароля-кандидата в стиле PHP,
• HMAC-SHA384 с ключом wp-sha384,
• кодирование полученного дайджеста в Base64,
• затем проверка bcrypt.

Зачем нужен этап предварительного хеширования

Это означает, что обычный словарь не может быть напрямую передан в Hashcat, если вы хотите воспроизвести точную логику WordPress 6.8+.

Вместо этого каждый пароль-кандидат должен быть сначала преобразован в его представление, совместимое с предварительным хешированием WordPress.

Репозиторий также включает «вспомогательный» скрипт, который:

• принимает извлечённый хеш в качестве аргумента,
• удаляет префикс $wp$ при необходимости,
• предварительно обрабатывает предоставленный словарь,
• генерирует преобразованный словарь,
• опционально создаёт файл сопоставления,
• автоматически запускает Hashcat,
• преобразует восстановленный предварительный хеш обратно в исходный открытый пароль.

Типичный рабочий процесс

Извлечь хеш:

• Пример результата: $wp$2y$10$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.

Подготовить среду для взлома:

• python3
• hashcat доступен в PATH

Запустить Auto_Crack.py:

python3 Auto_Crack.py -H '\$wp\$2y\$10\$zPA8xGJMvr.kvAAIIYaCreIMnTDpgw/9o8K7.ONBm/KBbNIywQtu.' -w /usr/share/wordlists/rockyou.txt

Необходимо экранировать "$" с помощью "\" — совместимость с bash

Рекомендации для обнаружения SOC

Следующее содержимое для обнаружения может использоваться командами SOC для выявления попыток эксплуатации и измерения зрелости защиты.

Сигнатура Sigma

title: Potential Time-Based Blind SQLi (CVE-2025-4396 Relevanssi)
id: 5a8a1c93-5c74-4b5b-a620-8e1c3e41ab5d
status: experimental
description: Detects HTTP GET requests containing typical Time-Based Blind SQL injection payloads often used to exploit CVE-2025-4396 in the WordPress Relevanssi plugin (bypassing comma filters).
author: n3fhara
date: 2026-03-18
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2025-4396
logsource:
    category: webserver
detection:
    selection_endpoint:
        cs-uri-query|contains:
            - 's='
            - 'cats='
            - 'tags='
    selection_payload:
        cs-uri-query|contains:
            - 'SLEEP('
            - 'WAITFOR'
            - 'SUBSTRING('
            - 'ASCII('
            - 'LENGTH('
    selection_bypass_indicators:
        cs-uri-query|contains:
            - 'FROM'
            - 'FOR 1'
            - '*('
    condition: selection_endpoint and selection_payload and selection_bypass_indicators
falsepositives:
    - Highly unlikely. Legitimate search queries should not contain SQL functions.
level: high

Сигнатура Suricata

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET EXPLOIT WordPress Relevanssi SQLi Attempt (CVE-2025-4396)"; flow:established,to_server; content:"GET"; http_method; content:"cats="; http_uri; pcre:"/(cats|tags)=.*(SLEEP|WAITFOR)%28.*(%2A|\*).*SUBSTRING/i"; classtype:web-application-attack; sid:1000001; rev:1; metadata:created_at 2026_03_18, cve CVE_2025_4396;)

Сигнатура SPLUNK

index=web_logs sourcetype=access_combined 
| regex uri_query="(?i)cats=|tags="
| stats count as request_count, avg(response_time) as avg_time, max(response_time) as max_time, dc(uri_query) as unique_payloads by clientip
| where request_count > 20 AND max_time > 2000
| sort - max_time

Сигнатура KQL

url.query : (*cats=* OR *tags=* OR *s=*) AND url.query : (*SLEEP* OR *WAITFOR* OR *SUBSTRING* OR *ASCII*) AND url.query : (*FROM* OR *FOR* OR *%2A*)

Сигнатура EQL

sequence by source.ip with maxspan=1m
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]
  [network where url.path == "/" and url.query : "*cats=*" and event.duration > 2000000000]

Пробелы в обнаружении и рекомендации

Базовые сигнатуры, указанные выше, хороши для необфусцированной эксплуатации, но становятся слабее, когда оператор внедряет более продвинутые техники.

Видимость SOC ухудшается, когда атакующий начинает использовать:

• альтернативные SQL-функции вместо очевидных,
• URL-кодирование и обфускацию на основе комментариев,
• уменьшенный объём запросов с помощью бинарного поиска,
• джиттер и низкоскоростную временную задержку,
• ротацию прокси,
• имитацию браузера.

Дополнительные идеи для обнаружения SOC:

• Обнаружение необычного медленного поискового трафика,
• Мониторинг запросов к конечной точке поиска WordPress, где:
  • время отклика многократно увеличено,
  • один и тот же клиент выполняет много поисковых запросов,
  • или одна и та же конечная точка показывает аномальные паттерны задержки с течением времени.
• Срабатывание на параметры поиска, содержащие закодированные операторы,
• Даже если очевидные SQL-ключевые слова не видны, параметры поиска, содержащие комбинации:
  • закодированных операторов сравнения,
  • подозрительной плотности скобок,
  • повторяющейся числовой логики,
  • или сильно URL-закодированных строк запроса.
• Корреляция по конечной точке, а не только по исходному IP,
• Если атакующий ротирует прокси, корреляция по IP становится слабой. Обнаружение также должно фокусироваться на:
  • повторяющихся обращениях к одной и той же конечной точке,
  • повторяющихся задержках ответов,
  • или повторяющихся некорректных поисковых запросах, нацеленных на одну и ту же страницу WordPress.
• Использование поведенческого обнаружения с длительным окном:
  • 30 минут,
  • 1 час,
  • или окна в несколько часов.
• Мониторинг медленных запросов на стороне базы данных

Структура репозитория

.
├── CVE_2025_4396.py
├── CVE_2025_4396_Stealth.py
├── Auto_Crack.py
├── README.md
└── relevanssi.4.24.4.zip

Юридическое уведомление

Используйте только в средах, где у вас есть явное разрешение на тестирование. Авторы и участники не несут ответственности за неправомерное использование.

Отказ от ответственности
Данный проект предоставляется только для образовательных целей, защитной проверки и авторизованного тестирования безопасности.
Не используйте его против систем, которые вам не принадлежат или на проверку которых у вас нет явного письменного разрешения.