Способы перехвата данных по сети

О перехвате трафика: 4-10% зашифрованного HTTPS-трафика сегодня перехватывается

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

В этой статье мы рассмотрим, проблему перехвата зашифрованного веб-трафика и её влияние на онлайн-безопасность. Согласно исследованию, опубликованному в NDSS 2017, сегодня перехватывается от 4% до 10% HTTPS-трафика. Анализ перехватов показал, что хотя они не всегда приносят вред, но всё же средства перехвата зачастую ослабляют шифрование, используемое для обеспечения безопасности коммуникаций, что повышает риски для пользователей.

Как перехватывается шифрованный трафик?

Как показано на иллюстрации, трафик перехватывается с помощью «атаки посредника». Специальное ПО перенаправляет на себя шифрованное соединение и притворяется запрошенным сайтом. Затем перехватчик открывает новое шифрованное соединение с целевым сайтом и проксирует данные сквозь себя, между двумя соединениями, что делает перехват по большей части «невидимым». Поскольку перехватчик получает доступ к не зашифрованным данным в рамках соединения, то он может считывать, изменять и блокировать любой контент, передающийся или получаемый клиентом.

Есть два основных способа перехвата соединений: локальный и удалённый.

Локальный перехват: когда программа-перехватчик выполняется прямо на пользовательском компьютере, сетевой стек операционной системы модифицируется таким образом, чтобы перехватывать и перенаправлять соединения в перехватчика. Этот подход обычно используется антивирусным ПО для мониторинга сетевых подключений, чтобы идентифицировать зловредные скачивания и попытки зловредов похитить данные или внедрить рекламу.

Удалённый перехват: выполняется посредством вставки в сетевой путь мониторинга, соединяющего пользовательский компьютер с сайтом, к которому обращается пользователь. Например, это можно сделать с помощью перенаправления сетевого трафика на перехватчика посредством политик файрвола. Сетевой перехват обычно выполняется «блоками защиты» (security box), которые пытаются выявить атаки или мониторят утечки корпоративных данных из всех компьютеров в сети. Эти аппараты также зачастую используются для перехвата и анализа электронной почты.

Важный аспект перехвата — как приложения выдают себя за сайты, а пользовательские браузеры не замечают подмены. Обычно при установке HTTPS-соединения браузер подтверждает подлинность сайта, проверяя представленный на нём сертификат. Если сертификат не проходит проверку, то браузер выдаёт предупреждение, как на картинке выше, что соединение потенциально небезопасно. Поэтому «невозможность подделки» TLS-сертификатов является краеугольным камнем онлайн-безопасности. Это техническое средство, дающее нам уверенность, что мы общаемся с правильной стороной, а не с самозванцем.

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

Поэтому перехватчику проще всего подделывать сертификаты не через какую-то мудрёную криптографическую атаку, а посредством добавления собственного «корневого» сертификата в хранилище на компьютере. Тогда браузер будет доверять любому сертификату, подписанному перехватчиком. Это не является уязвимостью, потому что добавление сертификата, конечно, возможно только тогда, если у перехватчика есть доступ к файловой системе компьютера, или если сертификат установил сисадмин.

Насколько распространён перехват HTTPS?

Измерение количества перехватов — задача непростая, потому что перехватчики себя не рекламируют. Так что для регистрации фактов перехвата мы использовали усовершенствованную версию технологии сетевого «отпечатка пальца», известную как TLS fingerprinting. Это позволило нам определять, какое ПО осуществляет соединение (перехватчик или браузер). Технология оценивает конструкцию клиентского приветственного TLS-пакета (например, наборы шифров и TLS-опции) и сравнивает её с базой данных известных «отпечатков». Их надёжность очень высока, особенно по сравнению с user-agent’ом, рекламируемым в HTTP-запросе.

Исследователи оценивали работу большого интернет-магазина, сайта Cloudflare и серверы обновления Firefox. Оценивалось количество перехваченного их сервисами браузерного трафика. Важно иметь много «точек обзора», потому что результат меняется в зависимости от того, откуда смотреть. Например, в целом доля перехватываемых HTTPS-соединений варьируется от 4% до 10%. Это много, но важно помнить, что не все перехваты выполняются злоумышленниками.

