Инструкция по Ettercap: атака человек-посередине (MitM), перехват паролей, обход HSTS, подмена данных на лету, использование пользовательских фильтров и плагинов, подцепление на BeEF, заражение бэкдорами. Перехват данных из SSL-соединения (читаем почту юз

Покажу и расскажу как с помощью утилиты sslstrip перехватить данные которые передаются по защищенному SSL-соединению.
Утилитка sslstrip в моем примере (после проведения атаки типа ARP-spoofing на жертву) перехватит запрос веб-клиента жертвы на установление защищенного SSL-соединения и заставит его использовать незащищенныый протокол HTTP. Далее я просто подсмотрю то, что делает жертва, не обратившая внимание на то, что она читает почту не по HTTPS, а по HTTP.

Вы убедитесь в том как просто можно организовать атаки типа MITM на SSL путем техник arp-spoof и проги sslstrip.

В моем примере жертва - виртуалка с ИПом 10.10.11.163 (обычная тачка с виндой), ПК с которого я атакую - 10.10.11.85 с установленной ОС Kali и с sslstrip (эта утилита предустановлена в пентестерских дистрибутивах Kali\BackTrack Linux). Между нами шлюз с ИПом 10.10.11.1.

1. При заходе жертвы на gmail.com ее кидает на адрес https://gmail.com и это нормально. Естественно, пароли и логины к почте жертвы мы в открытом виде не видим.

2. Включаю маршрутизацию трафика на ПК с Кали:

echo "1" > /proc/sys/net/ipv4/ip_forward

и настраиваю iptables таким образом, чтобы весь http-трафик направлялся на порт 81:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 81

arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

теперь трафик жертвы ходит через мою тачку и (согласно моего правила iptables) форвардится на 81 порт.

3. Запускаю sslstrip

sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

это создаст файлик лога прямо на рабочем столе и начнет писать в него перехваченный http-трафик (собственно, перехватываться-то будет HTTPS, но он будет strip"аться). Ну вобщем, запускаю на консоли смотрение этого файлика:

tail -f /root/Desktop/ssllog.txt

4. Жертва идет на свою почту

Для чтения почты жертва как всегда лезет в MS Explorer (хехе) и вводит там gmail.com. Но браузер почему-то не перекидывает жертву на https (в адресной строке http)! На рисунке ниже изображено то что увидит жертва в последний миг перед тем, как я узнаю ее пароль и логин.

Жертва жмакает "Войти"...а на моем окошке, куда выводился перехваченный трафик я вижу следующее:

Как видно, пароль 1q2w3e4r5t6y ...

Чтобы избежать угроз, связанных с перехватом начала SSL-соединения, надо:
- не юзать гаджеты в недоверенных сетях, даже если это очень надо (злодей может устроить MITM с гораздо бОльшей вероятностью, скажем, в аэропорту путем установки rogue wireless access point, чем ломанув корпоративную сеть вашей организации);
- шифровать почту симметричными протоколами шифрования (пишу и думаю о PGP);
- платить нормальную зарплату админу чтоб у него не возникало желания шпионить за вашими сотрудниками таким образом;
- следить за ARP-таблицей и юзать оборудование/софт, которое отслеживает подбные атаки;
- регулярно обновлять ПО из доверенных легальных источников.

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

Среди задач информационной безопасности всё важнее и важнее становится борьба с утечками конфиденциальных сведений. Согласно открытым источникам, за прошедший 2016 год количество утечек увеличилось на 86%, причём с этой проблемой столкнулись 47% российских компаний самого разного профиля. Данная проблема решается с помощью систем класса DLP (Data Loss Prevention). В статье рассматривается реализация одного из модулей такой системы, обеспечивающего мониторинг SSL/TLS-трафика путём перехвата системных функций Windows.

Борьба с утечками важной информации требует мониторинга сетевого траффика. Это подразумевает анализ всех данных, передаваемых по сети самыми различными способами, в том числе и данных, передаваемых в зашифрованном виде по SSL/TLS протоколу.

Перехват данных, передаваемых по протоколу SSL/TLS, возможен с помощью атаки типа «человека посредине» (man-in-the-midle, или сокращённо MITM). Для этого система мониторинга выступает в качестве посредника между клиентом и сервером. Вся информация от клиента сначала попадает посреднику (т.е. системе мониторинга), а затем переправляется серверу. И наоборот, вся информация от сервера сначала попадает посреднику, а затем переправляется клиенту.

Рис 1. Атака типа «человек посредине»

Простейший способ «внедрения» посредника основан на использовании промежуточного сервера (proxy-сервера). В этом случае клиент и сервер не взаимодействуют напрямую. Клиент отправляет все запросы промежуточному серверу, который переправляет их уже реальному серверу. Аналогично, реальный сервер отправляет ответы промежуточному серверу, который пересылает их клиенту.

Если данные передаются с использованием SSL/TLS, то оба соединения (и от клиента к промежуточному серверу, и от промежуточного сервера к реальному серверу) являются защищёнными. В обоих соединениях используется свой собственный сертификат и свой собственный закрытый ключ. Промежуточный сервер обладает закрытыми ключами для обоих соединений и осуществляет «перешифрацию» данных: принимает зашифрованные данные, дешифрует их, шифрует с помощью другого закрытого ключа и, наконец, отправляет дальше. Таким образом, промежуточный сервер располагает всеми передаваемыми данными в незашифрованном виде.

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

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

Рис 2. Атака типа «человек посредине» с помощью библиотеки-посредника, перехватывающей системные функции

Запуск системы мониторинга SSL/TLS траффика происходит с помощью трёх простых шагов:
1. Подключение к указанному клиентскому процессу (используются стандартные возможности ОС).
2. Подгрузка динамической библиотеки-посредника, в которой реализованы собственные функции сетевого взаимодействия.
3. Настройка перехвата функций сетевого взаимодействия таким образом, чтобы при вызове этих функции происходило обращение не к системным функциям, а к функциям, реализованным в подгруженной библиотеке.

Библиотека-посредник обладает теми же возможностями, что и промежуточный сервер. Так, вся информация от клиентского приложения сначала попадает библиотеке-посреднику, а затем переправляется реальному серверу. И наоборот, вся информация от реального сервера сначала попадает библиотеке-посреднику, а затем переправляется приложению.

Рис 3. Перехват данных библиотекой-посредником

Для взаимодействия с сервером библиотека-посредник использует стандартные системные функции и механизмы. Если информация передаётся с помощью SSL/TLS, то используется защищённое соединение, которое устанавливается библиотекой-посредником. После установки соединения библиотека-посредник «знает» закрытый ключ, используемый для шифрации/дешифрации данных.

Взаимодействие с клиентским приложением происходит несколько иным способом. Библиотека-посредник получает управление, когда клиентское приложение вызывает некоторую функцию сетевого взаимодействия. Если вызываемая функция имеет входные аргументы, то библиотека-посредник получает значения этих аргументов. Далее, библиотека-посредник «эмулирует» работу этой функции и, если функция имеет выходные аргументы, то библиотека-посредник формирует значения этих аргументов. Такая логика распространяется на абсолютно все перехватываемые функции, в том числе функции установки соединения, передачи данных и получения ответов сервера.

Библиотека-посредник одновременно взаимодействует и с клиентским приложением, и с удалённым сервером. Логика работы зависит от действий, выполняемых клиентским приложением:

1. Установка нового сетевого соединения происходит следующим образом:
- приложение вызывает необходимую системную функцию;
- вызов передаётся библиотеке-посреднику;
- библиотека-посредник устанавливает соединение с сервером, при этом самостоятельно выполняет все действия, предусмотренные протоколом SSL/TLS: проверку сертификата сервера, отправку собственного сертификата, «рукопожатие», генерацию закрытого ключа и т.д.
- библиотека-посредник возвращает управление приложению;
- приложение выполняет все действия, необходимые для установки соединения по протоколу SSL/TLS, вызывая функции сетевого взаимодействия. Библиотека-посредник перехватывает все эти вызовы, но не делает никаких обращений к реальному серверу, а самостоятельно «отвечает» приложению. С точки зрения приложения всё выглядит так, как будто происходит взаимодействие с реальным сервером (в т.ч. «рукопожатие» и генерация закрытого ключа).
В результате проделанных действий библиотека-посредник располагает сразу двумя закрытыми ключами протокола SSL/TLS. Один ключ используется для взаимодействия с приложением, другой – сервером.

2. Для передачи данных серверу приложение вызывает системную функцию. На вход функции передаются уже зашифрованные данные. Библиотека-посредник перехватывает этот вызов и делает следующее:
- дешифрует передаваемые данные с помощью закрытого ключа, полученного при установке соединения с приложением;
- шифрует полученные данные с помощью закрытого ключа, полученного при установке соединения с сервером;
- отправляет зашифрованные данные на сервер.

3. Получение данных от сервера происходит похожим образом, но в обратном порядке. Приложение вызывает функцию получения данных, а библиотека-посредник перехватывает этот вызов и делает следующее:
- получает порцию данных от сервера;
- дешифрует полученные данные с помощью закрытого ключа, полученного при установке соединения с сервером;
- шифрует полученные данные с помощью закрытого ключа, полученного при установке соединения с приложением;
- возвращает шифрованные данные (или их часть) как результат работы функции.

4. При разрыве соединения приложение вызывает соответствующую функцию. Библиотека-посредник перехватывает этот вызов, разрывает соединение с сервером, удаляет свои внутренние структуры и возвращает управление приложению.

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

Более серьёзная проблема состоит в том, что наличие библиотеки-посредника может быть заметно для опытного пользователя. Библиотека-посредник «отвечает» приложению от имени сервера, но при этом использует собственный самоподписанный сертификат. Многие клиентские приложения (например, интернет-браузеры) корректно работают с самоподписанным сертификатом сервера, но всегда позволяют его просмотреть. Если пользователь видит самоподписанный сертификат, не имеющий никакого отношения к реальному серверу, то пользовать может заподозрить о наличии посредника.

В целом, предложенный способ мониторинга TLS/SSL траффика крайне эффективен по нескольким причинам. Во-первых, библиотека выступает в качестве полноценного посредника между приложением и сервером. Она полностью контролирует и всю сетевую активность приложения, и все отправляемые/принимаемые данные. Во-вторых, внедрение библиотеки-посредника не требует значительных системных ресурсов. Наконец, наличие библиотеки-посредника заметно только для опытного пользователя.

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

Система позволяет вручную устанавливать определенные сертификаты для подмены при перехвате сессий соответствующих серверов (сайтов, программ) путем привязки сертификата к серверу.

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

Для настройки перехвата SSL-трафика:

В окне вкладки Профиль настроек агента в зоне редактирования профиля выберите вкладку Контроль сетевого трафика .
Нажмите кнопку Параметры перехвата SSL и следуйте рекомендациям текущего параграфа.

Выбор режима подмены SSL-сертификата

В окне настроек выберите приемлемый режим перехвата:

Для автоматической генерации агентом корневого SSL-сертификата при установке на компьютер пользователя, выберите опцию Автоматический режим . Созданный корневой сертификат будет помещен в базу доверенных создателей сертификатов и автоматически использоваться агентом для последующей выдачи дочерних сертификатов, подписанных по умолчанию именем издателя Falcongaze SecureTower .

Для смены имени издателя сертификата, которое будет указано в сведениях о безопасности соединения, задайте нужное имя в поле Имя в SSL- сертификате .

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

В открывшемся окне нажмите кнопку Добавить сертификат и укажите файлы сертификата и ключа одним из предложенных ниже способов:

Для генерации нового сертификата нажмите кнопку Сгенерировать сертификат . Введите в открывшемся окне имя нового сертификата, время его действия и укажите пути, по которым будут храниться вновь созданные файлы сертификата(*.cer) и закрытого ключа(*.pvk). Нажмите кнопку Сгенерировать .

Если требуется добавить сертификат, ранее сгенерированный в формате PFX, нажмите кнопку Конвертировать из сертификата в формате PFX . Укажите путь и пароль к файлу сертификата в формате PFX, а также путь к файлам сертификата(*.cer) и закрытого ключа(*.pvk), в которые требуется конвертировать исходный файл. Нажмите кнопку Конвертировать для завершения конвертации.

Нажмите Далее в окне Добавление пользовательских сертификатов для продолжения процедуры добавления. В открывшемся окне введите уникальное имя, которым будет подписан добавляемый сертификат, и комментарий (опционально).

Нажмите Готово для завершения процесса. Сертификат будет добавлен в базу пользовательских сертификатов системы SecureTower. Нажмите OK для завершения добавления. Добавленный пользовательский сертификат будет автоматически помещен агентом в базу доверенных создателей (если этого не было сделано администратором сети предварительно) и далее будет использован для выдачи дочерних сертификатов.

Примечание.

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

Привязка SSL-сертификата к серверу

Для определения соответствия "сервер-сертификат" нажмите кнопку Привязки сертификатов и следуйте рекомендациям, приведенным далее:

Для привязки к определенному серверу корневого сертификата на вкладке Корневые сертификаты , нажмите кнопку Добавить сертификат для сайта . Введите имя хоста (доменное имя), на которое будут выданы дочерние сертификаты и к которому будет привязан корневой сертификат, в поле Имя хоста (IP-адрес). Выберите один из предустановленных корневых сертификатов в раскрывающемся списке поля Корневой сертификат либо нажмите кнопку Пользовательские сертификаты для добавления и указания файлов сертификата и закрытого ключа на компьютере пользователя.
Для привязки к определенному серверу уже имеющегося сертификата, выберите вкладку Пользовательские сертификаты . Агент не будет генерировать для указанных в данной вкладке серверов новые дочерние сертификаты, а будет использовать для процедур подмены сертификаты, заданные пользователем. В открывшемся окне в поле Имя хоста (IP-адрес) введите имя хоста (доменное имя), к которому будет привязан сертификат. Выберите один из сертификатов в раскрывающемся списке поля Сертификат : (если сертификаты уже добавлялись ранее) либо нажмите кнопку Пользовательские сертификаты для выбора пользовательских сертификатов из списка либо добавления и указания файлов сертификата и закрытого ключа на компьютере пользователя.

Примечание.

Для заполнения поля Имя хоста (IP-адрес) допускается использование IP - адреса хоста, но только в случаях, когда имя хоста не было определено при соединении и известен только IP - адрес.

Исключение серверов из перехвата шифрованного трафика

Для работы с исключениями из процесса подмены сертификатов, нажмите кнопку Исключения SSL - серверов .

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

В поле ввода открывшегося диалогового окна введите имя сервера (хоста) (например, accounts.google.com) с учетом регистра и нажмите кнопку Добавить . Система позволяет использовать введение имен по маске (разрешены символы? и *, например, использование *.microsoft.* позволит избежать дублирования ресурсов Microsoft в списке исключений) для исключения ресурсов одного семейства. Введенное имя появится в списке исключений.

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

Для совершения прочих операций с исключениями следуйте соответствующим рекомендациям параграфа

Многие пользователи и не догадываются, что заполняя логин и пароль при регистрации или авторизации на закрытом Интернет-ресурсе и нажимая ENTER, эти данные легко могут перехватить. Очень часто они передаются по сети не в защищенном виде. Поэтому если сайт, на котором вы пытаетесь авторизоваться, использует HTTP протокол, то очень просто выполнить захват этого трафика, проанализировать его с помощью Wireshark и далее с помощью специальных фильтров и программ найти и расшифровать пароль.

Лучшее место для перехвата паролей - ядро сети, где ходит трафик всех пользователей к закрытым ресурсам (например, почта) или перед маршрутизатором для выхода в Интернет, при регистрациях на внешних ресурсах. Настраиваем зеркало и мы готовы почувствовать себя хакером.

Шаг 1. Устанавливаем и запускаем Wireshark для захвата трафика

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

Захват трафика начался.

Шаг 2. Фильтрация захваченного POST трафика

Открываем браузер и пытаемся авторизоваться на каком-либо ресурсе с помощью логина и пароля. По завершению процесса авторизации и открытия сайта мы останавливаем захват трафика в Wireshark. Далее открываем анализатор протоколов и видим большое количество пакетов. Именно на этом этапе большинство ИТ-специалистов сдаются, так как не знают, что делать дальше. Но мы знаем и нас интересуют конкретные пакеты, которые содержат POST данные, которые формируются на нашей локальной машине при заполнении формы на экране и отправляются на удаленные сервер при нажатии кнопки «Вход» или «Авторизация» в браузере.

Вводим в окне специальный фильтр для отображения захваченных пакетов: http. request. method == “ POST”

И видим вместо тысячи пакетов, всего один с искомыми нами данными.

Шаг 3. Находим логин и пароль пользователя

Быстрый клик правой кнопки мыши и выбираем из меню пункт Follow TCP Steam

После этого в новом окне появится текст, который в коде восстанавливает содержимое страницы. Найдем поля «password» и «user», которые соответствуют паролю и имени пользователя. В некоторых случаях оба поля будут легко читаемы и даже не зашифрованы, но если мы пытаемся захватить трафик при обращении к очень известным ресурсам типа: Mail.ru, Facebook, Вконтакте и т.д., то пароль будет закодирован:

HTTP/1.1 302 Found

Server: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Set-Cookie: password=; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/

Location: loggedin.php

Content-Length: 0

Connection: close

Content-Type: text/html; charset=UTF-8

Таким образом, в нашем случае:

Имя пользователя: networkguru

Пароль:

Шаг 4. Определение типа кодирования для расшифровки пароля

Заходим, например, на сайт http://www.onlinehashcrack.com/hash-identification.php#res и вводим наш пароль в окно для идентификации. Мне выдан был список протоколов кодирования в порядке приоритета:

Шаг 5. Расшифровка пароля пользователя

На данном этапе можем воспользоваться утилитой hashcat:

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

На выходе мы получили расшифрованным пароль: simplepassword

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

Протокол POP и фильтр выглядит следующим образом: pop.request.command == "USER" || pop.request.command == "PASS"
Протокол IMAP и фильтр будет: imap.request contains "login"
Протокол SMTP и потребуется ввод следующего фильтра: smtp.req.command == "AUTH"

и более серьезные утилиты для расшифровки протокола кодирования.

Шаг 6. Что делать, если трафик зашифрован и используется HTTPS?

Для ответа на этот вопрос есть несколько вариантов.

Вариант 1. Подключиться в разрыв соединения между пользователем и сервером и захватить трафик в момент установления соединения (SSL Handshake). В момент установки соединения можно перехватить сеансовый ключ.

Вариант 2. Вы можете расшифровать трафик HTTPS, используя файл журнала сеансовых ключей, записываемый Firefox или Chrome. Для этого браузер должен быть настроен на запись этих ключей шифрования в файл журнала (пример на базе FireFox), и вы должны получить этот файл журнала. По сути, необходимо похитить файл с ключом сессии с жесткого диска другого пользователя (что является незаконным). Ну а далее захватить трафик и применить полученный ключ для его расшифровки.

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

После получения ключей по варианту 1 или 2 необходимо прописать их в WireShark:

Идем в меню Edit - Preferences - Protocols - SSL.
Ставим флаг «Reassemble SSL records spanning multiple TCP segments».
«RSA keys list» и нажимаем Edit.
Вводим данные во все поля и прописываем путь в файлу с ключом

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

В силу важности этой проблематики в рамках серии публикаций сайт предлагает обзор безопасности стэка протоколов TLS/SSL, параллельно рассмотрев последовательные и систематические стратегии ослабления этих протоколов со стороны спецслужб.

Треть защищённого трафика в мире сгенерировано криптографическими средствами с заведомо ослабленным ГПСЧ?

Снятые с канала

В качестве затравки обратимся к российскому примеру — последнему судебному заседанию по делу бывшего владельца платежной системы Chronopay Павла Врублёвского , обвинённого в DDoS-атаке против «Аэрофлота».

Суть ключевого сюжета сводилась к тому, что суд затребовал внутреннюю переписку между участниками этого уголовного процесса, которую они вели через личные аккаунты в Facebook. Несмотря на то, что там содержалась важнейшая изобличительная информация, коварная американская социальная сеть не вняла просьбе российского правосудия и отказала в доступе к приватной переписке граждан РФ. И тут происходит тот самый драматичный перелом в этой истории — ФСБ в исполнении решения суда самостоятельно «добывает» переписку этих граждан.

«ЦИБ ФСБ, в соответствие с Законом «Об оперативно-розыскной деятельности» осуществил самостоятельный съем информации с каналов связи указанных лиц и записал её на DVD-диск».

Действительно, впоследствии сторона защиты смогла убедиться, что необходимая личная переписка была «изъята из сети в полной мере и объёме» вопреки воле Facebook. При этом сами фигуранты сего дела отрицали предоставление следствию своих паролей и обличающей себя переписки. В Рунете можно найти кричащие новостные заголовки типа «ФСБ России взломало серверы Facebook» , но не следует забегать с выводами настолько далеко.

Во-первых, все сеансы связи с Facebook осуществляются исключительно по защищённому протоколу связи HTTPS. Во-вторых, с момента последних контактов подсудимых и данного решения суда (и, следовательно, следственных действий ФСБ по исполнению данного решения) прошло достаточно много времени. С какого такого «канала» можно было «снять» эти «данные из прошлого», если сами фигуранты в сеть с тех пор не выходили, находясь под следствием?

Эти прямые вопросы, заданные на суде к представителям ФСБ, они проигнорировали. Наиболее очевидная версия ответа напрашивалась сама: HTTPS-трафик с данной перепиской был заранее проснифан/сохранен ФСБ и каким-то образом впоследствии взломан.

Интересно, что ранее в материалах этого же дела зафиксирован почти аналогичный случай. ЦИБ ФСБ, цитируя протокол следствия, «путём сохранения и анализа трафика интернет-подключения одного из обвиняемых восстановил логин и пароль от панели управления ботсети» (физически расположенной на сервере в США), после чего перехватил удаленный контроль над этим ботнетом. Так вот, доступ к той самой веб-панели осуществлялся обвиняемым опять же исключительно по зашифрованному HTTPS-соединению с соблюдением мер предосторожности (например, без сохранения паролей на своем локальном компьютере).

Таким образом, констатируем наличие проблем с безопасностью HTTPS, приводя поразительные случаи преодоления «защиты» TLS/SSL со стороны российских спецслужб.

Modus Operandi

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

На первом моменте подробно останавливаться не будем, поскольку физический доступ к практически любым каналам у спецслужб есть. Те, кто следит за последними новостями «СОРМостроения», уже в курсе , что в соответствии с новым законом с 1 июля 2014 г. все российские провайдеры обязаны установить на свои сети спецоборудование для записи и хранения своего транзитного интернет-трафика в полном объёме на срок не менее 12 часов. Причем силовики получат прямой доступ ко всем сохраняемым и транзитным массивам данных.

Gmail мне пишет: "Возможно, ваш аккаунт или компьютер подвергся воздействию со стороны хакеров, поддерживаемых определенными государствами"
— Roman Dobrokhotov (@Dobrokhotov) September 9, 2014

Если же говорить о прослушке HTTPS-сессий, то сразу отметим важный момент — необходимость «активного режима» прослушивания в некоторых случаях, потому как сохраненный трафик не всегда может быть взломан позже. Речь идёт о так называемом режиме прогрессивной секретности (forward secrecy, FS) для протокола HTTPS, который предотвращает возможность восстановления данных после окончания сеанса связи (даже если впоследствии злоумышленник сможет получить валидные ключи сайта). Наличие такого режима обязывает злоумышленника «ковать железо пока оно горячо» - то есть, взламывать данные в режиме реального времени, что в подавляющем большинстве случаев вряд ли технически возможно.

Плохая новость заключается в том, что Facebook, равно как и большинство других крупных интернет-порталов, не используют режим forward secrecy потому, что он создает дополнительную серьёзную нагрузку для и так перегруженной социальной махины. Кроме того, использование подобных продвинутых DH-алгоритмов может негативно влиять на совместимость с некоторыми популярными браузерами. Теперь легко понять, почему согласно статистике Netcraft по состоянию на лето 2013, примерно 70-99 % наблюдаемых в рамках данного мониторинга SSL-соединений вообще не использовали FS.

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

Выше показан замер падения производительности на 6-ядерном процессоре веб-сервера с включенным и соответственно отключенным режимом DHE. DHE выбран как самый популярный и образцовый пример реализации Perfect Forward Secrecy. Например, компания Google , сервисы которой поддерживают практически все крипто-инновации и средства защиты своих пользователей (это яркое исключение из общей интернет-практики), реализует недолговечные («эфемерные») сеансовые ключи PFS как раз на базе ECDHE_RSA. И это очень, очень дорогое удовольствие, поверьте!

Учитывая данное замечание, будем считать, что с перехватом трафика всё более-менее ясно . Теперь рассмотрим, что делать дальше с сохраненным шифрованным потоком.

Представляется, общий алгоритм в этом случае будет выглядеть примерно так: при перехвате интересующего трафика HTTPS-сессии гипотетическими спецслужбами их информационная система получает запрос поиска соответствующего серверного ключа к своей базе данных. Если такой ключ не найден, он ставится в очередь на дальнейшее вычисление (взлом). С учётом замечания о фактической недоступности опции FS, интересующий трафик всегда есть смысл молча накапливать (записывать), не дожидаясь реакции системы о готовности/доступности ключа для дешифровки в режиме реального времени.

Что касается упомянутой базы данных из серверных ключей, то ещё летом 2013 года издание Cnet опубликовало информацию и документ-пример запроса АНБ в адрес крупной интернет-компании, пожелавшей остаться неизвестной. Согласно этому источнику стало известно, что такие же запросы получали в свой адрес и другие крупные интернет-площадки (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T и др.). Cnet официально обратилось в эти организации с просьбой прокомментировать факт подобного запроса, но в подавляющем большинстве случаев компании отказались как подтвердить, так и опровергнуть подобное взаимодействие с АНБ.

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

Действительно, закрыть данную уязвимость удалось лишь после поднятого шума в прессе. Сам же проект Debian назвал ситуацию с давним багом в своём репозитории OpenSSL «довольно странной историей».

Если же говорить о пресловутых аппаратных «закладках», то в последнее время они расцвели буйным цветом уже в самых неожиданных местах: от утюгов до кофемашин. Так по данным Spiegel , специальное управление АНБ «Операции специального доступа» (Tailored Access Operations, TAO) долгое время осуществляло массовый перехват купленного самыми разными компаниями и странами компьютерного (и не только) оборудования по пути от поставщика к адресату. При этом перехваченное оборудование, отгруженное интересующему АНБ заказчику, оперативно проходило через секретную «фабрику» TAO, где в него внедрялось модифицированное ПО или «жучки». Такое вмешательство в процесс поставок в собственных целях, обозначаемое спецтермином «интердикция», оценивался самой АНБ как один из «наиболее эффективных видов современных операций».