Поделиться
Десятки тысяч серверов по всему миру под угрозой взлома из-за крайне опасной «дыры» в сверхпопулярной СУБД, которую не закрывают уже 13 лет
Крайне опасный баг 13-летней давности угрожает серверам со сверхпопулярной СУБД Redis, широко используемой при построении облачной инфраструктуры. Таковых, по оценке экспертов, насчитывается около 60 тыс.Давняя уязвимость в Redis
В популярной СУБД Redis обнаружена крайне опасная уязвимость, которая позволяет аутентифицированному пользователю спровоцировать удаленное выполнение кода на стороне сервера. Как отмечает The Register, брешь оставалась незамеченной на протяжении последних 13 лет, однако доказанных фактов ее эксплуатации пока нет.
Redis (Remote Dictionary Server) – нереляционная NoSQL система управления базами данных с открытым исходным кодом, работающая со структурами данных типа «ключ – значение». Главная особенность – хранение базы данных в оперативной памяти компьютера, за счет чего обеспечивается высочайшая производительность на атомарных операциях. Располагает механизмом снимков и журналирования для обеспечения постоянного хранения на жестких дисках и твердотельных накопителях.
Уязвимость, которой присвоен идентификатор CVE-2025-49844 (степень опасности 10 из 10 по шкале CVSS), затрагивает все версии с поддержкой языка сценариев Lua. С ее помощью злоумышленник имеет возможность добиться возникновения ошибки типа Use-After-Free (использование памяти после освобождения) за счет косвенных манипуляций с механизмом сборки мусора – системы автоматического управления памятью при помощи особого скрипта и покинуть «песочницу» интерпретатора Lua.
Согласно энциклопедии «Лаборатории Касперского», Use-After-Free – это уязвимость, связанная с некорректным использованием динамической памяти в процессе работы программы: при освобождении ячейки памяти указатель на нее не обнуляется, что позволяет хакерам воспользоваться ею в своих целях. В данном случае это может приводить к выполнению программного кода в процессе сервера Redis.
После взлома хоста Redis злоумышленник имеет возможность похитить учетные данные, установить вредоносное программное обеспечение или инструменты для майнинга криптовалюты, извлечь конфиденциальную информацию из БД, получить доступ к иным системам внутри сети жертвы или же внедриться в другие облачные сервисы.
Пользователям сервиса управляемых баз данных Redis Cloud, по информации The Register опасаться уязвимости не стоит – о применении патчей ее закрывающих уже позаботились специалисты. Остальным пользователям Redis, управляющим СУБД самостоятельно, следует установить исправление самостоятельно.
Десятки тысяч уязвимых экземпляров СУБД
По словам Бенни Айзекса (Benny Isaacs) и Нира Браха (Nir Brakha), исследователей из компании Wiz, выявивших этот опасный баг в коде Redis, эта СУБД применяется примерно в 75% облачных сред, что в совокупности с фактом его позднего обнаружения – серьезный повод для беспокойства.
«Организациям настоятельно рекомендуется немедленно установить исправления, уделяя первоочередное внимание тем [экземплярам Redis], что имеют доступ в интернет», – заявили исследователи в разговоре с The Register.
Кроме того, администраторам уязвимых экземпляров Redis рекомендуется включить аутентификацию, декатировать поддержку Lua в СУБД и необязательных команд, если это возможно, а также убедиться в том, что Redis запускается с правами пользователя, отличного от root и др.
Эксплуатация уязвимости требует от злоумышленника получения аутентифицированного доступа к экземпляру Redis, что несколько усложняет поставленную перед ним задачу. Однако, согласно оценке экспертов, через интернет сейчас доступно около 330 тыс. экземпляров СУБД, 60 тыс. для подключения к которым не требуется прохождение процедуры аутентификации. Как сообщил CNews в августе 2025 г., специалисты компании Trend Micro насчитали более 2 тыс. ИИ-серверов с Redis, подключенных к интернету без аутентификации.
Лучше убедиться самостоятельно
Со слов директора по информационной безопасности в Redis Риаза Лахани (Riaz Lakhani), в распоряжении разработчиков СУБД отсутствуют какие-либо сведения о фактах эксплуатации уязвимости в Redis Cloud или окружениях клиентов. Тем не менее, учитывая, что баг «прятался» от программистов Redis последние 13 лет, администратором, вероятно, все же следовало бы проверить используемые экземпляры СУБД на предмет наличия признаков компрометации.
К таковым, как отмечает Лахани, относятся факты подключения к Redis неавторизованных или неизвестных лиц, необычный входящий и исходящий сетевой трафик, присутствие в БД скриптов сомнительного происхождение, сбои сервера, причины которых установить не удалось и источником которых в результате трассировки стека оказывается движок Lua.
Поделиться
Короткая ссылка
