Сотни тысяч беззащитных серверов. Redis 13 лет скрывал уязвимость с удалённым выполнением кода
NewsMakerВ коде известный базы данных обнаружили неожиданный сюрприз.
Redis, одна из самых распространённых систем кэширования и баз данных в памяти, пережила неожиданное разоблачение: в её коде обнаружили уязвимость , жившую там тринадцать лет. Ошибка, получившая критический рейтинг 10 из 10 по шкале опасности, даёт злоумышленнику, имеющему доступ с правами пользователя, возможность выполнять произвольный код на сервере. По сути, речь идёт о полном контроле над процессом Redis — ситуации, которая в производственных инфраструктурах может привести к катастрофическим последствиям.
Исследователи из компании Wiz, Бенни Айзекс и Нир Браха, вместе с командой инициативы Trend Micro Zero Day Initiative, выяснили, что брешь затрагивает все версии Redis, поддерживающие выполнение Lua-скриптов. Проблема кроется в том, как система управляет памятью через механизм сборщика мусора. Манипулируя его поведением, злоумышленник может вызвать состояние use-after-free , когда освобождённая область памяти используется повторно. Это открывает путь для внедрения кода, который запускается прямо внутри сервера.
Наибольшее беспокойство вызывает не только серьёзность уязвимости, но и то, что она оставалась незамеченной с момента появления Lua-движка в кодовой базе Redis — почти полтора десятилетия. Redis используется примерно в трёх четвертях всех облачных сред, и столь долгоживущий дефект потенциально затрагивает сотни тысяч компаний и государственных организаций по всему миру. Исследователи подчёркивают: обновление следует установить безотлагательно, начиная с экземпляров, доступных из интернета.
Для пользователей облачного сервиса Redis Cloud ситуация уже решена — исправления применены автоматически. Однако тем, кто управляет инсталляциями самостоятельно (включая открытые, корпоративные и серверные версии), необходимо обновиться вручную до последних сборок, опубликованных на официальном сайте проекта.
По данным Wiz, сейчас в открытом доступе находится около 330 000 Redis-инстансов, из которых примерно 60 000 вовсе не защищены аутентификацией. Это означает, что любой, кто знает IP-адрес сервера, может взаимодействовать с ним напрямую, что делает потенциальное использование уязвимости особенно опасным.
Компания Redis Labs выпустила 3 октября официальное уведомление по безопасности, в котором указано, что на данный момент не зафиксировано случаев эксплуатации дефекта ни в облачной среде, ни в инфраструктуре клиентов. Тем не менее специалисты советуют проверить системы на возможные признаки компрометации. Среди таких индикаторов — соединения с базой данных с неизвестных адресов, необычная исходящая или входящая активность, наличие посторонних скриптов в хранилище, неожиданные сбои сервера, связанные с Lua-модулем, и выполнение команд, которых не должно быть в рабочем процессе.
Администраторы также должны ограничить сетевой доступ к Redis с помощью файерволов и политик безопасности, оставив доступ лишь доверенным источникам, и убедиться, что все подключения защищены паролями. Поскольку Redis часто используется как часть более сложных микросервисных архитектур, незакрытая уязвимость в одном узле способна стать точкой входа для атакующих в целую экосистему.
Redis, одна из самых распространённых систем кэширования и баз данных в памяти, пережила неожиданное разоблачение: в её коде обнаружили уязвимость , жившую там тринадцать лет. Ошибка, получившая критический рейтинг 10 из 10 по шкале опасности, даёт злоумышленнику, имеющему доступ с правами пользователя, возможность выполнять произвольный код на сервере. По сути, речь идёт о полном контроле над процессом Redis — ситуации, которая в производственных инфраструктурах может привести к катастрофическим последствиям.
Исследователи из компании Wiz, Бенни Айзекс и Нир Браха, вместе с командой инициативы Trend Micro Zero Day Initiative, выяснили, что брешь затрагивает все версии Redis, поддерживающие выполнение Lua-скриптов. Проблема кроется в том, как система управляет памятью через механизм сборщика мусора. Манипулируя его поведением, злоумышленник может вызвать состояние use-after-free , когда освобождённая область памяти используется повторно. Это открывает путь для внедрения кода, который запускается прямо внутри сервера.
Наибольшее беспокойство вызывает не только серьёзность уязвимости, но и то, что она оставалась незамеченной с момента появления Lua-движка в кодовой базе Redis — почти полтора десятилетия. Redis используется примерно в трёх четвертях всех облачных сред, и столь долгоживущий дефект потенциально затрагивает сотни тысяч компаний и государственных организаций по всему миру. Исследователи подчёркивают: обновление следует установить безотлагательно, начиная с экземпляров, доступных из интернета.
Для пользователей облачного сервиса Redis Cloud ситуация уже решена — исправления применены автоматически. Однако тем, кто управляет инсталляциями самостоятельно (включая открытые, корпоративные и серверные версии), необходимо обновиться вручную до последних сборок, опубликованных на официальном сайте проекта.
По данным Wiz, сейчас в открытом доступе находится около 330 000 Redis-инстансов, из которых примерно 60 000 вовсе не защищены аутентификацией. Это означает, что любой, кто знает IP-адрес сервера, может взаимодействовать с ним напрямую, что делает потенциальное использование уязвимости особенно опасным.
Компания Redis Labs выпустила 3 октября официальное уведомление по безопасности, в котором указано, что на данный момент не зафиксировано случаев эксплуатации дефекта ни в облачной среде, ни в инфраструктуре клиентов. Тем не менее специалисты советуют проверить системы на возможные признаки компрометации. Среди таких индикаторов — соединения с базой данных с неизвестных адресов, необычная исходящая или входящая активность, наличие посторонних скриптов в хранилище, неожиданные сбои сервера, связанные с Lua-модулем, и выполнение команд, которых не должно быть в рабочем процессе.
Администраторы также должны ограничить сетевой доступ к Redis с помощью файерволов и политик безопасности, оставив доступ лишь доверенным источникам, и убедиться, что все подключения защищены паролями. Поскольку Redis часто используется как часть более сложных микросервисных архитектур, незакрытая уязвимость в одном узле способна стать точкой входа для атакующих в целую экосистему.