dxdt.blog: занимательный интернет-журнал

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

Итак, получение трафика реализуется с помощью его перенаправления или копирования в сети NSA. Перенаправление реализует транзитный узел, который нужно правильно подобрать. Пользовательский интерфейс наверняка устроен следующим образом: оператор вводит требуемый IP-адрес, обозначающий либо пользователя, либо сервер; система находит в базе данных, хранящей сведения о топологии сети, подходящие точки присутствия NSA, через которые может проходить трафик для заданного IP, проверяет, что этот трафик там есть, обнаружив трафик – ставит его на прослушивание, включает перенаправление. Нужно различать два режима работы с трафиком: активный и пассивный. В пассивном случае трафик лишь копируется в анализирующий сегмент. В активном – перенаправляется, то есть, между двумя точками, устанавливающими соединение, появляется дополнительный узел. Кстати, активный режим, работающий на уровне IP, сейчас штатно используется интернет-провайдерами для фильтрации доступа к интернет-ресурсам. Так что это вполне стандартный инструмент.

Тут есть ряд трудностей. Маршруты, по которым ходят пакеты в Интернете, могут меняться, соответственно, нужно найти действующий маршрут, а в дальнейшем – следить за его возможными изменениями. Кроме того, подключение пользователя с “внутренним” IP-адресом, из адресного пространства локальной сети, может находиться за неким транслятором адресов, внешний адрес которого соответствует и другим пользователям. Очевидно, задача упрощается, если в качестве исходных данных используется адрес не только пользователя, но и сервера, с которым он работает. Проще перехватывать трафик заданного сервера, но и поиск путей перехвата только “по пользователю” тоже реализуем, если у вас в распоряжении суперкомпьютер, анализирующий таблицу BGP, и вы видите определяющий маршруты технический трафик на портах крупнейших мировых транзитных узлов.

Перехват интернет-трафика обычно представляют на уровне IP или близких к этому протоколу уровнях. Однако в реальности существуют более “глубокие” уровни, позволяющие коммутировать каналы и пересылать пакеты данных в самые разные центры обработки. То есть, сведения из таблиц BGP требуется для поиска точек подключения клиентов и серверов, для построения списков транзитных узлов. Но сам перехват может быть реализован на уровне других протоколов, относительно которых реализация IP-транспорта является виртуальной надстройкой.

Итак, после того, как подходящие узлы перехвата определены, вычисляется, возможна ли работа в активном режиме. Активный режим необходим для осуществления атаки типа “человек посередине”. Действительно, транзитный узел (например, маршрутизатор), может сделать с проходящим через него трафиком всё что угодно. В том числе, направить трафик для определённых адресов по специальному маршруту, завернув его в сеть NSA в прозрачном режиме. При идеальной реализации, единственное, что может выдать систему анализа, это возросшая задержка при установлении соединения. Однако активный режим требует возможности управления, условно говоря, коммутацией: нужно добавлять дополнительный узел в цепочку. Пассивный – может быть реализован значительно проще, без доступа к начинке коммуникационного оборудования: достаточно установить на физический канал оптический сплиттер (ну или подключиться к проводам, если они вдруг используются).

Хорошие кандидаты на роль узла перехвата: пограничные маршрутизаторы провайдеров доступа; точки подключения дата-центров; узлы опорных сетей крупнейших операторов связи; усилители оптических сигналов и так далее, это далеко не полный список. При наличии бекодров в прошивках домашних роутеров, последние также становятся хорошим инструментом перехвата пользовательского трафика. Система “тотального” перехвата должна предоставлять единый “уровень абстракции”, позволяющий получить нужный трафик вне зависимости от того, на каком узле и каким способом он физически перехватывается. Это вполне реализуемо, если у вас есть коллектив разработчиков, достаточно вычислительных мощностей и пропускной способности собственных каналов связи. Понятно, что у NSA тут проблем нет.

Кстати, по этой же теме: “Вывод информации, снятой с подводных кабелей“.

Есть, скажем, программное обеспечение с открытым исходным кодом, есть процессы выработки различных рекомендаций (стандартов, RFC), которые, вроде бы, тоже протекают в открытом режиме. Представление об открытости процессов, регулирующих, в частности, Интернет – это такой фактор, на который сейчас принято ссылаться как на некую гарантию отсутствия агентов влияния. (В контексте деятельности АНБ, например.) Но существует ли эта декларируемая “открытость Интернета” фактически?

