Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!
CVE-2025-49844 — Сканер и учебное руководство по CVE-2025-49844 (RediShell) — уязвимости use-after-free в Lua-скриптинге Redis. Проверяет Redis-серверы на подверженность уязвимости, предоставляет шаги по устранению и объясняет механику эксплуатации в учебных целях. | Kitploit
Сканер и учебное руководство по CVE-2025-49844 (RediShell) — уязвимости use-after-free в Lua-скриптинге Redis. Проверяет Redis-серверы на подверженность уязвимости, предоставляет шаги по устранению и объясняет механику эксплуатации в учебных целях.
Привет! Это простой инструмент, который я сделал, чтобы помочь людям проверить, уязвимы ли их Redis-серверы к этой ошибке. Он не предназначен для реальных атак — только для обучения и защиты собственных систем.
О чём это всё?
Итак, мои дорогие, вот один из самых интересных косяков 2025 года — CVE-2025-49844. По сути, если кто-то может выполнять Lua-скрипты на вашем Redis-сервере, он может получить доступ к памяти.
Самое важное
Насколько серьёзно?: Критично (9.9/10)
Кто затронут: Все, кто использует Redis версии 8.2.1 или старше
Что происходит: Выполнение кода
Как это делают: Через Lua-скрипты (которые Redis использует для всяких навороченных штук с базами данных)
Давайте начнём!
Шаг 1: Собираем эту штуку
root@kitploit:~
# Сначала подготовим Go
cd scanner
go mod tidy
# Затем соберём сканер
go build -o rscan redis-scanner.go
Шаг 2: Проверяем свои серверы
root@kitploit:~
# Проверка одного сервера
./rscan -host your-server.com -port 6379
# Проверка с паролем (если он есть)
./rscan -host your-server.com -port 6379 -auth yourpassword
# Проверка нескольких серверов сразу
./rscan -host server1.com,server2.com,server3.com
# Или проверка из файла
./rscan -file hosts.txt
Шаг 3: Чиним то, что сломано
root@kitploit:~
# Отключаем Lua-скрипты (это останавливает атаку)
redis-cli ACL SETUSER default -@scripting
# Или просто обновите Redis до последней версии
🛡️ Хорошо! — Ваш Redis защищён (Lua отключён или версия новее)
✅ Отлично! — Ваш Redis в безопасности (версия 8.2.2 или новее)
❌ Упс! — Не удалось подключиться или что-то пошло не так
Как работает эта ошибка памяти
Проблема
Это так называемая ошибка «use-after-free» (использование после освобождения). По сути, у Redis есть система управления памятью, которая иногда путается в том, какую память она уже очистила.
Как должно работать:
📝 Redis создаёт данные в памяти
🔍 Использует эти данные для чего-то
🗑️ Очищает память, когда закончил
✅ Всё безопасно и надёжно
Как это работает на самом деле (ошибка):
📝 Redis создаёт данные в памяти
🔍 Использует эти данные для чего-то
🗑️ Очищает память
🔍 Пытается снова использовать данные (но их уже нет!)
💥 Всё ломается, и этим пользуются для развлечения ;)
Как хакеры это используют
Что они атакуют: Систему Lua-скриптов Redis
Какие команды используют: EVAL и EVALSHA (они выполняют Lua-скрипты)
Чего хотят добиться: Перезаписать память и выполнить произвольный код
Как это исправить
Сделайте это прямо сейчас (первые 24 часа)
Найдите все свои Redis-серверы (их может быть больше, чем вы думаете)
Проверьте их версии (всё, что 8.2.1 или старше, — критично, нужно обновляться!)
Отключите Lua-скрипты (это немедленно остановит атаку)
Спланируйте обновление (это настоящее решение)
Быстрое исправление (остановите атаку прямо сейчас!)
root@kitploit:~
# Отключаем Lua-скрипты (это останавливает атаку)
redis-cli ACL SETUSER default -@scripting
# Или отредактируйте файл redis.conf и добавьте эту строку:
disable-commands eval evalsha
# Затем перезапустите Redis
sudo systemctl restart redis
Ограничьте доступ к сети
root@kitploit:~
# Разрешите только определённым IP-адресам подключаться к Redis
iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP
# Заставьте Redis слушать только определённые сетевые интерфейсы
bind 127.0.0.1 10.0.0.100
Настройте надёжные пароли
root@kitploit:~
# Установите надёжный пароль
redis-cli CONFIG SET requirepass "fuckredis1234ilovehacking!"
# Создайте пользователей с ограниченными правами
redis-cli ACL SETUSER appuser on >password +@read +@write -@scripting
redis-cli ACL SETUSER readonly on >password +@read -@scripting
Обновите Redis (настоящее решение)
root@kitploit:~
# Сначала сделайте резервную копию данных (всегда делайте это!)
sudo cp -r /var/lib/redis /var/lib/redis.backup.$(date +%Y%m%d)
# Обновите Redis до исправленной версии
# На Ubuntu/Debian:
sudo apt update && sudo apt install redis-server=8.2.2*
# На CentOS/RHEL:
sudo yum update redis
# Проверьте, что всё сработало
redis-server --version
Проверьте, что ваше исправление действительно работает
Убедитесь, что скрипты заблокированы
root@kitploit:~
# Эта команда должна завершиться ошибкой, если исправление работает
redis-cli -a "YourPassword" EVAL "return 'test'" 0
# Должно быть: (error) ERR unknown command 'EVAL'
Проверьте сетевую безопасность
root@kitploit:~
# Проверьте, доступен ли Redis из сети
nmap -p 6379 your-redis-server
# Проверьте, требуется ли пароль
redis-cli -h your-redis-server -p 6379 ping
# Должен запросить пароль
Как обнаружить эту атаку
Признаки в вашей сети
Увеличение использования Lua-скриптов
Кто-то отправляет очень большие или сложные скрипты
Много скриптов выполняется очень быстро
Скрипты, которые явно выглядят подозрительно
Признаки на вашем сервере
Redis постоянно падает или перезапускается
Использование памяти скачет вверх и/или вниз
Redis устанавливает странные сетевые соединения
Обращение к файлам, к которым не должно быть доступа
Это довольно сложно (если вы не понимаете, что происходит)
Нужно понимать, как Redis работает внутри
Трюки с памятью: Приходится вмешиваться в управление памятью Redis
Навыки Lua: Нужно хорошо уметь писать Lua-скрипты
Идеальный тайминг: Нужно вызвать ошибку в точно правильный момент
Как выглядят реальные эксплойты
Создание странных паттернов памяти: Написать Lua-скрипты, которые заставляют Redis располагать память определённым образом
Обман процесса очистки: Заставить Redis очищать память в неподходящий момент
Поломка памяти: Вызвать использование Redis уже удалённой памяти
Выполнение своего кода: Использовать сломанную память для выполнения чего угодно
Насколько это на самом деле серьёзно?
Что произойдёт, если вас взломают
Полный захват: Хакеры могут выполнять что угодно на вашем сервере
Все ваши данные: Они могут увидеть всё в вашей базе данных Redis
Распространение на другие серверы: Они могут использовать ваш сервер для атак на другие системы
Скрытное присутствие: Они могут сохранить доступ, даже когда вы думаете, что всё исправили
Что это значит для вашего бизнеса
Утечка данных: Вся ваша конфиденциальная информация может быть украдена
Всё ломается: Ваш сервис Redis может перестать работать
Юридические проблемы: Вас могут оштрафовать за недостаточную защиту данных
Потеря доверия: Клиенты могут уйти, если узнают об этом
Давайте углубимся в технические детали
Какие части Redis сломаны
Движок Lua-скриптов (команды eval и evalsha)
Как Redis управляет памятью
Система сборки мусора (очищает неиспользуемую память)
Как ломается память
Ошибка возникает, когда:
Вы создаёте определённые паттерны объектов в Lua
Вы вмешиваетесь в подсчёт ссылок на память в Redis
Вы заставляете Redis очищать память в неподходящий момент
Вы используете тайминг управления памятью Redis
Какие версии затронуты
Redis версии 8.2.1 и старше
Любая версия с включёнными Lua-скриптами
Эта ошибка существует уже около 13 лет (ой-ой!)
Как выглядят эксплойты (для обучения)
Базовая структура (Это не будет работать на самом деле)
root@kitploit:~
-- Это просто для демонстрации структуры
local function create_memory_pattern()
-- Создаём объекты, которые мешают очистке памяти Redis
local objects = {}
for i = 1, 1000 do
objects[i] = {data = "pattern_" .. i}
end
return objects
end
local function trigger_gc()
-- Заставляем Redis очищать память в неподходящий момент
collectgarbage("collect")
-- Здесь и происходит ошибка памяти
end
-- Основная структура атаки
local objects = create_memory_pattern()
-- Вмешиваемся в ссылки на память
-- Заставляем сборщик мусора работать
-- Используем сломанную память для выполнения кода
Как защитить себя
Ограничьте доступ к сети
Настройте правила брандмауэра
Не позволяйте Redis общаться со всем интернетом
Следите за сетевым трафиком
Включите журналирование
Контролируйте, кто имеет доступ
Используйте надёжные пароли
Настройте права пользователей (ACL)
Давайте людям только тот доступ, который им нужен
Регулярно проверяйте, кто имеет доступ
Следите за проблемами
Просматривайте свои журналы
Мониторьте производительность Redis
Следите за странным поведением
Имейте план действий на случай проблем
Хотите безопасно протестировать?
Если вы хотите увидеть, как это работает, не ломая ничего реального, можно использовать Docker:
root@kitploit:~
# Запустите тестовый Redis (этот уязвим)
docker run -d --name redis-test -p 6379:6379 redis:6.0
# Протестируйте его
cd scanner
./rscan -host localhost -port 6379
# Остановите уязвимый и запустите исправленный
docker stop redis-test
docker run -d --name redis-fixed -p 6379:6379 redis:6.0 redis-server --rename-command EVAL "" --rename-command EVALSHA ""
./rscan -host localhost -port 6379
# Очистите всё после завершения
docker stop redis-fixed && docker rm redis-fixed
Дополнительные возможности (если нужно)
Все опции
root@kitploit:~
cd scanner
./rscan --help
Сканирование нескольких серверов
Создайте файл hosts.txt примерно так:
root@kitploit:~
# Укажите здесь свои серверы
server1.com
server2.com:6380
192.168.1.100
redis.example.com:6379
Ускорение работы
root@kitploit:~
# Используйте больше воркеров для более быстрого сканирования (если у вас много серверов)
./rscan -host server1.com,server2.com -workers 20
Что вам понадобится
Go 1.21+ (для сборки сканера)
redis-cli (для подключения к Redis)
Docker (необязательно, для безопасного тестирования)
