Исследователи проанализировали методы локального перехвата HTTPS-трафика

Исследователи проанализировали методы локального перехвата HTTPS-трафика

Исследователи проанализировали методы локального перехвата HTTPS-трафика

Группа, в которую вошли исследователи из ряда известных университетов, а также представители Mozilla, Cloudflare и Google, провела анализ распространения методов локального перехвата HTTPS-трафика и влияния такого перехвата на сетевую безопасность.

Результаты превзошли ожидания исследователей, оказалось, что 4-11% HTTPS-трафика перехватывается и анализируется сторонним ПО на стороне клиента (антивирусное ПО, межсетевые экраны), при этом в большинстве случаев подобный перехват приводит к уменьшению уровня защиты соединения.

Под локальным перехватом подразумеваются случаи анализа HTTPS-трафика с использованием программного обеспечения, установленного на системе пользователя (например, антивирусное ПО), или применением корпоративных шлюзов инспектирования трафика, работающих в виде прокси. Подобные системы перехватывают обращение клиента, затем от своего лица и с собственным сертификатом транслируют HTTPS-запрос на сервер, получают ответ и отдают его клиенту в рамках отдельного HTTPS-соединения, установленного с использованием SSL-сертификата перехватывающей системы. Для сохранения индикатора защищённого соединения в браузере на машины клиента устанавливается дополнительный корневой сертификат, позволяющий скрыть работу применяемой системы инспектирования трафика, пишет opennet.ru.

Исследователи разработали ряд эвристических методов, позволивших на стороне сервера выявить факты перехвата HTTPS и определить какие именно системы использовались для перехвата. На основании заголовка User Agent определялся браузер, а затем сравнивались специфичные для браузера и фактические особенности устанавливаемого TLS-соединений. Более того, сопоставив такие характеристики TLS-соединения, как параметры по умолчанию, поддерживаемые расширения, заявленный набор шифров, порядок определения шифров и методы сжатия, удалось достаточно точно определить конкретный продукт, применяемый для перехвата трафика.

 

 

Серверные компоненты для определения подмены HTTPS-соединения были установлены на серверы распространения обновлений для Firefox, в сеть доставки контента Cloudflare и на некоторые популярные интернет-магазины. В итоге, на серверах обновления Firefox выявлено 4% перехваченных запросов, в интернет-магазинах - 6.2%, а в CDN-сети Cloudflare - 10.9%. В 62% случаев использование корпоративных систем инспектирования снижало безопасность соединения из-за применения менее надёжных алгоритмов шифрования, а в 58% случаев соединения были подвержены известным уязвимостям. В 10-40% случаев системы перехвата анонсировали при установке соединения с сервером поддержку небезопасных шифров, подверженных MITM-атакам.

 

 

Из рассмотренных 12 шлюзов инспектирования только 5 предлагали актуальный набор шифров, 2 вообще не осуществляли верификацию сертификатов (Microsoft Threat Mgmt и WebTitan Gateway).

 

 

24 из 26 протестированных систем перехвата, работающих на компьютере клиента (как правило антивирусы), снижали общий уровень безопасности HTTPS-соединения. Актуальные наборы шифров предоставлялись в 11 из 26 продуктов. 5 систем не осуществляли верификацию сертификатов (Kaspersky Internet Security 16 Mac, NOD32 AV 9, CYBERsitter, Net Nanny 7 Win, Net Nanny 7 Mac). Продукты Kaspersky Internet Security и Total Security подвержены атаке CRIME. Продукты AVG, Bitdefender и Bullguard подвержены атакам Logjam и POODLE. Продукт Dr.Web Antivirus 11 позволяет откатиться на ненадёжные экспортные шифры (атака FREAK).

 

 

Интересно, что поддерживаемая современными браузерами возможность привязки сертификата к сайту (public key pinning) не работает в случае применения систем локального перехвата трафика. Chrome, Firefox и Safari выполняют данную проверку только если цепочка проверки ключей связана с сертификатом удостоверяющего центра. Проверка не выполняется, если цепочка верификации завершается локальным корневым сертификатом, установленным администратором.

Подпишитесь на новости

Дешёвая поддельная вышка позволяет следить за абонентами 5G

Исследователи из i2CAT Foundation, Университета Мурсии и NEC Laboratories Europe собрали недорогой инструмент 5G-Shark, который заманивает смартфоны на поддельную базовую станцию. Без глушилок, хитрых пакетов и предупреждений на экране телефон сам цепляется за фейковую вышку, считая её подходящей сетью.

Разработка использует открытую программную платформу и доступное SDR-оборудование.

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

Как показало исследование 5G-Shark, протестированные сети почти всегда скрывали постоянный идентификатор абонента, ради чего 5G и должен был отправить классические IMSI-catcher в музей. Но временные идентификаторы GUTI некоторые операторы выдавали почти последовательно.

Учёные собрали 3742 идентификатора в сетях трёх операторов. В отдельных случаях до 84-96% последовательных регистраций одного абонента удавалось связать только по значению GUTI. У оператора, который распределял номера случайнее, показатель упал до 7%.

На слежке сюрпризы не закончились. Поддельная станция отправляла смартфонам сообщения Registration Reject и заставляла Samsung Galaxy S23 откатываться в ограниченный режим 3G без интернета, бесконечно пытаться зарегистрироваться либо намертво подвешивать модем до ручной перезагрузки.


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

Впрочем, объявлять весь 5G дырявым пока рано. Работа опубликована как препринт и ещё не прошла рецензирование, тесты проводились только на семи собственных устройствах исследователей, а атака требует находиться рядом с целью.

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