Разбив по операционным системам трафик на Cloudflare и интернет-магазин выяснилось, что с Windows перехватывается гораздо чаще, чем с MacOS. Трафик с Android и iOS перехватывается значительно реже, чем с настольных ОС. Полное разбиение можно посмотреть на странице 13 нашего отчёта (ссылка в начале статьи).

Разбиение перехвата трафика обновления Firefox демонстрирует совсем другую картину. Чаще всего перехватом занимаются мобильные провайдеры. Отчасти это можно объяснить тем, что настольная версия Firefox использует отдельное хранилище для корневых SSL-сертификатов, что делает его менее вероятным кандидатом на перехват по сравнению с другими браузерами.

Кто и почему занимается перехватом на коммуникациях?

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

• Улучшение безопасности: антивирусы и некоторые корпоративные файрволы/IPS перехватывают трафик ради защиты своих пользователей. Они хотят проверять шифрованный трафик, стараясь предотвратить проникновение зловредов или мониторить утечку данных. Некоторое ПО для родителей и блокировщики рекламы используют аналогичный подход для блокирования трафика на определённые сайты.

• Активность злоумышленников: на другом конце спектра находится зловредное ПО, которое выполняет перехват ради внедрения рекламы или похищения конфиденциальных данных.

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

Как перехват HTTPS-трафика влияет на безопасность?

Если перехват выполняется не с корыстными целями, то почему вообще это может ослабить онлайн-безопасность?

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

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

Чтобы посчитать влияние HTTPS-перехватов на безопасность соединений исследователи проанализировали безопасность криптографических стеков, используемых перехватчиками. В целом у 65% перехваченных соединений на серверы обновления Firefox безопасность снижена, а 37% оказались легкоуязвимы к «атакам посредника» из-за вульгарных криптографических ошибок (например, сертификаты не валидированы) [65,7%+36,8%=102,5%, но так в оригинале — прим. переводчика]. Не сильно лучше оказалась ситуация с трафиком на Cloudflare.

Чтобы закончить на «позитивной» ноте, нужно упомянуть, что в редких случаях (4,1% у интернет-магазина и 14% у Cloudflare) перехват повышает безопасность соединений. Но это по большей части следствие ранжирования более слабых шифров (RC4 и 3DES).

В целом перехваты HTTPS распространены больше, чем ожидалось (4%—10%), и они влекут за собой серьёзные риски, поскольку ухудшают качество шифрования. Более того, используемые для перехвата реализации HTTPS не имеют тех же механизмов автоматического обновления, как в браузерах, что делает применение фиксов менее вероятным. Пассивные и перехватывающие промежуточные устройства тоже повлияли на задержанный релиз TLS 1.3 в браузерах.

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

Источник

Вскрытие трафика в публичных сетях

Эта статья о том, как стать кулхацкером (или по-английски Script Kiddie) — условным злоумышленником, который испытывает недостаток знаний в области программирования и использует существующее программное обеспечение, чтобы провести атаку на смартфоны и планшеты своих одноклассников.

Шучу. На самом деле передо мной стояла задача понять две вещи:

1. Насколько опасно пользоваться публичным WiFi в 2020 году, в мире где господствуют браузеры и сайты с повсеместно победившими технологиями HTTPS (на основе TLS 1.1+) и HSTS
2. Сможет ли человек моего уровня знаний (не самого высокого) “залезть” в чужой браузер и стащить ценные данные.

Отправная точка

Сразу скажу, что хотя часть моих опытов проводил в настоящих публичных сетях, “неправомерный доступ” я получал только к браузерам своих собственных устройств. Поэтому фактически Главу 28 УК РФ я не нарушал, и Вам настоятельно нарушать не советую. Данный эксперимент и статья предлагаются к ознакомлению исключительно в целях демонстрации небезопасности использования публичных беспроводных сетей.

