Это СОРМ, детка. Часть 1

========================

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

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

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

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

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

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

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

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

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

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

Modus Operandi

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

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

Причем силовики получат прямой доступ ко всем сохраняемым и транзитным массивам данных.

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

— Змaj Огњени Вук (@zmeevolk) 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) 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) 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, где в него внедрялось модифицированное ПО или «жучки».

Такое вмешательство в процесс поставок в собственных целях, обозначаемое спецтермином «интердикция», оценивался самой АНБ как один из «наиболее эффективных видов современных операций».

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

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

— Hans Schoolenberg (@Buitendijks) 9 сентября 2014

Выводы

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

Создание глобальных правительственных баз данных из валидных мастер-ключей для популярных интернет-проектов.

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

Создание «закладок» для их внедрения в свободные/проприетарные, как программные, так и аппаратные продукты.

Активный поиск, выявление и эксплуатация уже существующих уязвимостей.

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

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

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

--------------------------------

Примерно год назад проект 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 в лоб.

Это СОРМ, детка. Часть 2

========================

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

Между тем, повсеместное подключение к системам типа СОРМ, которые позволяют прозрачно проводить глобальные MiTM-атаки, а также доступ спецслужб к корневым SSL-сертификатам и рукотворно-массовым уязвимостям в области ПО, превращают концепцию абсолютной безопасности HTTPS в утопичный рудимент.

Грош цена SSL-сертификату

-------------------------

В прошлом году Mozilla Project буквально за руку схватила известнейший удостоверяющий центр Trustwave, который втихаря продавал корневые сертификаты (subordinate root). Под давлением доказательств Trustwave был вынужден официально признать вину, так и не назвав покупателя сертификатов. Пресс-релиз этого крупного удостоверяющего центра гласил:

«Выдача корневого сертификата сторонней компании для анализа SSL-трафика внутренней сети компании — это обычная практика».

Поясним последствия этого далеко идущего шага для публики. Наличие подобного вторичного корневого сертификата (subordinate root CA) у стороннего лица позволяет ему создать корректный и не вызывающий подозрения сертификат для абсолютно любого сайта в сети без привлечения удостоверяющего центра, авторизованного на выполнение подобных операций. В свою очередь это дает возможность проводить абсолютно «чистые» man-in-middle атаки, которые конечный интернет-пользователь никак не сможет отследить, что приведет к созданию ложных дубликатов известных сайтов и возможности прослушки их трафика.

Иными словами, эта невольно всплывшая «обычная практика» регистратора сводит замысел SSL полностью на нет. Trustwave не скрывает цели покупки сертификата её таинственным контрагентом, честно заявляя об этом в правдательном письме:

Сертификат продан с целью обеспечения работы системы корпоративного мониторинга утечек данных, то есть сертификат будет использоваться для организации перехвата SSL-сессий в режиме man-in-middle, путём генерации на лету валидных сертификатов для всех анализируемых сессий.

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

Аналогичные инциденты всплывают с пугающей регулярностью. Год назад исследователи случайно наткнулись «в дикой природе» на поддельный веб-сертификат для Google.com, который может быть использован для компрометации почтового сервиса Gmail. Расследование показало, что источником данного сертификата является французский центр SSL-сертификации IGC/A (также известный как ANSSI). Учредителем центра оказалась государственная контора French cybersecurity agency, которая не скрывает связей с местными спецслужбами. В ответ на разоблачение IGC/A промямлил «о случайной ошибке сотрудника», после чего отозвал все проблемные сертификаты.

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

С одной стороны, вал подобных сообщений нарастает с каждым днем. Например, Microsoft уже дважды вынуждена была корректировать свой Certificate Trust List (CTL) в Windows, выбрасывая оттуда «преступно выданные SSL-сертификаты» (вот пример такого случая). Набирает обороты самая настоящая эпидемия коррупционно-финансовой компрометации принципов SSL/TLS.

С другой стороны, когда следует повысить бдительность, Google планирует отказаться от использования проверок сертификатов на актуальность в онлайн-режиме (revocation checking) в будущих версиях Google Chrome. То есть, если раньше при подключении по протоколу HTTPS к любому сайту этот браузер делал дополнительный запрос в центр сертификации (Certificate Authorities) на предмет того, не отозван ли данный конкретный сертификат (как в случае с ANSSI), то теперь делать этого не будет.

Подкуп против криптографии

--------------------------

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

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

Аналогичные вещи творятся и на стороне системообразующего криптографического софта. Мы уже рассказывали о скандальной ситуации вокруг известных продуктов RSA, когда согласно источникам Reuters, АНБ тайно заплатила компании 10 млн долларов, после чего этот прославленный «крипто-бренд» внедрил скрытую уязвимость в ведущем продукте.

Забавно другое: инициированная после этого инцидента независимая проверка продуктов RSA, похоже, открыла ящик Пандоры. На данный момент выявлен уже второй опаснейший баг, встраивание которого, вероятно, также «пролоббировано» спецслужбами США. Если прошлый баг был добавлен в генератор случайных чисел, то новая уязвимая технология — модуль Extended Random (ER), который по легенде призван существенно увеличивать уровень энтропии при генерации шифров Dual Elliptic Curve.

