Монстры внутри Middlebox’ов: Две новые утилиты для детектирования перехвата HTTPS-трафика

Авторы: Gabbi Fisher, Luke Valenta

Перехват HTTPS-трафика остается распространенным явлением в интернете. Одно из наиболее детальных исследований, касающееся влияния этой практики, было обнародовано в статье «The Security Impact of HTTPS Interception». Кроме того, команда US-CERT предупреждает, что HTTPS-перехват ослабляет безопасность систем. В этой заметке мы рассмотрим случаи, когда используется перехват HTTPS-трафика, и рассмотрим две новые утилиты:

• MITMEngine: библиотека с открытым исходным кодом, предназначенная для детектирования перехвата HTTPS-трафика.

• MALCOLM: информационная панель, отображающая метрики, касающиеся HTTPS-перехвата, отслеживаемого нами трафика, проходящего через в сеть Cloudflare.

В базовом варианте взаимодействия по протоколу HTTS браузер (клиент) инициирует TLS-соединение напрямую к серверу для отправки запросов и загрузки контента. Однако многие подключения в интернете идут не напрямую, а через прокси или middlebox(«монстр посередине» или MITM). Существует несколько причин для подобного рода схем, как легитимных, так и злонамеренных.

Типы перехвата HTTPS-трафика

Одни из самых распространенных HTTPS-перехватчиков – прямые (пересылочные) прокси сервера с поддержкой TLS-terminating (то есть когда расшифровывается TLS на некоторое время). Прокси без поддержки TLS-terminating передают TLS-соединение как есть без анализа расшифрованного трафика.

Прокси с поддержкой TLS-terminating находятся перед клиентом во время TLS-подключения и прозрачно передают, возможно модифицируя, трафик от браузера к целевому серверу. Для реализации этой схемы прокси должен завершить TLS-подключение от клиента, а затем (следует надеяться) повторно шифрует и передает полезную нагрузку целевому серверу в новом TLS-соединении. Для перехвата соединения без возникновения предупреждений на клиенте касательно сертификата браузера, прямые прокси часто требуют установки корневого сертификата на машине пользователя. Таким образом, прокси сможет cгенерировать и предоставить браузеру достоверный сертификат, связанный с целевым сервером. Корневые сертификаты обычно устанавливаются сетевыми администраторами на устройствах, управляемых корпоративно, без вмешательства конечных пользователей.

Антивирусы и корпоративные прокси

Прямой прокси может использоваться антивирусом или корпоративным сервером для инспектирования зашифрованных данных попадающих и покидающих локальную сеть для детектирования подозрительного содержимого, вредоносов и информационных утечек. Например, компания Symantec предлагает комплекс Blue Coat Data Loss Prevention. При использовании этого пакета перед отсылкой запроса в пункт назначения при помощи HTTPS-перехвата выполняется проверка на предмет утечек конфиденциальных сведений.

Вредоносные прокси

Вредоносные прямые прокси могут вставлять рекламу в веб-страницы или собирать конфиденциальные сведения о пользователях. Например, вирусы наподобие Superfish вставляют таргетированную рекламу в зашифрованный трафик. Для реализации этой схемы требуется перехват и модификация HTTPS-трафика во время ответа, отсылаемого клиенту.

Прокси с утечкой информации

Любой прямой прокси с поддержкой TLS-terminating – вне зависимости от предназначения – рискует стать причиной утечки конфиденциальной информации и открывает дверь для спуфинга. Когда установлен корневой сертификат прокси-сервера, браузер не может проверить достоверность подключения и должен доверять прокси в плане безопасности конфиденциальных данных. Некоторые прокси повторно шифруют и передают трафик в пункт назначения, используя не очень безопасные TLS-параметры.

Прокси также может требовать установки корневого сертификата производителя, который легко может быть использован злоумышленниками во вредоносных целях. В ноябре 2018 года вышла заметка, описывающая инцидент, связанный требованием установки корневого сертификата с небезопасными параметрами для одной из моделей беспроводных наушников Sennheiser. Этот корневой сертификат мог использоваться любым злоумышленником для работы от имени сайта и отсылки поддельных ответов системам, где установлен этот сертификат. Кроме того, при помощи этого сертификата можно получить доступ к другим зашифрованным данным.

Прямые прокси с поддержкой TLS-terminating могут даже доверять небезопасным корневым сертификатам, как, например, от компании Symantec. В случае ненадлежащей реализации подобные прокси сервера могут стать инструментом для различного рода атак, направленных на утечку конфиденциальных данных или подделку ответов.

Реверсивные прокси

Реверсивные прокси также находятся между пользователями и серверами. Однако прокси наподобие Cloudflare и Akamai используются уже в интересах сервера для кэширования статической информации, улучшения скорости отдачи контента и защиты от вторжений (например, от DDoS атак). Важное уточнение: реверсивные прокси не требует установки специальных корневых сертификатов на пользовательских устройствах, поскольку браузеры подключаются напрямую к реверсивному прокси для загрузки содержимого, хранимого на целевом сервере. Реверсивные прокси часто используются серверами для улучшения безопасности клиентских HTTPS-соединений (например, принуждая к строгим политикам безопасности и новейшим протоколам наподобие TLS 1.3). В этом случае реверсивные прокси выступают в роли посредников, улучшая производительность и безопасность TLS-подключений.

