Критическая уязвимость в продуктах FireEye активируется одним письмом

Критическая уязвимость в продуктах FireEye активируется одним письмом

Исследователи Google Project Zero, в лице Тевиса Орманди (Tavis Ormandy) и Натали Силванович (Natalie Silvanovich),нашли критическую уязвимость в продукции компании FireEye. Проблема получила зловещее название «666», так как это шестьсот шестьдесят шестой баг, обнаруженный экспертами Project Zero.

Уязвимость, допускающая удаленное исполнение произвольного кода (RCE), касается продуктов серий Network Security (NX), Email Security (EX), Malware Analysis (AX) и File Content Security (FX). Баг обнаружился в MIP (Malware Input Processor) – подсистемном модуле, который анализирует Java JAR-файлы, а затем производит их декомпиляцию. После декомпиляции, модуль проверяет код, сравнивая его с известными вредоносными паттернами. Однако если атакующий отправит в корпоративную сеть файл, который якобы использует обфускацию, это одурачит декомпилятор, по сути, превратив его в инструмент для исполнения произвольных shell-команд, пишет xakep.ru.

Для эксплуатации уязвимости, хакеру достаточно отправить жертве email, содержащий подходящий JAR-файл. Такое письмо даже не нужно читать, достаточно просто его получить. Или атакующий может вынудить пользователя пройти по ссылке, ведущей к вредоносному JAR-файлу. Клик по ссылке или получение письма приведут к компрометации одной из наиболее привилегированных машин во всей сети.

«Для сетей, в которых работают устройства FireEye, уязвимость, которую можно эксплуатировать через интерфейс пассивного мониторинга, может обернуться форменным кошмаром», — пишет Орманди.

Компания FireEye поблагодарила исследователей за обнаружение столь важной проблемы и уже выпустила исправление. Орманди отмечает, что на создание патча специалисты FireEye потратили всего два дня, и он распространился через автоматический апдейтер Security Content.

Подробные технические детали Орманди опубликовал в официальном блоге Project Zero.

Бесплатные 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