Иначе говоря, модуль ER предназначался для сверхсекретных данных, для защиты которых за дополнительную плату можно приобрести такой «усилитель» генерации ключей. Исключительно выгодная двойная монетизация здесь налицо: с одной стороны деньги несут благодарные клиенты, горящие желанием защитить свои интеллектуально-коммерческие секреты во враждебной капиталистической среде, с другой — банкет щедро оплачивают спецслужбы, испытывающие непреодолимый зуд знать всё про всех.

Нужная спецификация за мелкий прайс

-----------------------------------

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

К примеру, буквально месяц назад рабочая группа HTTPBis Working Group предложила новый стандарт Explicit Trusted Proxy («Полностью доверенный прокси в HTTP/2.0») для новой версии протокола HTTP/2.0. В этом проектном документе описывается общий механизм прозрачной расшифровки транзитными провайдерами защищенных пользовательских данных «с целью их кэширования».

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

«Из предложения следует, что интернет-пользователи должны соглашаться с тем, что они доверяют „промежуточным“ сайтам (таким, как Verizon, AT&T и др.) и разрешают расшифровывать их данные для „предположительно“ невинных целей, а затем шифровать заново и перенаправлять в пункт назначения в целях безопасности».

Несмотря на протест общественности, для которой нежелательный побочный эффект в области приватности от подобных действий очевиден, рабочая группа (ее главным спонсором является один из комитетов правительства США) категорична в своем стремлении сделать эту опцию частью будущего стандарта HTTP/2.0.

Как видно, не мытьём так катанием роль защищенных протоколов ради достижения «невинных целей» будет последовательно размываться и сводиться к нулю на самых разных уровнях: от их проектирования до реализации.

«И только бабло побеждает зло»

-----------------------------

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

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

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

Во-вторых, аноним привел личный пример ухода из бизнеса. Однажды неизвестные предложили ему 50 000 долларов за все данные о подключениях его клиента. Возможно, продолжил он, это неприятно удивит адептов сверхзащищенных сервисов «с двойной оберткой» из VPN (Elite VPN, Quad VPN, Double VPN и т.п.), но винчестеры с его серверов были отправлены скорой почтой на следующий же день после получения предложенных денег.

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

Конечно, при условии, если у вашего визави есть реальные возможности и горячее желание вас достать. «Как видите, между США и Россией гораздо больше общего, чем это предполагают многие политики», — ехидно заключил упомянутый анонимный источник.

Мнение типичного обывателя-технаря, не догадывающегося о чарующей и всепроникающей силе больших денег

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

Контуры необъявленной войны против HTTPS

----------------------------------------

Если сопоставить всё сказанное, возвращаясь к загадочной истории с Facebook и ФСБ, запросто читающей чужую защищенную переписку, неизбежно возникает вопрос: а можно ли вообще доверять корневым центрам сертификации сегодня?

К примеру, расположенным на территории РФ, а потому косвенно подчиненных тому же ФСБ РФ? Предлагаем каждому ответить на него самостоятельно. Отметим лишь, что приведенные выше разрозненные факты органично объединяются в рамках этого допущения.

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

Конкретные технические характеристики и теоретическая устойчивость SSL/TLS сегодня меркнут, становясь уделом диспута отдельных «частных» хакеров и других представителей «старой школы», не гнушающихся лобового решения сложных проблем. На уровне же больших игроков — «сормостроителей» — искусство выкручивания рук подручным «кнутом и пряником» достигло невиданных высот и изощрённости.

Как минимум, согласно документам Эдварда Сноудена, в рамках АНБ существовала специальная программа финансирования подкупа разработчиков и компаний, а также обнаружения новых и пока неизвестных ошибок уровня 0day. В частности, в рамках проекта Bullrun на нейтрализацию сильной криптографии, встраивания в известные продукты и библиотеки закладок для спецслужб США, а также на целенаправленное ослабление международных алгоритмов защиты данных в течение 2010 года было потрачено несколько миллиардов долларов. В top-3 по степени приоритетности этой подрывной работы был внесен именно взлом/ослабление протоколов семейства TSL/SSL. Убеждены, что подобные работы ведутся по всему миру, и Америка в этом смысле не уникальна, а выделяется скорее лишь масштабами такой деятельности.

http://blogerator.org/page/eto-sorm-detka-proslushka-2

Популярно о перехвате HTTPS

===========================

August 2013

https://dxdt.ru/2013/08/02/6066/

В связи с ростом интереса к перехвату “всего и вся” структурами 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 также оказывается бесполезным, так как данные могут копироваться вовне до того, как попадут в зашифрованный канал.

Вот.

Скрытое управление пограничными маршрутизаторами

================================================

March 2018

https://dxdt.ru/2018/03/08/8469/

Немного теорий заговора. Сетевого уровня.

----------------------------------------

