Традиционно, браузеры включают в себя утилиты для проверки сертификатов, выданных веб-сайтами, что позволяет им убедиться в их подлинности.
В идеале решения безопасности должны быть полностью прозрачны: они не должны устанавливать какой-либо тип сертификата и не использовать техники перехвата (например, man-in-the-middle через TLS-прокси) для анализа соединений пользователей. Благодаря этому можно избежать инцидентов, связанных с различными соответствующими уязвимостями, сводя к минимуму влияние на производительность соединения для устройств.
Однако не все антивирусные системы являются тем, чем они кажутся, и многие из них часто являются более опасными, нежели полезными для кибер-безопасности пользователей, что было заявлено в недавнем исследовании Университета Конкордия (Монреаль, Канада). Его авторы пришли к выводу, что в наши дни многие антивирусы снижают порог безопасности интернет-браузера.
Для фильтрации трафика, защищенного протоколами SSL/TLS, некоторые антивирусы и приложения родительского контроля помещают TLS-прокси между узлами связи клиента.
В исследовании была изучена работа данных прокси, т.к. существуют известные проблемы в других, более зрелых, движках по обработке TLS-трафика (например, браузеры или общие TLS-библиотеки). В сравнении со стандартными прокси, клиентские TLS-прокси вводят свои уникальные ограничения, а потому должны быть проанализированы на дополнительные направления атак: в частности, прокси могут доверять свои собственные корневые сертификаты внешнему контенту и использовать собственное хранилище доверительных центров сертификаций (минуя хранилища операционной системы и браузера).
Охватывая существующие и новые направления атак, исследователями была создана комплексная система для анализа таких клиентских TLS-прокси. Используя эту систему, авторы исследования произвели тщательный анализ восьми антивирусных программ и четырех приложений родительского контроля для ОС Windows, которые выполняют функцию TLS-прокси, наряду с двумя дополнительными продуктами, которые только импортируют корневой сертификат.
Системный анализ позволил обнаружить, что некоторые из тестируемых продуктов оказывают негативное воздействие на защиту TLS-соединения. В частности, обнаружено, что четыре продукта являются уязвимыми при атаке с перехватом сообщений и подменой ключей в рамках атаки man-in-the-middle (MITM) и еще два — при включении TLS-фильтрации. Некоторые из этих продуктов также обманывают браузеры, которые в результате этого считают, что TLS-соединение является более безопасным, чем есть на самом деле, например, искусственно обновляя версию TLS на сервере клиента.
Исследование было выполнено для определения новых рисков, добавляемых инструментами перехвата TLS-соединений, которое, возможно, используются миллионами пользователей.
Рисунок 1. Иллюстрация MITM-атаки против приложения по контролю контента, в рамках которой осуществляется перехват TLS, в результате чего разрешается собственный корневой сертификат якобы эмитента внешних сертификатов. Кроме того, параметры TLS не являются прозрачными для браузеров, а потому они могут быть понижены прокси до нежелательного уровня. Все показанные версии SSL/TLS являются наивысшими, которые могут использоваться между узлами соединения, учитывая, что MITM поддерживает TLS 1.2.
В таблице ниже приведен список протестированных в рамках исследования продуктов. Позиции, выделенные жирным шрифтом,– это продукты, которые могут установить корневой сертификат и прокси TLS-соединений. Именно эти продукты и были проанализированы исследователями.
В результате, те антивирусные системы, которые в исследовании отмечены как уязвимые, потенциально могут привести к обману браузеров, которые будут доверять любому сертификату, даже если они не должны ему доверять.
Более подробную информацию о методике и результатах проведения исследования специалистов Университета Конкордия смотрите здесь.
Поделиться с друзьями
Комментарии (17)
Saffron
17.05.2016 20:36Понапроверяли всякой малораспространённой чуши, а обычный сквид не проверили, обидно.
teecat
18.05.2016 13:26Они проверяли влияние установки антивирусов на защиту десктопов. Сквид тут совсем не причем. Во первых для сквида антивирус это плагин, тоесть антивирус перехватом трафика не занимается и уязвимостей не вносит. А во вторых с точки зрения проверки файлов сквид весьма не оптимален
Saffron
18.05.2016 16:07Вот не надо путать тёплое и мягкое. Они проверяли корректность реализации конкретно одной фичи — перехвата https трафика через прокси. Это очень узкий аспект и имеет слабое влияние на защиту десктопов в целом. А сквид точно также имеет возможность перехватывать https. А антивирусный плагин для него рассматривать не зачем, когда исследуется безопасность реализации перехвата https.
feyd12
21.05.2016 14:11Могли тогда и решения от чекпоинт тоже проверить или Palo Alto. Всего не охватишь, имхо.
teecat
Хорошо, тогда вопрос — ваши предложения как перехватывать защищенные соединения которые используют вирусы для подгрузки компонентов или как находить вредоносные скрипты в скачивании с сайта по защищенному протоколу (который сейчас суют все кому не лень)
Угроза, описанная в статье, явно преувеличена. Любое ПО уязвимо, но задачу перехвата трафика нужно решать и решить ее без перехвата трафика нельзя никак
Frankenstine
Зачем перехватывать? Можно же анализировать уже конечные файлы и скрипты, расшифрованные. Если браузер может выполнить скрипт — значит антивирус может его проанализировать, установив дополнение в браузер. Так поступают многие антивирусы.
teecat
Так нельзя. Файл должен проверяться до получения клиентским приложением:
1. получаемый файл может быть рассчитан на эксплуатацию неизвестной уязвимости и отработает не дойдя до плагина
2. браузером, ридером и почтовыми клиентами список программ, работающих с инетом не исчерпывается. Предположим есть у вас плагин — а толку, если запустившийся троян в роли дроппера установил защищенный канал со своим сервером.
3. плагин слишком легко вынести — шаловливыми руками клиента или самим трояном средствами приложения, неконтролируемыми естественно самозащитой антивируса
4. плагин внезапно может стать несовместимым по причине обновления программы для которой он создан.
Именно поэтому нужно перехватывать все соединения до клиентских приложений. Плагины нужны только для обработки проприетарных протоколов типа МАПИ
Frankenstine
1, 2 — файл будет записан на диск и тут же антивирус (если не слоупок) должен его словить. Запуск исполнимых файлов невозможен без записи их на диск.
3 — антивирус «слишком легко вынести — шаловливыми руками клиента или самим трояном средствами приложения» — чем это отличается от отдельно взятого плагина?
4 — расскажите это разработчикам Avast, Avira, Trend Micro, Bitdefender, Kaspersky Antivirus, DrWeb, 360 Total Security,…
Другое дело что в общем-то это так же плохо, как перехватывать трафик.
teecat
1/2. — совершенно не обязательно. пример — руткиты. записи на диск нет
3. плагин, не антивирус. Антивирус (драйвер перехвата трафика) как раз сложно вынести ибо он защищен системой самозащиты
4. как сотрудник Доктора Веб как бы периодически наблюдаю
Frankenstine
Эм, что за дичь вы тут городите? Руткиты сначала нужно записать на диск, чтобы запустить. Из астрала программы не выполняются. Может вы хотели сказать эксплойты? Защита от неизвестных эксплойтов так же невозможна практически, иначе бы уже давно они потеряли актуальность.
Система самозащиты может контролировать любые файлы и ветки реестра, а так же области памяти, никто не запрещает.
teecat
1. Бестелесные вредоносные программы, а в древности бестелесные черви. Редкий зверь. Подсказывают в качестве примера WMIGhost
2. защита от неизвестных эксплойтов возможна. Dr.Web Security Space/Dr.Web Katana содержат систему контроля процессов изнутри. Предназначено именно для защиты от эксплойтов
teecat
И если на русском (http://www.kaspersky.ru/about/news/virus/2012/Bestelesnyj_bot_atakuet_posetitelej_novostnyh_resursov): «в отличие от стандартных drive-by атак вредоносная программа не загружалась на жесткий диск, а функционировала исключительно в оперативной памяти компьютера»
Frankenstine
WMIGhost заражает систему из dll файла, который легко обнаружить антивирусом.
«Бестелесный бот» на самом деле эксплойт, который загружает на диск трояна Lurk чтобы что-то сделать. Без этого он способен только отключить UAC (для установки трояна, собственно). При наличии файлового антивируса обе угрозы бесполезны.
И дайте-ка статистику защиты Dr.Web от 0-day эксплойтов.
teecat
Мы с вами спорим по терминологии. Даже из вашего ответа получается, что есть компоненты вредоносных программ, которые могут быть бестелесными. Пусть даже эксплойты. А значит нужен контроль за тем, что передается и получается, но не осаживается на диск. Ибо это сможет быть дроппер — наиболее редко папапающая вендорам часть вредоносного комплекса
Frankenstine
Дык защита от эксплойтов — патчи для софта. А в защиту от 0-day эксплойтов софтом я не верю. Есть какая-нибудь статистика отлова/ложноположительных неизвестных эксплойтов?
teecat
Ну верить или не верить — вопрос миросознания. Статистики точной именно по перехвату эксплойтов у меня на руках нет, но пока нареканий на шелгард я не видел по качеству его работы
feyd12
Про скрипты в браузерах согласен, нужно проверять. Другое дело, что можно работать конкретно с браузером, а не вторгаться в SSL, пути есть, имхо. А от про подгрузку компонентов малварью — не вижу смысла. Во-первых, защищенный канал может реализоваться как угодно, а не только через SSL и по любому транспортному протоколу и порту. Во-вторых, если внутри SSL будет использоваться дополнительное шифрование данных, то MITM антивируса ничем не поможет пользователю, имхо.
А вот отсутствие возможности проверить цепочку сертификатов для доступа к ресурсу с критически важным содержимым считаю серьезной проблемой.