Спецслужбы против TLS/SSL: перехваченный трафик, закрытые ключи, криптозакладки

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

В силу важности этой проблематики в рамках серии публикаций dev.by предлагает обзор безопасности стэка протоколов 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

 

@Dobrokhotov сорм подменяет tls/ssl криво, чтобы легко вас читать.

— Змaj Огњени Вук (@zmeevolk) 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 официально обратилось в эти организации с просьбой прокомментировать факт подобного запроса, но в подавляющем большинстве случаев компании отказались как подтвердить, так и опровергнуть подобное взаимодействие с АНБ.

В приведённом документе речь шла о безусловном требовании предоставить в распоряжении федералов доступ к закрытым ключам SSL/TLS этих популярных веб-ресурсов (SSL/TLS master encryption keys), выдать базы данных с хэшами паролей всех пользователей, а также расписать применяемые алгоритмы и методы хэширования.

Интересно, что совсем другой источник — Эдвард Сноуден — год спустя полностью подтвердил существование информационной базы АНБ, содержащей актуальные SSL/TLS-ключи крупнейших и наиболее популярных веб-ресурсов мира. Повторюсь, это позволяет прозрачно (on-the-fly) дешифровать практически любой HTTPS-трафик, связанный с этими порталами и социальными сетями.

Проект BULLRUN – официальная смета расходов АНБ на «размытие прочности» криптографических стандартов, спецификаций и их реализаций

В мутной водице черти водятся

Конечно, далеко не все мировые веб-проекты добровольно раздают серверные ключи спецслужбам. Хотя бы потому, что интернет — это наднациональное образование, лежащее в юрисдикции множества государств сразу.

Поэтому следующий важный этап для силовиков — это систематическое и намеренное ослабление стойкости важнейших криптоалгоритмов, используемых повсеместно независимыми от них интернет-порталами. Опять же, согласно документам, опубликованным Сноуденом, стало известно, что АНБ давно и успешно сотрудничает с криптографическими компаниями по вопросу встраивания в их продукты закладок в интересах спецслужб США. По строчкам расходов в опубликованных документах видно, что только на встраивание бэкдоров в популярные криптографические продукты АНБ ежегодно тратит около $250 млн на выплаты наличными лицам, принимающим в участие в их разработке.

В качестве наиболее яркого примера из череды подобных инцидентов можно привести недавнее сообщение агентства Reuters, которое приводит документальные факты того, что широко известная криптографическая компания RSA Security на протяжении нескольких лет сотрудничала с АНБ. Согласно их двухстороннему контракту, в криптографических продуктах RSA предпочтение должно было отдаваться алгоритму генератора псевдослучайных чисел (ГПСЧ) Dual EC DRBG. Как теперь известно, последний — не только содержит скрытую уязвимость, но и стал самым популярным в мире ГПСЧ.

Today Reuters reported that the NSA paid RSA, a security company and subsidiary of EMC, $10 million to use a

— WUDFHost.exe (@WUDFHost) September 3, 2014

 

: RSA replied, but failed to clarify anything about $10 million bribe they received from #NSA http://t.co/HFLc26yzhF pic.twitter.com/KO5tO2AsEB

— anoncracker (@anoncracker) December 23, 2013

Возвращаясь к российским крипто-стандартам, заметим, что согласно ГОСТ 28147-89, таблицы замен вместе с сертификацией устройства\программы выдает непосредственно ФСБ РФ. Очевидно, что от качества генерации такой таблицы критически зависит общая стойкость шифрования. На выходе получается этакая «государство-зависимая криптография»…

Специально для тех, у кого RSA Security ассоциируется с дорогостоящими проприетарными решениями, приведём несколько аналогичных примеров из мира Open Source. Так, в 2010 году один из образцовых проектов OpenBSD потряс скандал. Его создатель Тео де Раадт опубликовал личное письмо от Грегори Пери, где сообщалось о наличии в коде OpenBSD «закладок», специально внесенных туда по заказу ФБР. По словам Грегори, бывший сотрудник Netsec Джейсон Райт непосредственно отвечал за внесение в OpenBSD кода с «закладками», а известный в западном ИТ-сообществе специалист по виртуализации Скотт Лоуэ, будучи одним из штатных сотрудников ФБР, занимался активным продвижением OpenBSD на коммерческом рынке.

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

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