Оказывается, чтобы разобраться в общедоступных потоках сообщений и мнений, приводящих к появлению тех или иных стандартов и рекомендаций (или программного кода, если хотите), обычному пользователю-наблюдателю не хватит ни квалификации, ни времени. А ведь для построения точного представления о движущих силах нужно ещё представлять контекст, который создаётся в личном общении участников процессов выработки решений (пусть это переписка или какие-нибудь телеконференции – не важно, всё равно они не публичны). Да и много ли вообще желающих разбираться в отчётах, письмах, предложениях и баг-трекерах? Так что “прозрачность”, не имеющая удобного интерфейса, – мнимая.

Виртуальный хостинг RU-CENTER доступен на нескольких площадках (дата-центрах) – Москва, Амстердам, Новосибирск. Для сравнения площадок сделали вот такой сервис: hat.nic.ru – просмотр уровня доступности площадки в зависимости от региона. Для построения оценки собрана довольно приличная статистика: около 4 млн запросов (примерно 1 млн уникальных IP-адресов; это за месяц).

Принцип работы сервиса следующий. Есть три узла, находящихся в разных дата-центрах. На каждом из них работает веб-сервер. Это специальный веб-сервер, написанный с нуля, конкретно под эту задачу. В ответ на запросы пользовательских компьютеров – веб-сервер отдаёт эталонную порцию данных, измеряя время её передачи. Это и есть основа для статистики. А чтобы пользовательские запросы возникали, на некоторых веб-ресурсах разместили специальный код, который их и генерирует (посредством браузера, конечно).

В общем, hat.nic.ru – полезный сервис, позволяющий понять, на какой площадке лучше разместить веб-сайт, в зависимости от географического распределения аудитории.

Интересно представить, как может работать гипотетическая система “тотального” прослушивания NSA защищённого интернет-трафика. Защищённый интернет-трафик, в подавляющем большинстве случаев, использует TLS/SSL, с теми или иными SSL-сертификатами. Самый известный пример такого использования – защищённая версия HTTP, HTTPS, его и возьмём в качестве примера. Другим источником сведений о гипотетической системе послужат скриншоты неких интерфейсов доступа и другие фрагменты презентаций, которые были опубликованы в СМИ. (Напомню, что я уже писал о перехвате HTTPS ранее.)

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

Начнём со второй задачи, с расшифровки или предотвращения шифрования данных, предположив, что трафик уже перехвачен.

В принципе, протоколы TLS (HTTPS) проектировались из соображений, что канал передачи данных между пользователем и сервером может прослушиваться и перехватываться в активном режиме. Поэтому TLS, в теории, позволяет защитить данные от прослушивания и обнаружить активное вмешательство в канал. Что с этим можно сделать? Я уже не раз рассказывал о том, что есть возможность подмены серверного сертификата с дальнейшим перехватом соединения. Эта опция доступна, если с вами сотрудничает удостоверяющий центр, которому доверяет программное обеспечение пользователя. Но есть ещё один вариант: можно получить серверный закрытый ключ. В таком случае для перехвата можно использовать действующий сертификат сервера, он всем доступен, его достаточно просто скопировать. При наличии серверного ключа можно и проводить атаку типа “человек посередине”, и расшифровывать данные в пассивном режиме (если сервер настроен подходящим образом). Атака “человек посередине” предотвращает шифрование данных в точке перехвата.

Как получить серверный ключ? Если NSA внедряет закладки в программное и аппаратное обеспечение, то, вероятно, есть возможность вычислить секретный ключ за разумное время. Например, для самой популярной криптосистемы RSA достаточно знать разложение на простые множители модуля, используемого в данном секретном ключе. (Модуль – это, грубо говоря, число, задающее множество, в котором проводятся операции для даннной пары закрытый/открытый ключ.) Это не единственный способ, есть множество других. Закладка NSA с указанными свойствами приводит к уменьшению количества возможных ключей. В качестве наиболее вероятного рычага воздействия закладки принято называть генератор (псевдо)случайных чисел. Действительно, как бы хорошо не была реализована сама криптосистема, если практическое число возможных ключей, порождаемых генератором “неслучайных” чисел, не велико, то и от самой системы толка нет.

Тривиальный пример. Предположим, в NSA, воздействуя на производителей криптомодулей, на разработчиков программного обеспечения, добились того, что количество простых чисел, используемых в качестве одного из сомножителей в ключах RSA, которые генерируются “сертифицированными средствами”, не превышает 10^12 (триллион). Второе число может быть истино случайным, ведь тут важно не переборщить: чрезмерно малое разнообразие ключей будет быстро обнаружено наблюдателями (см. историю с ошибкой в Debian OpenSSL, которая, кстати, теперь уже и не кажется просто ошибкой). Зная структуру множества этих выбранных простых чисел, можно быстро вычислить секретный ключ простым перебором. Чуть более технично: пусть модуль ключа RSA представляет собой произведение двух простых чисел; если наш суперкомпьютер выполняет миллион пробных делений в секунду, то, исходя из 10^12 вариантов известных множителей, мы получим разложение для модуля не более чем через 278 часов; это означает, что факторизация будет обычно занимать чуть более недели. Заметьте, что серверные ключи традиционно существуют в неизменном виде годами.

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

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