Итак, в чем собственно проблема для хакера, если в трафик в открытых беспроводных сетях легко перехватить любым сниффером? Проблема в том, что в 2020 году почти все (99%) сайты используют HTTPS и шифруют весь обмен данными между сервером и браузером потенциальной “жертвы” индивидуальным ключом по довольно свежему протоколу TLS. TLS даёт возможность клиент-серверным приложениям осуществлять связь в сети таким образом, что нельзя производить прослушивание пакетов и осуществить несанкционированный доступ. Точнее прослушивать-то можно, но толка в этом нет, так как зашифрованный трафик без ключа для его расшифровки бесполезен.

Более того, во всех современных браузерах реализован механизм HSTS ( HTTP Strict Transport Security), принудительно активирующий защищённое соединение через протокол HTTPS и обрывающий простое HTTP-соединение. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение вместо использования HTTP-протокола. Механизм использует особый заголовок Strict-Transport-Security для принудительного использования браузером протокола HTTPS даже в случае перехода по ссылкам с явным указанием протокола HTTP (http://). Исходный вариант HSTS не защищает первое подключение пользователя к сайту, что оставляет лазейку для хакеров, и злоумышленник может легко перехватить первое подключение, если оно происходит по протоколу http. Поэтому для борьбы с этой проблемой большинство современных браузеров использует дополнительный статический список сайтов (HSTS preload list), требующих использования протокола https.

Чтобы как-то перехватить вводимые пароли или украсть cookies жертвы нужно как-то влезть в браузер жертвы или добиться, чтобы протокол шифрования TLS не использовался. Мы сделаем обе вещи сразу. Для этого мы применим метод атаки “человек посередине” (MitM). Оговорюсь, что наша атака будет довольно низкопробной, потому что мы будем использовать готовые “конструкторы-полуфабрикаты” из журнала “Хакни Сам” практически без какой-либо доработки. Настоящие хакеры вооружены более качественно, а мы только играем роль низкоквалифицированных кулхацкеров, чтобы проиллюстрировать степень небезопасности публичных современных беспроводных сетей.

Железо

В качестве инструментария для эксперимента я использовал следующий инструментарий:

• Любая публичная WiFi сеть на фудкорте
• Нетбук Acer Aspire one D270
• Встроенная wifi карта Atheros AR5B125
• Внешний wifi usb адаптер WiFi TP-LINK Archer T4U v3
• Внешний wifi usb адаптер TP-LINK Archer T9UH v2
• Kali Linux c версией ядра 5.8.0-kali2-amd64
• Фреймворк Bettercap v2.28
• Фреймворк BeEF 0.5
• Несколько смартфонов и планшетов на Android 9 и ноутбук на Windows 7 в качестве устройств-жертв.

Зачем так много wifi-карт? Да потому, что в процессе экспериментов я наступил на кучу граблей и пытался сэкономить. Оказалось, хорошая WiFi-карта — главный инструмент успешного злоумышленника. Тут целый ряд проблем: карта должна поддерживать мониторинг (monitor) и точки доступа (AP), для нее должны быть драйвера под вашу версию ядра Linux, у карты должна быть хорошая антенна и возможность управления мощностью сигнала. Если не хотите лишних граблей — берите дорогой адаптер из самого верха этого списка и не забудьте проверить наличие драйвера именно для вашей аппаратной ревизии карточки.

У встроенной карты Atheros AR9485 была великолепная поддержка всех режимов и драйвер “из коробки” в Kali, но невозможность управлять мощностью сигнала и слабая антенна сводили на нет эффективность данной карты на фазе активного вмешательства в трафик.

У WiFi TP-LINK Archer T4U v3 не было драйвера из коробки, а тот который я нашел на Github, не имел поддержки режима точки доступа (AP) и его нужно было компилировать самостоятельно.

Карточка TP-LINK Archer T9UH v2 заработала идеально с драйвером из коробки, на ней то у меня все и получилось.

Первым делом я установил Kali Linux 5.8.0 на свой ноутбук. Единственный SSD в ноутбуке был пустым и предназначался целиком для эксперимента, что избавило меня от некоторых трудностей с разбивкой разделов и резервным копированием старых данных с него, поэтому при установке я использовал все варианты “по умолчанию”. Я все же столкнулся некоторыми тривиальными проблемами вроде потери монтирования флешки с дистрибутивом в процессе установки и обновления системы до последней актуальной версии из репозитория.

Затем нужно было запустить инструменты проникновения, ими будут Bettercap и BeEF. С их помощью мы принудим браузеры “жертв” отказаться от шифрования трафика и внедрим в просматриваемые сайты троянский JavaScript.

Bettercap — это полный, модульный, портативный и легко расширяемый инструмент и фреймворк с диагностическими и наступательными функциями всех видов, которые могут понадобиться для выполнения атаки “человек посередине”. Bettercap написан на Go, основная разработка проекта проходила до 2019 года, сейчас происходят лишь небольшие исправления. Однако, как мы увидим позднее этот инструмент в быстро меняющемся мире информационной безопасности сохраняет свою актуальность и на закате 2020 года. Bettercap поставляется со встроенным модулями arp spoof и sslstrip. Именно Bettercap должен перехватывать трафик и внедрять в него вредоносную нагрузку.

SSlstrip — это специализированный прокси-сервер, который позволяет организовать один из способов обхода HTTPS для перехвата трафика — разбиение сессии пользователя на два участка… Первый участок от клиента до прокси сервера будет идти по протоколу HTTP, а второй участок, от прокси до сервера будет проходить, как и должен, по шифрованному соединению. SSLstrip позволяет разрезать сессию “жертвы” на две части и перехватить трафик для дальнейшего анализа, а также предоставлять автоматические редиректы на динамически создаваемые HTTP двойники страниц.

arp spoof перехватывает пакеты в локальной проводной или беспроводной сети с коммутацией. arpspoof перенаправляет пакеты от целевого хоста (или всех хостов) сети, предназначенные для другого хоста в этой сети, путём подмены ARP ответов. Это очень эффективный способ сниффинга трафика на коммутаторе или wifi-роутере.

BeEF — это фреймворк, позволяющий централизованно управлять пулом зараженных через XSS-атаку (сross-site scripting) клиентов, отдавать им команды и получать результат. “Злоумышленник” внедряет на уязвимый сайт скрипт hook.js. Скрипт hook.js из браузера “жертвы” сигналит управляющему центру на компьютере “злоумышленника” (BeEF) о том, что новый клиент онлайн. “Злоумышленник” входит в панель управления BeEF и удаленно управляет зараженными браузерами.

Я использовал версии Bettercap v2.28 и BeEF 0.5 Они оба уже есть в составе Kali Linux 5.8.0
Открываем окно командной строки и вводим команду

Стартует первая часть нашего зловредного бутерброда — фреймворк BeEF.

Теперь запустим браузер (в Kali Linux обычно это Firefox), переходим по адресу http://127.0.0.1:3000/ui/panel, логин и пароль по умолчанию beef:beef, после чего мы попадаем в контрольный пункт управления нашей атаки.

Оставляем вкладку с BeEF открытой, мы в нее вернемся позже.

Перейдем к второй части бутерброда — Bettercap. Тут был подводный камень — Bettercap, уже имевшийся в системе, отказывался стартовать сервисом и выдавал другие непонятные мне ошибки. Поэтому я его решил удалить и поставить заново вручную. Открываем окно командной строки и выполняем команды:

Затем скачиваем браузером бинарную версию Bettercap v2.28 в архиве в папку загрузки. Обратите внимание, что я выбрал версию для своей архитектуры ядра.

Теперь распаковываем и размещаем исполняемый файл в системе Bettercap в папку, предназначенную для ручной установки.

Самый простой способ начать работу с Bettercap — использовать его официальный веб-интерфейс пользователя. Веб-интерфейс работает одновременно с сервисом rest API и интерактивной сессией командной строки. Чтобы установить веб-интерфейс нужно выполнить команду:

Внимание! Уже на этом этапе нужно обязательно подключиться к атакуемой беспроводной сети, получить ip-адрес для беспроводного интерфейса атакующей машины и запомнить его (команда ifconfig поможет его узнать).

Bettercap понимает как отдельные команды из командной строки так и каплеты. Каплет — это просто текстовый файл со списком команд, которые будут выполнены последовательно. Для запуска веб-интерфейса используется http-ui caplet. Посмотреть и изменить учетные данные по умолчанию в нем можно по пути /usr/local/share/bettercap/caplets/http-ui.cap. Запуск Bettercap с веб интерфейсом модулями api.rest и http.server 127.0.0.1 производится командой

Теперь можно открыть в браузере еще одну вкладку с адресом 127.0.0.1 (без номера порта!) и войти в систему, используя учетные данные, которые были подсмотрены или настроены на предыдущем шаге (обычно это user/pass).

Веб-интерфейс Bettercap полностью дублирует командную строку, поэтому все действия которые мы будем делать из командной строки, можно сделать и из веб-интерфейса (запуск модулей, смена режимов, просмотр изменение значение переменных, вывод диагностической информации)

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

net.recon on — Запускает обнаружение сетевых хостов.
net.probe on — Запускает активное зондирование новых хостов в сети через отправку фиктивных пакетов каждому возможному IP в подсети.
net.show — Даёт команду отобразить список кэша обнаруженных хостов.
net.probe off — Выключает модуль активного зондирования.
Настраиваем переменные Bettercap, чтобы он:

• работал как прозрачный прокси (transparent proxy) и “отключал” шифрование браузерного обмена “жертв” модулем sslstrip,
• внедрял им вредоносную нагрузку (http://192.168.0.103/hook.js — скрипт BeEF, используйте IP, выданный роутером вашему адаптеру в атакуемой сети),
• обходил механизм HTST методом замены адреса в адресной строке браузера жертвы на похожие интернационализированные символы.

Команды:

Затем запускаем атаку против пользователей беспроводной сети:
Команды

arp.spoof on — Запускает отравление ARP кеша устройств “жертв”, этот модуль перенаправлять трафик на беспроводной интерфейс “злоумышленника”
http.proxy on — Запускает прозрачный прокси, этот модуль создает прокси сервер, который будет ловить весь переадресованный трафик и модифицировать его в интересах “злоумышленника”.
“Жертвы” начинают пользоваться интернетом, заходить на сайты, и в случае успеха атаки будут лишены транспортного шифрования (а значит станут доступны для прямого прослушивания любым сниффером) и будут получать себе вредоносный скрипт BeEF. Скрипт BeEF, выполнялась в контексте домена, в чью страницу он был внедрен, может выполнить много разных действий, например утащить cookies или украсть вводимые пароли.

Как и положено наспех сделанному бутерброду, атака сработает далеко не на все сайты. Например, крайне маловероятно провернуть атаку с одним из сайтов Google, так как в браузере уже есть список HSTS preload list для некоторых сайтов. Но вот “хайджекнуть” Рамблер или Coub.com оказалось вполне возможно! Если мы попросим “жертву” (социальная инженерия, куда ж без нее) открыть адрес Ro.ru, или вдруг она сама это сделает, то произойдет вот что:

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

А на машине “злоумышленника” в контрольной панели фреймворка BeEF, в разделе Online Browsers тем временем появится запись о новом браузере, пойманном на крючок. Выбираем этот браузер мышью, переходим в суб-вкладку Commands, на каталог Browsers, потом последовательно Hooked domain → Get Cookie → Execute

Раз, и парой парой кликов мышки мы украли у жертвы сессионные cookies сайта Rambler.ru. Теперь мы можем попытаться вставить их в свой браузер и попасть в сессию жертвы. И это только вершки! А ведь в арсенале BeEF еще несколько сотен различных “команд”, которые мы можем отправить “пойманному” браузеру: различные варианты фишинга, кража паролей, рикролы, редиректы, эксплоиты…

Выводы

Выводы по результатам эксперимента неутешительные. Браузеры еще не могут на 100% защитить пользователей от вмешательства в трафик или подмены настоящего сайта фишинговым. Механизм HSTS срабатывает только для пары тысяч самых популярных сайтов и оставляет без надежной защиты миллионы других. Браузеры недостадочно явно предупреждают о том, что соединение с сервером не зашифровано. Еще хуже дело обстоит в беспроводных сетях, где доступ к среде передачи данных есть у любого желающего, при этом почти никто из пользователей вообще никак не проверяет подлинность самой точки доступа, а надежных методов проверки подлинности точек доступа просто не существует.

Источник