Годом ранее очень похожая история приключилась с OpenSSL уже в рамках проекта Debian, где обнаружили (аналогичный описанному выше) математический дефект в генераторе псевдослучайных чисел. В связи с этими двумя случаями хочется процитировать мнение известного отечественного юниксоида Алексея Тутубалина:

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

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

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

NSA plans to infect potentially millions of computers with malware as part of its Tailored Access Operations https://t.co/HQ6Fo6LvbJ

— EFF (@EFF) June 5, 2014

 

АНБ США внедряет «жучки» в роутеры и серверы, пока они едут к покупателям: АНБ получает и перехватывает серверы и... http://t.co/3urByYTHtO

— ITNews.PRO (@ITNewsPRO) May 13, 2014

По информации Spiegel, наиболее вожделенным (приоритетным) для интердикции оборудованием являлось как раз специализированное криптообрудование, то есть самые разные аппаратные ускорители и акселераторы для создания, в том числе, безопасных TLS/SSL/IPSec-каналов на их основе для правительственных, военных и коммерческих нужд.

NSA reportedly installing spyware on US-made hardware http://t.co/FFjRxBVHrj #manivaje

— Hans Schoolenberg (@Buitendijks) September 9, 2014

Выводы

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

1. Создание глобальных правительственных баз данных из валидных мастер-ключей для популярных интернет-проектов.
2. Разработка и популяризация намеренно ослабленных алгоритмов и спецификаций, которые получают  широкое хождение и применение.
3. Создание «закладок» для их внедрения в свободные/проприетарные, как программные, так и аппаратные продукты.
4. Активный поиск, выявление и эксплуатация уже существующих уязвимостей.
5. «Честный брутфорс» приватных ключей с помощью специализированного высокопроизводительного аппаратного оборудования.

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

Хакеры при погонах. Зачем российские власти взламывают Gmail? http://t.co/EtNnI23H6t С комментарием @b0ltai

— The Insider (@the_ins_ru) September 10, 2014

Сноуден уехал, но дело его живёт

Примерно год назад проект factorable.net завершил собственный общественный мониторинг транзитного интернет-трафика (для чего использовались сканеры ZMap и nmap), где «в диких условиях» наблюдались все SSL/TLS и SSH-соединения тысячи случайных хостов друг с другом.

Вот его главные выводы:

• Примерно 6% TLS-соединений и 7% SSH-соединений использовали небезопасный механизм обмена своими публичными ключами, вызванный главным образом недостаточной рандомизацией при генерации ключей (или со стороны исходных дефолтных ключей).
• В силу этого данному любительскому проекту удалось удаленно заполучить частные ключи RSA почти для 1% TLS-соединений и для 0.03% SSH-соединений в полностью пассивном режиме.
• Проект смог удалённо заполучить частные ключи DSA для более 1% всех SSH-соединений по этим же причинам.
• Подчеркивается, что процент слабозащищенного трафика существенно больше указанного, ведь выше приведены лишь цифры, по которым проект имел готовые методики атак. Если же говорить о потенциально опасных долях, можно утверждать, что под ударом находится 6-7% от всех HTTPS-соединений и более 10% от всех SSH-подключений в мире.

Резюмируя, для большого числа TLS-ключей обнаружено, что они имеют общие простые множители, то есть их факторизация заметно (подозрительно) упрощена. Дополнительно отметим, что серверные ключи традиционно существуют в неизменном виде годами. Поэтому, глядя на эти статистические данные, с большой степенью вероятности можно предположить, что как минимум треть защищённого трафика в мире сгенерировано криптографическими средствами с (заведомо?) ослабленным ГПСЧ.

Продолжение следует

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

Иллюстрации: Вася Ложкин, admem.ru, Netcraft, vincent.bernat.im, www.shutterstock.com

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.