Почему актуальна тема детектирования перехвата HTTPS-трафика?

В одной из предыдущих статей мы утверждали, что перехват HTTPS-трафика довольно распространен в интернете и часто влияет на безопасность подключений в худшую сторону. Сервера, отказывающиеся работать с недостаточно безопасными соединениями, обычно защищены от многих рисков. Однако существует множество причин, когда нужно знать, был ли перехвачен HTTPS-трафик у клиентов.

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

Во-вторых, системы инспектирования содержимого могут не только ослабить безопасность TLS-подключений, но и замедлить внедрение инноваций и улучшений в TLS. Пользователи, подключающиеся через устаревшие middlebox’ы, могут использовать старые версии протоколов и не использовать нововведения в области безопасности, производительности и приватности даже если новые версии поддерживаются и браузером и сервером.

MITMEngine: детектор перехвата HTTPS-трафика

Многие реализации TLS-клиентов могут быть однозначно опознаны при помощи Client-Hello-сообщений, как, например, поддерживаемая версия, наборы шифрования, расширения, эллиптические кривые, форматы точек, тип сжатия и алгоритмы сигнатур. Техника, представленная в статье «The Security Impact of HTTPS Interception», конструирует сигнатуры Client-Hello-сообщений, подходящие для самых распространенных браузеров и middlebox’ов. Затем для обнаружения перехваченных HTTPS-запросов сервер может найти подпись (сигнатуру), соответствующую запросу User Agent, и проверить, есть ли соответствие сигнатуре Client-Hello-сообщение из запроса. Несоответствие свидетельствует либо о подделке User Agent или перехвате HTTPS-подключения. Сервер также может сравнить Client-Hello-сообщения из запроса с сообщениями, используемые стандартными перехватчика, с целью обнаружения конкретной версии.

В утилите Caddy Server MITM Detection используются подобного рода эвристики и поддерживается ограниченное количество версий браузеров. Однако нам нужен инструмент, легко применимый к большому количеству реализаций TLS, поддерживаемых Cloudflare, со следующими характеристиками:

• Расширяемость: нужно уметь легко добавлять новые браузеры и обновлять сигнатуры существующих браузеров в случае выхода новой версии.

• Широта охвата: Сигнатуры должны охватывать достаточно большой спектр поведенческих характеристик TLS-клиента. Например, сигнатуры должны учитывать значения GREASE, отсылаемые современными версиями Chrome.

• Производительность: Детектирование MITM в каждом запросе не должно отнимать много ресурсов в случае, если возникнет необходимость в масштабировании.

Для соответствия вышеуказанным требованиям команда Cryptography компании Cloudflare разработала MITMEngine, детектор перехвата HTTPS-трафика с открытым исходным кодом, представляющий собой библиотеку Golang, которая собирает User Agent и признаки Client-Hello сообщений протокола TLS, а затем возвращает вероятность HTTPS-перехвата и факторы, используемые для идентификации перехвата.

MITMEngine сравнивает значения, полученные из Client-Hello сообщений с уже известными наборами, привязанными к конкретной версии браузера. Сравниваются следующие параметры:

• Версия TLS.

• Наборы шифров (cipher suite).

• Расширения и значения расширений.

• Поддерживаемые группы эллиптических кривых.

• Форматы точек эллиптических кривых.

После считывания User Agent и Client-Hello сообщения, MITMEngine ищет отличия между полученным Client-Hello сообщение и сигнатурой, привязанной к указанному браузеру. Например, рассмотрим следующий User Agent:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)

Chrome/47.0.2526.111 Safari/537.36

Вышеуказанный User Agent соответствует Chrome 47, запущенному в Windows 7. Соответствующее Client-Hello сообщение, включающее наборы шифров, показано ниже в шестнадцатеричном формате:

0000 c0 2b c0 2f 00 9e c0 0a c0 14 00 39 c0 09 c0 13 .+./.... ...9....

0010 00 33 00 9c 00 35 00 2f 00 0a .3...5./ ..

Эти наборы соответствуют следующему списку из 13 шифров, перечисленных в определенной последовательности:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)

TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)

TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Отпечаток набора шифров для Client-Hello сообщения, соответствующий Chrome 47, показан ниже:

0000 c0 2b c0 2f 00 9e cc 14 cc 13 c0 0a c0 14 00 39 .+./.... .......9

0010 c0 09 c0 13 00 33 00 9c 00 35 00 2f 00 0a .....3.. .5./..

Если присмотреться внимательно, можно заметить, что перечень наборов шифров в анализируемом трафике короче, чем предусмотрено для Chrome 47. Два набора шифров были удалены, хотя оставшиеся наборы идут в том же порядке. Удаленные наборы шифров следующие:

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)

