Команда Red Hat выпустила рекомендации по смягчению уязвимости memcached

Команда Red Hat выпустила рекомендации по смягчению уязвимости memcached

Команда Red Hat выпустила рекомендации по смягчению уязвимости memcached

Команда Red Hat сообщила, что она осведомлена о серьезной угрозе атак DDoS, использующих уязвимость memcached в серверах, открытых на доступ извне. Также специалисты опубликовали ряд рекомендаций для пользователей, которые желают снизить воздействие этой бреши.

Прежде всего, грамотная настройка брандмауэра. Только в очень редких случаях сервер memcached должен быть доступ извне по Сети. Эксперты призывают пользователей установить брандмауэр, чтобы обеспечить доступ к серверам memcached только из локальной сети.

Не допускайте внешний трафик на порты, используемые memcached (например, на 11211, который используется по умолчанию). К примеру, фаервол Red Hat Enterprise Linux не разрешает доступ к этому UDP-порту в конфигурации по умолчанию.

Во-вторых, отключить UDP.

«Если вам не требуется использовать UDP для memcached, мы настоятельно рекомендуем переключиться на TCP-соединения для вашего сервера (для этого надо добавить "-U 0" в переменную OPTIONS в /etc/sysconfig/memcached). Если вам требуется использование UDP, а также необходим удаленный доступ к серверам memcached, рекомендуется настроить брандмауэр для разрешения соединений только с доверенных хостов», — пишет команда Red Hat.

Ниже приведен пример файла /etc/sysconfig/memcached с отключенным UDP:

PORT="11211"
USER="memcached"
# max connection 2048
MAXCONN="2048"
# set ram size to 2048 - 2GiB
CACHESIZE="4096"
# disable UDP and listen to loopback ip 127.0.0.1
OPTIONS="-U 0 -l 127.0.0.1"

Более подробные рекомендации по правильной конфигурации memcached специалисты Red Hat опубликовали здесь.

Напомним, что в конце февраля мы сообщали, что утилита для кеширования memcached используется для DDoS-атак. А в пятницу стало известно о крупнейшей в истории DDoS-атаке, совершенной на Github, в которой как раз использовалась уязвимость memcached.

Критическая дыра в Elementor Pro позволяет захватывать WordPress-сайты

В плагине Elementor Pro для WordPress обнаружили критическую уязвимость CVE-2026-32475, позволяющую без аутентификации загрузить на сервер PHP-файл и выполнить произвольный код. Под угрозой находятся версии до 4.2.2. Проблема скрывается в модуле загрузки файлов.

Как выяснили специалисты Patchstack, проверка и сохранение вложений выполняются разными циклами, которые неодинаково реагируют на пустое имя файла.

Атакующий может отправить специально подготовленный запрос из нескольких частей. В первой будет файл без имени, а во второй — PHP-бэкдор. Проверка споткнётся о пустую запись и завершится, так и не добравшись до полезной нагрузки.

А обработчик загрузки, наоборот, пропустит пустышку и заботливо сохранит следующий файл в публичном каталоге wp-content/uploads/elementor/forms/.

После этого остаётся определить имя загруженного файла и открыть его по прямой ссылке. Сервер запустит PHP-код с правами веб-сервера, и сайт фактически перейдёт под управление атакующего.

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

Для атаки на сайте должна быть опубликована форма Elementor Pro с полем загрузки и включённой возможностью прикреплять несколько файлов. Эта настройка по умолчанию отключена. Бесплатная версия Elementor, насчитывающая более 10 млн установок, уязвимости не подвержена.

Разработчики закрыли брешь в Elementor Pro 4.2.2. Администраторам советуют немедленно обновить плагин и проверить каталог загрузок на PHP-файлы и другие незнакомые сюрпризы. Само обновление уже заброшенные бэкдоры не удалит.

Активных атак пока не зафиксировано. Но теперь, когда технические подробности опубликованы, они не заставят себя ждать.

RSS: Новости на портале Anti-Malware.ru