Вычисленный ключ попадает в базу данных и становится доступен пользователям системы прослушивания HTTPS. Трафик можно начинать записывать сразу, не дожидаясь готовности ключа. Например, если взглянуть на те же веб-сервера Mail.ru, то они, как и подавляющее большинство других сервисов Интернета, не поддерживают прогрессивной секретности (forward secrecy) для HTTPS, это означает, что ранее записанный трафик можно расшифровать позднее, когда станет известен серверный ключ. (Подчеркну: я не вижу тут какой-то ошибки со стороны Mail.ru – они просто следуют сложившейся практике.)

Продолжение про перехват HTTPS – в следующей части, рассказывающей о перехвате трафика.

Очередная порция материалов относительно прослушивания интернет-трафика NSA. В этот раз на “скриншотах” видео, повествующего об экономическом шпионаже за бразильской нефтяной компанией Petrobras, можно посмотреть на интерфейс некой системы, перехватывающей TLS (HTTPS). Из контекста очевидно, что перехват производится при помощи подмены серверного сертификата на другой, но тоже легитимный, выпущенный тем или иным хорошо известным удостоверяющим центром, чтобы не вызывать предупреждения системы безопасности в браузере.

Очень интересно, что российский почтовый провайдер Mail.ru опять фигурирует в презентациях NSA (АНБ). Полюбуйтесь – здесь указан IP-адрес сервера (94.100.184.14) из сети Mail.ru:

(Примерно 2:08 в видео.)

Не вдаваясь в оценки связи с реальностью “скриншотов” интерфейса системы NSA из СМИ, отмечу, что трафик на серверы Mail.ru вполне мог перехватываться, при условии, что тот или иной транзитный маршрутизатор перенаправлял нужный поток в NSA (о чём упоминается на тех же слайдах).

Опять повторяется история с перехватом управления доменом известного ресурса, с последующей сменой серверов имён и перенаправлением всего трафика на сайт атакующих. Вчера такая штука произошла с доменом The New York Times. Причём, из-за кеширования DNS, перенаправление происходило долгое время после того, как правильную адресацию в домене восстановили. Понятно, что атака позволила перехватить и электронную почту, работающую в домене. А это, в свою очередь, первый шаг к перехвату аккаунтов в разных других сервисах, при помощи “напоминалок паролей”.

Заметьте, что DNSSEC от перехвата управления доменом у регистратора – никак не защищает. И большой вопрос, почему все эти крупные СМИ до сих пор не выстроили защищённую схему работы с регистратором, при том, что методы защиты известны (это подтверждение операций по управлению доменом, дополнительная авторизация и другие решения).

Вот, ICANN выяснила, что с массовым вводом новых доменов верхнего уровня не всё так гладко, как говорится, “с точки зрения безопасности”. Грозят отодвинуть сроки внедрения.

(Вообще, про .corp и прочие .lan – с самого начала было понятно: глобальное делегирование таких имён дело скользкое, и не только из-за проблем с SSL-сертификатами.)

Сейчас проходит очередная массовая атака на сайты, работающие под CMS WordPress. В этот раз она сводится к POST-запросам по адресу /wp-login.php. Видимо, это следы попытки подбора паролей. Отличие этой атаки в том, что запросы приходят с очень большого числа IP-адресов, что несколько затрудняет блокирование. Похоже, атака касается только сайтов в домене .ru (но тут нет уверенности). Поток запросов велик, кто-то активировал ботнет: например, на одном из сайтов я сейчас вижу около 20 POST-запросов в секунду.

Кстати, прошлая массовая атака была устроена несколько хитрее.

В связи с ростом интереса к перехвату “всего и вся” структурами NSA, часто стали упоминать HTTPS. Думаю, полезным будет некоторый небольшой популярный обзор HTTPS, как раз с точки зрения его прослушивания. Ниже, кроме HTTPS, фигурируют такие связанные понятия, как TLS/SSL, SSL-сертификат.

Итак, ряд базовых моментов.

1. HTTPS – это HTTP, работающий по “защищённому каналу”. Технологии, служащие для создания такого канала для HTTPS, называются TLS (SSL). TLS используется не только HTTPS. Обычно предполагается, что трафик, передаваемый по упомянутому каналу, может быть доступен третьей стороне, которая, однако, не должна иметь возможность раскрыть сами передаваемые данные (“защита от прослушивания”, реализуется шифрованием; заметьте, впрочем, что HTTPS можно устроить без шифрования, но это будет являться ошибкой).

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

