Хакеры ищут доступные серверы vCenter c незакрытой дырой CVE-2021-21985

Хакеры ищут доступные серверы vCenter c незакрытой дырой CVE-2021-21985

Хакеры ищут доступные серверы vCenter c незакрытой дырой CVE-2021-21985

В интернете наблюдается всплеск сканов, нацеленных на выявление уязвимых экземпляров vCenter Server. Неизвестные пытаются атаковать критическую RCE-брешь, для которой VMware недавно выпустила заплатку.

Уязвимость, о которой идет речь (CVE-2021-21985), связана с работой расширения Virtual SAN Health Check, предназначенного для мониторинга состояния хранилищ vSAN. По словам разработчика, в этом по умолчанию включенном плагине отсутствует проверка достоверности пользовательского ввода. При наличии сетевого доступа к серверу на порту 443 этот недочет можно использовать для выполнения произвольных команд в целевой ОС с самыми высокими привилегиями.

Степень опасности уязвимости оценена в 9,8 балла из 10 возможных по шкале CVSS. Ее наличие подтверждено для vCenter Server веток 7.0, 6.7 и 6.5; проблема затрагивает также гибридные облака, созданные с помощью VMware vCloud Foundation версии 3 или 4. Соответствующие обновления для обоих продуктов были выпущены 25 мая.

Рост скан-активности, связанной с CVE-2021-21985, был зафиксирован несколько дней назад и пока актуален. По всей видимости, этот всплеск спровоцировала публикация PoC-эксплойта.

Схожая ситуация наблюдалась в феврале; VMware тогда тоже пропатчила RCE-уязвимость в vCenter Server (CVE-2021-21972), и через пару дней исследователи обнаружили, что новую лазейку уже вовсю ищут.

Поиск по Shodan на момент выхода заплат для новой RCE выявил тысячи серверов vCenter, подключенных к интернету. Наибольшее количество таких потенциально уязвимых узлов (1,4 тыс.) размещено в США.

Бесплатные VPN начали умирать за пару дней, IP уже ни при чём

Бесплатный VPN из Telegram бодро запускается, а через несколько дней Reels замирают, YouTube уходит в бесконечную загрузку, а Gemini встречает ошибкой 403. Современные системы фильтрации научились распознавать туннели даже без расшифровки трафика.

По версии пользователя Хабра Djin22, теперь одного нового IP-адреса может быть недостаточно.

Анализаторы изучают размеры пакетов, интервалы между ними, структуру TLS-соединения и другие косвенные признаки. Если трафик ведёт себя как прокси, маскировка под обычный HTTPS уже не всегда спасает.

Один из характерных сценариев автор называет «проблемой 16 КБ»: соединение успешно устанавливается, передаёт первые данные, а затем резко замедляется или обрывается. Для борьбы с этим используют фрагментацию пакетов, уменьшение размера TCP-сегментов и десинхронизацию DPI с помощью zapret. Идея проста: сервер должен получить нормальный поток, а анализатор — головоломку.

Отдельная история — сервисы Google. Они могут учитывать TLS-отпечаток клиента и замечать, когда программа притворяется Chrome не слишком убедительно. В sing-box для более правдоподобной имитации браузера применяют uTLS.

Если Telegram не работает даже через VLESS Reality, автор предлагает ShadowTLS v3: протокол маскирует соединение под обычную TLS-сессию с разрешённым ресурсом. Ещё один приём — padding, то есть добавление случайных данных для изменения размеров пакетов и усложнения статистического анализа.

В качестве готовых вариантов Djin22 перечисляет hynet.cloud, AmneziaVPN, Red Shield VPN, Cloudflare WARP и собственные серверы на Xray или sing-box. Однако часть текста о hynet.cloud выглядит рекламно, а заявления об «эмуляции JA4», residential-маршрутизации и автоматическом переключении протоколов приводятся без независимого подтверждения.

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