Apple закрыла две 0-day, используемые в нашумевшей операции Триангуляция

Apple закрыла две 0-day, используемые в нашумевшей операции Триангуляция

Apple закрыла две 0-day, используемые в нашумевшей операции Триангуляция

Apple устранила три уязвимости нулевого дня (0-day), которые использовались в шпионской кампании «Операция Триангуляция» (Operation Triangulation). Злоумышленники с помощью zero-click эксплойтов устанавливали шпионский софт на iPhone жертв.

О нашумевшей Operation Triangulation стало известно после сообщения от «Лаборатории Касперского». Атака, в которой вредонос проникал на устройства в скрытом сообщении iMessage, затронула и сотрудников Kaspersky.

Буквально вчера российский гигант сферы кибербезопасности рассказал подробности использования шпионской составляющей для iOS. Выяснилось, что атакующие задействовали имплант для iPhone, условно названный TriangleDB.

Теперь Apple отчиталась в устранении двух уязвимостей — CVE-2023-32434 и CVE-2023-32435. Они затрагивают компоненты Kernel и WebKit соответственно. Вот что пишет сама корпорация:

«Мы в курсе, что описанные бреши могут использоваться в атаках на версии iOS до 15.7».

По данным «Лаборатории Касперского», кибершпионы начали использовать 0-day в 2019 году. К слову, в начале месяца ФСБ и ФСО России заявили, что спецслужбы США следят за дипломатами в России через iPhone, однако Apple позже открестилась от подобных практик.

Помимо нашумевших багов, разработчики устранили ещё одну 0-day — CVE-2023-32439 (нашлась в WebKit). Брешь позволяет выполнить произвольный код на непропатченных устройствах. О ней сообщил неназванный исследователь.

Рекомендуем установить свежие заплатки: macOS Ventura 13.4.1, macOS Monterey 12.6.7, macOS Big Sur 11.7.8, iOS 16.5.1 and iPadOS 16.5.1, iOS 15.7.7 and iPadOS 15.7.7, watchOS 9.5.2 и watchOS 8.8.1.

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