3. SSL-сертификаты не связаны с собственно шифрованием данных HTTPS, но они позволяют создать зашифрованный канал. Однако такой канал может быть создан и без использования сертификата. Функция SSL-сертификата, применительно к HTTPS, состоит лишь в удостоверении связки некоторого имени ресурса и некоторого открытого ключа. В качестве имени ресурса обычно выступает доменное имя (пример: dxdt.ru). То есть, при помощи серверного SSL-сертификата, клиент (обычно – браузер) может удостовериться, что соединяется именно с обладателем секретного ключа из пары, открытая часть которой указана в сертификате. Этот процесс часто называют аутентификацией сервера. Если специально задаться целью, то несложно реализовать TLS-соединение с проверкой SSL-сертификата, но вообще без шифрования.

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

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

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

7. Если генерация секретного сеансового ключа проводится по алгоритму Диффи-Хеллмана, то наличие серверного секретного ключа никак не помогает восстановить его из записанного трафика. Однако на практике далеко не все TLS-серверы используют соответствующие алгоритмы.

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

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

10. Тем не менее, валидный SSL-сертификат, выпущенный для атакуемого домена, позволяет провести незаметную для пользователя атаку типа “человек посередине”. Для этого требуется, чтобы между атакуемым пользователем и сервером существовал управляемый атакующим узел, активно перехватывающий трафик. Этот узел выдаёт себя пользователю за легитимный сервер, предъявляя тот самый валидный сертификат. Пассивное прослушивание канала не позволяет раскрыть HTTPS-трафик подобным образом – наличие сертификата или секретных ключей УЦ никак тут не помогает.

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

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

13. “Человек посередине” не работает для HTTPS при наличии некоторых дополнительных мер: например, установление TLS-соединения требует взаимной аутентификации, и перехватывающему узлу недоступен клиентский секретный ключ (либо ключи УЦ, удостоверяющего клиентский ключ); или – пользовательский браузер ведёт реестр отпечатков открытых ключей сервера, которым он доверяет; или – пользователь применяет дополнительные источники сведений о разрешённых ключах и сертификатах, которые недоступны для подмены на перехватывающем узле (таким источником может служить DNS, либо другая база данных).

14. Все (хорошо – подавляющее большинство) сколь-нибудь массовые сервисы используют так называемый SSL termination: то есть, пользовательский HTTPS-трафик в зашифрованном виде доходит только до пограничного прокси, где благополучно транслируется в HTTP, который дальше ходит по внутренним (в логическом, а не техническом смысле) сетям сервиса в открытом виде. Это стандартная практика, так как тотальный HTTPS, с ростом числа клиентов, быстро превращается в неподъёмную, плохо масштабируемую технологию. Если система инспекции трафика находится внутри сетей сервиса, за таким пограничным SSL-прокси, то никакой HTTPS ей не мешает. Внутренний трафик распределённых сервисов с легкостью ходит между узлами и дата-центрами по арендованным у крупных операторов каналам связи в открытом виде, такой трафик может прослушиваться, хотя для пользователя он выглядит как HTTPS-соединение.

15. Если на компьютере пользователя присутствует троянская программа, имеющая доступ к браузеру, то HTTPS также оказывается бесполезным, так как данные могут копироваться вовне до того, как попадут в зашифрованный канал.

Вот.

Одна из основных проблем современной инфраструктуры SSL-сертификатов в том, что удостоверяющие центры (УЦ) могут выпускать сертификаты, нарушающие принципы построения цепочки доверия в клиентском программном обеспечении. Самый распространённый пример таких сертификатов – сертификаты, выпущенные для того или иного домена без разрешения администратора этого домена.

Бороться с таким положением дел можно, кроме прочего, с помощью построения дополнительной открытой системы аудита сертификатов, назависимой от УЦ и доступной для использования каждому, кто заинтересован в дополнительной проверке полученных с сервера сертификатов. При поддержке Google развивается как раз такая система: Certificate Transparency (CT). Основные задачи, которые могут быть решены при помощи CT: затруднить выпуск SSL-сертификатов для домена, невидимый администратору этого домена; позволить администратору домена узнать, какие сертификаты для его домена были выпущены; оградить клиентское программное обеспечение от доверенного использования неправомерно выпущенных сертификатов. Решается всё при помощи ведения лога, содержащего описания сертификатов. Подробности есть на сайте.

На сайте журнала “Доменные имена” появился PDF весеннего выпуска. Почитайте. Темой номера стал Интернет после апокалипсиса. А статья “Главной темы” (с.34) рассказывает о грядущей сегментации Сети и о возможном установлении в ней “государственных границ”:

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

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