Отражены 5 млн атак на WordPress через дыру 0-day в плагине BackupBuddy

Отражены 5 млн атак на WordPress через дыру 0-day в плагине BackupBuddy

Отражены 5 млн атак на WordPress через дыру 0-day в плагине BackupBuddy

Патч для опасной уязвимости в коммерческом WordPress-плагине разработки iThemes включен в состав обновления BackupBuddy 8.7.5 и вышел 2 сентября. С конца августа Wordfence (собственность Defiant) зафиксировала около 4,95 млн попыток эксплойта по своей клиентской базе.

По оценке экспертов, в настоящее время плагин, призванный облегчить управление резервным копированием, установлен и работает примерно на 140 тыс. сайтов. Подозрительную активность первыми заметили разработчики BackupBuddy и оперативно выпустили обновление; пользователи сервиса iThemes Sync получили его автоматически.

Уязвимость CVE-2022-31474 (7,5 балла CVSS) актуальна для сборок с 8.5.8.0 по 8.7.4.1. Эксплойт тривиален и позволяет без аутентификации просматривать и загружать с сайта произвольные файлы, которые могут содержать конфиденциальную информацию. Пользователям настоятельно рекомендуется обновить BackupBuddy до новейшей версии.

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

Бэкапы, создаваемые с помощью BackupBuddy, обычно отправляются в облако — в Google Drive, OneDrive, AWS и т. п. Для локального хранения используется опция Local Directory Copy; некорректная реализация этого механизма и стала причиной появления проблемы.

С 26 августа межсетевой экран Wordfence остановил 4 948 926 атак на клиентские сайты через уязвимость CVE-2022-31474. Около 2 млн попыток эксплойта исходило с IP-адреса 195.178.120[.]89 (Нидерланды, AS-провайдер Delis). Остальные внешние серверы в Топ-10 по этому показателю принадлежат Microsoft и расположены в разных странах — Великобритании, США, Швеции, Канаде, Ирландии.

Как выяснилось, авторов большинства атак интересуют следующие файлы:

  • /etc/passwd
  • /wp-config.php
  • .my.cnf
  • .accesshash

Проверить сайт на предмет компрометации можно просмотром запросов в логах доступа: присутствие параметров local-download и/или local-destination-id, а также полного пути к файлу может свидетельствовать о попытке эксплуатации CVE-2022-31474.

При выявлении взлома iThemes советует сменить пароль к базе данных, соли WordPress и ключи к облачным сервисам в файле wp-config.php. Тем, у кого открыт доступ к phpMyAdmin или WordPress-сервер связан с публичным сервером базы данных, рекомендовано восстановление из бэкапа (созданного до первой попытки несанкционированного доступа, согласно логам). При отсутствии такой возможности придется вручную чистить сайт — с помощью сервиса Hack Repair или своими силами, притом как минимум поискать и удалить подозрительные аккаунты администратора и сбросить пароли остальным админам.

VLESS+REALITY больше не магия: ТСПУ бьёт по поведению

На Хабре запустили новое обсуждение вокруг работы ТСПУ и методов блокировки VPN-трафика. Пользователь darkisdark опубликовал масштабный разбор, в котором утверждает: эпоха простого сигнатурного анализа фактически закончилась, а на смену ей пришла поведенческая фильтрация соединений.

По словам автора, если раньше многие решения могли обходить ограничения за счёт маскировки TLS-отпечатков и имитации обычного HTTPS-трафика, то теперь этого уже недостаточно.

ТСПУ якобы анализирует не содержимое пакетов, а поведение соединений: какие TLS-отпечатки используются, сколько параллельных подключений создаётся и к каким подсетям направляется трафик.

Именно этим darkisdark объясняет массовые сбои VLESS+REALITY, которые пользователи начали фиксировать в феврале и особенно активно — в июне 2026 года.

Типичная картина выглядит так: клиент показывает статус «Connected», соединение формально установлено, но данные не передаются. Интернет словно зависает, хотя явной блокировки нет.

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

В качестве примера приводится инцидент с Delta Chat, когда под ограничения попали TLS-соединения, использующие определённый отпечаток библиотеки Rust ring, что вызвало проблемы у ряда хостинг-провайдеров.

Главный вывод автора: больше не существует неблокируемых протоколов. Побеждает не технология, которая выглядит как обычный HTTPS, а та инфраструктура, которая успевает адаптироваться быстрее, чем системы фильтрации учатся её распознавать.

При этом darkisdark отдельно предупреждает, что многие цифры и пороги срабатывания, фигурирующие в обсуждениях, остаются гипотезами и требуют независимого подтверждения.

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