Chrome отдает больший приоритет шифрам ChaCha, чем AES-CBC. Логика вполне понятна, учитывая, что режим CBC (cipher block chaining; сцепление блоков шифров) уязвим к атакам типа padding oracle. Скорее всего, полученный трафик прошел через HTTPS-перехватчик, не поддерживающий шифры ChaCha.

При помощи контекстуальных подсказок, как, например, используемых наборов шифров, а также дополнительного текста в User Agent, можно определить конкретный тип перехватчика. В этом случае MITMEngine сравнивает по сигнатурам, собранным антивирусом Sophos, и определяет, какое программное обеспечение, скорее всего, участвовало в перехвате.

Приветствуется любая помощь касаемо MITMEngine. Особенно нас интересует пополнение базы сигнатур разных MITM-приложений и Client-Hello сообщений браузеров, пересылаемых по протоколу TLS, поскольку вся логика работы MITMEngine по детектированию перехвата HTTPS-трафика основывается на работе с базой этих сигнатур. Сбор отпечатков происходит очень просто. Нужно открыть Wireshark, сформировать pcap-файл с Client-Hello сообщениями и отправить этот файл в запросе на изменение кода в репозитарии (pull request).

Статистика HTTPS-перехвата на базе трафика из сети Cloudflare

В дополнении к MITMEngine была создана информационная панель MALCOLM для наглядного отображения результатов анализа трафика, проходящего через сеть Cloudflare, на предмет HTTPS-перехвата. Недавно база отпечатков Client-Hello сообщений была пополнена, и читатели могут заметить сокращение «неизвестных» экземпляров, участвующих в HTTPS-перехвате с февраля по март 2019 года.

В этом разделе мы сравним статистку HTTPS-перехвата, полученную в MALCOLM с исследованием «The Security Impact of HTTPS Interception» от 2017 года. Таким образом, можно отследить, как изменилась ситуация на поприще перехвата HTTS-трафика, проходящего через сеть Cloudflare, за последние два года.

При помощи MALCOLM рассмотрим, как HTTPS-соединения перехватывались за последние время. Данные собраны между 12 и 13 марта 2019 года.

В исследование от 2017 выявлено, что было перехвачено 10.9% Client-Hello сообщений, проходящих через сеть Cloudflare. Исходя из текущих данных, количество перехватов значительно увеличилось (до 18.6%):

Однако полученный результат, скорее всего, завышен, по сравнению с результатами исследования от 2017 года. В той статье учитывался весь трафик, проходящий через Cloudflare, вне зависимости от того, был ли опознан User Agent или нет. В MALCOLM учитывается только тот трафик, когда User Agent был опознан и может быть идентифицирован посредством uasurfer, представляющим собой библиотеку для парсинга строк с User Agent. Если учитывать весь трафик, получается, что было перехвачено 11.3% запросов (увеличение на 0.4% по сравнению с 2017 годом). По результатам сравнения можно сделать вывод, что активность, связанная с перехватом HTTPS-трафика остается на том же уровне.

Затем мы сравнили HTTPS-перехват в разрезе по браузерам и операционным системам с целью выяснения, какие браузеры наиболее популярны и какие браузеры наиболее часто встречаются при перехвате. Статистика, собранная в 2017 году:

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

По сравнению с 2017 годом доля Chrome значительно увеличилась, а по Safari, IE (включая Edge) и Firefox снизилась. На диаграмме ниже показано распределение наиболее перехватываемых браузеров:

На рисунке выше видно, что Chrome находится в явных фаворитах вследствие роста общей популярности. В итоге процент перехвата по остальным браузерам (например, по Internet Explorer) снизился. Также при помощи MALCOLM выявлен еще один браузер, чей трафик перехватывается, а конкретно – UCBrowser. Этот браузер популярен в Китае.

Теперь посмотрим распределение операционных систем во всем трафике:

Видно, что за последние два года доля Android выросла, поскольку смартфоны стали использоваться намного чаще для доступа в интернет. Windows также остается популярной операционной системой.

Поскольку Android становится все более популярным, сильно выросла доля перехвата по устройствам, использующим эту операционную систему:

По сравнению с 2017 годом устройства на базе Android опередили системы на базе Windows по доле перехвата.

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

Заключение

При помощи MITMEngine и MALCOLM мы смогли непрерывно отслеживать тенденции, связанные с HTTPS-перехватом, на базе анализа 10% всего трафика в интернете. Крайне важно отслеживать эти тенденции для реализации новых мер безопасности и детектирования критических изменений в соответствующих протоколах. Отслеживание перехвата HTTPS-трафика помогает реализовать одну из наших основных миссий, связанной с «улучшением интернета», путем отслеживания приложений, возможно, негативно влияющих на хорошие практики безопасности.

Если вы заинтересовались темой перехвата HTTS-данных, рекомендуем следующее:

• Ознакомьтесь с информационной панелью MALCOLM. Пощелкайте по диаграммам и фильтрам. Расскажите о новых находках, которые вы обнаружили.

• Поэкспериментируйте с MITMEngine. Проанализируйте, влияет ли перехват HTTPS-трафика на TLS-соединения вашего сайта.

• По возможности принимайте участие в улучшении MITMEngine!