zbyszkok/cve-2025-49844-redishell-ai-made-revshellНепроверенное завершение PoC Redishell, созданного ИИ
PoC Reverse Shell, созданный ИИ
Непроверенная завершённая версия PoC Redishell, созданная ИИ.
Original PoC:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Korean Piece:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Позже мы подключили GDB — нам удалось получить базовый адрес и выяснить ещё кое-что, но, что самое главное, похоже, что это не простая уязвимость в куче. Что бы мы ни пробовали, выполнение кода было невозможно. Сбой? Да. Команды? Нет.
Мы больше не сильны в реверс-инжиниринге, поэтому не можем быть уверены, но из всего, что мы нашли за часы работы с помощью некоторых сильнейших моделей ИИ, выполнение кода через эту уязвимость невозможно (или это один шанс из тысячи, но это чистое предположение).
Через многочисленные попытки мы в лучшем случае всегда оказывались вот здесь:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Любопытно увидеть настоящий PoC с выполнением кода.
ПРОЧТИТЕ ВНИМАТЕЛЬНО: Мы сказали, ИЗ ВСЕГО, ЧТО МЫ ЗНАЕМ / ВИДЕЛИ НА ДАННЫЙ МОМЕНТ. Это не абсолютное утверждение, возможно, есть какой-то трюк или лакомый кусочек, который мы не учли, есть гораздо более сильные специалисты по бинарным эксплойтам.
Обратите внимание, что Redis Server оставался стабильным — мы извлекли его из Docker для тестирования. Вы можете вызвать сбой, запуская эксплойт несколько тысяч раз, и мы ещё не пробовали комбинировать этот метод перебора с попытками выполнения кода; возможно, это и есть решение.
Как видите, оригинальный PoC, похоже, страдает от тех же проблем; он утверждает, что является «упрощённым», но не совсем понятно, каким должен быть результат.
Пока ничего...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Загадочным образом в примечаниях к патчам Redis указан совершенно другой CVE — также предположительно бинарный эксплойт, но гораздо более простой: стековый переполнение буфера с предполагаемым RCE:
XACKDEL может привести к переполнению стека и потенциальному RCEМы нашли ещё меньше информации об этом. Уже сейчас сложно найти версию без бэкпорта без самостоятельной компиляции, но, возможно, именно этим путём нам и придётся пойти.
Все эти POTENTIALS — у меня есть потенциал. Теперь у меня два потенциала.
62507 — это путь... RCE пока нет, но выглядит легко и многообещающе...
Так что, CVE-2025-49844 был просто обманом? Корейская головоломка так и не вызвала сбой — но она выдаёт совершенно другой вывод на нашей самостоятельно скомпилированной версии 8.2.2. Признаюсь, я тоже поддался мысли: «да, сбой, более чем правдоподобно, вероятно, легко...» и просто предположил, что часть сбоя CVE-2025-49844 будет работать. Но этого никогда не произошло. Извините, что ранее неправильно выразился, но теперь всё прояснилось, надеюсь. CVE-2025-49844 не вызывает сбой, CVE-2025-62507 вызывает сбой.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Выглядит знакомо? Я не знаю, что они там сделали... или никто, кроме меня, не проверял? Мир стал довольно странным местом в последнее время.