Маршрутизаторы – эффективное направление атак на сети, которые являются сегментами глобальной Сети. В подавляющем большинстве случаев, если “погасить” несколько умело выбранных маршрутизаторов, сеть падает полностью, несмотря на попытки резервирования, предпринятые при проектировании и построении сегмента. Хрестоматийная ситуация: резервные маршрутизаторы не справляются с изменившейся конфигурацией сети; причин может быть много разных – от возросшего трафика, до невозможности обмена управляющей информацией в результате возникших в сети “штормов”. Например, предполагается, что довольно давний случай с глобальной аварией сети в Сирии был вызван тем, что специалисты АНБ, во время операции по удалённому внедрению (обновлению?) программных закладок, случайно “уронили” ключевой маршрутизатор.

Интересно, как можно обнаруживать подобные действия?

Предположим, доверять маршрутизатору нет оснований, поэтому сразу считаем, что там есть закладки. Естественно, крайний вариант закладки – это продвинутый kill switch, срабатывающий по какой-нибудь последовательности в проходящих через маршрутизатор данных. Обнаружить его до срабатывания – чрезвычайно сложно, поэтому противодействовать не получится. Можно рассчитывать, что нет универсального “выключателя”, поэтому взамен вышедших из строя удастся быстро ввести новые маршрутизаторы. (Наличие подобного инструмента, конечно, вообще выглядит довольно фантастично. Тем не менее, совсем не рассматривать его тоже нельзя.)

С универсальным выключателем – мало что можно сделать. Но возможен более мягкий вариант: наличие несанкционированного удалённого доступа к маршрутизатору (через недокументированные возможности). Такой доступ позволяет управлять настройками и, скажем, выстраивать хитрые логические атаки. Каналы, реализующие доступ, могут быть хорошо замаскированы средствами стеганографии. Быстрый поток там не нужен, достаточно передавать несколько десятков коротких команд в минуту. Поэтому набор транспортов – радует свой широтой. Можно передавать биты “полезной нагрузки” в заголовках пакетов (TCP, IP, UDP и т.п. – выбирайте сами). Для этого нужно знать маршруты и располагать узлами, находящимися по разные стороны от контролируемого маршрутизатора: пакеты должны ходить через маршрутизатор, чтобы процессоры могли считывать недокументированные команды и отвечать на них. Естественно, можно ограничиться и отправкой пакетов только снаружи, лишь бы они достигали маршрутизатора, но вариант с трафиком, проходящим “через пару портов”, гораздо более привлекателен с точки зрения реализации недокументированных возможностей: во-первых, так проще реализовать скрытую обработку (из-за архитектуры маршрутизатора); во-вторых, больше способов отправить ответ. С ответами – вообще отдельная задача. Маршрутизатор не может просто так заменять какие-то параметры в заголовках, допустим, произвольных пакетов – велика вероятность ненамеренно испортить значимые данные, тем самым демаскировав всю операцию. Но зато специально выделенные пакеты – можно заменить (или сгенерировать) полностью, даже вместе с содержимым. Выделить пакеты для связи помогут ранее отправленные команды, сам пакет – будет передан узлом, находящимся за одним из портов, но данные в пакете заменяются маршрутизатором (пакет передаётся для того, чтобы не рисковать поднятием флагов во всяких системах учёта трафика, повсеместно внедрённых – они считают именно пакеты и иногда их длину; впрочем, перекос даже в один процент – вряд ли вызовет подозрения).

IP или, например, UDP, оказываются универсальными в силу того, что работают на общем для всех узлов IP-сети логическом уровне. При этом другие протоколы спускаются на несколько уровней ниже. Так, есть инструменты VLAN (виртуальные сети) и другие логические элементы, невидимые для IP. Связанные с ними протоколы также можно было бы использовать для передачи недокументированных сигналов. Однако из-за того, что свойства даже соседствующих сетей на соответствующих уровнях очень сильно разнятся, тут встречаются трудности. С другой стороны, можно представить ситуацию, когда использование расширений стандарта Ethernet (например) позволяет скрывать от анализаторов трафика, работающих параллельно маршрутизаторам, целый пласт ходящих по физической линии связи данных. Элементарный пример, понятный каждому: представим, что для анализа трафика используется обычный компьютер и Wireshark, но продвинутая сетевая карта – игнорирует часть пакетов, например, обнаружив в заголовке Ethernet некоторый заранее зашитый в процессор карты индекс (заметьте, что такое поведение аналогично штатной функции, позволяющей разграничивать VLAN-ы). Понятно, что Wireshark в таком случае не будет видеть часть трафика, и обнаружить, что видны не все пакеты, вряд ли получится. Конечно, пакеты могло бы прятать и ядро ОС, но аппаратная фильтрация сетевой картой – куда как более эффективна: зафиксировать передачу данных теперь можно только при помощи логического анализатора, подключенного непосредственно к проводам. А вот уже представить себе логический анализатор, который прячет сигналы, гораздо сложнее, чем только что описанную конфигурацию с продвинутой сетевой картой. Но многие ли мониторят сети при помощи логических анализаторов? (Вопрос даже не риторический, а скорее похож на шутку.)

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

Антивирусы и “подмена” сертификатов в браузерах

===============================================

September 2017

https://dxdt.ru/2017/09/14/8403/

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

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

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

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