ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2014 / Выпуск №1 (34) / Это СОРМ, детка. Часть 1. Возможности современных средств шифрования

Рубрика: Тема номера /  Технологии безопасности

Игорь Савчук, работает в CoreLink Datacenter. Программист с 12-летним стажем. Автор более 200 опубликованных в печатной прессе статей по ИТ-тематике

Это СОРМ, детка
Часть 1. Возможности современных средств шифрования

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

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

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

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

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

И тут – вуаля! – ФСБ в исполнении решения суда самостоятельно «добывает» переписку этих граждан. Приведу цитату из судебного протокола полностью: «ЦИБ ФСБ в соответствии с Законом «Об оперативно-розыскной деятельности» осуществил самостоятельный съем информации с каналов связи указанных лиц и записал ее на DVD-диск».

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

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

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

Прямые вопросы к представителям ФСБ последние проигнорировали. Наиболее очевидная версия ответа напрашивалась сама: HTTPS-трафик с данной перепиской был заранее сохранен ФСБ и каким-то образом впоследствии взломан. Эксперты, не желая верить в «прослушку HTTPS-трафика», развели бурную дискуссию, выдвигая разные альтернативные версии того, как это можно было сделать иначе. Например, популярна гипотеза, что здесь было применено восстановление чужого аккаунта на Facebook с использованием перехвата SMS/Callback на телефон подследственного в рамках стандартной процедуры восстановления пароля. А уж в том, что ФСБ могло перехватить данные SMS, заведомо ожидая их, сомнений ни у кого нет.

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

Спецслужбы против HTTPS

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

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

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

Modus Operandi

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

На первом моменте не будем сильно заморачиваться, уверен, что физический доступ к любым каналам у спецслужб есть (разработчики СОРМ не дадут мне соврать). Если же говорить о прослушке HTTPS-сессий, то сразу отметим важный момент – это обязательность «активного режима» прослушивания в некоторых случаях, потому что сохраненный трафик не всегда может быть взломан позже.

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

Это была хорошая новость, но на подходе плохая: Facebook, равно как и большинство других крупных порталов, не использует режим forward secrecy просто потому, что он создает сильную нагрузку для и так перегруженной социальной махины, также затормаживая соединения, удлиняя по времени установку соединения.

И, наконец, использование подобных продвинутых DH-алгоритмов может негативно влиять на совместимость с некоторыми популярными браузерами.

Теперь легко понять, почему согласно статистике Netcraft [3] по состоянию на лето 2013-го примерно 70-99% наблюдаемых в рамках этого мониторинга SSL-соединений вообще не использовали FS.

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

Согласно этому же исследованию один из наиболее продвинутых браузеров для поддержки DH/FS – последние версии Opera, один из худших – MSIE. Лучший веб-сервер в этом же плане – наш отечественный nginx, среди мировых интернет-сервисов специалисты выделили компанию Google, сервисы которой поддерживают практически все инновации и средства защиты своих пользователей. В частности, эта компания реализует недолговечные («эфемерные») сеансовые ключи ECDHE_RSA – это образцовый вариант Perfect Forward Secrecy.

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

Что касается упомянутой базы данных из серверных ключей, то еще летом 2013 года издание Cnet опубликовало [4] информацию и документ – пример запроса АНБ в адрес крупной интернет-компании, пожелавшей остаться неизвестной. Согласно этому источнику такие же запросы получали в свой адрес и другие крупные интернет-площадки, такие как Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T, Fastmail.fm, Time Warner Cable, Comcast и так далее. Cnet официально обратилось в эти организации с просьбой прокомментировать факт подобного запроса в их адрес, но в подавляющем большинстве случаев компании отказались как подтвердить, так и опровергнуть подобное взаимодействие с АНБ.

В приведенном документе [4] речь шла о безусловном требовании предоставить в распоряжение АНБ доступ к закрытым ключам SSL/TLS этих популярных веб-ресурсов (SSL/TLS master encryption keys), выдать базы данных с хешами паролей всех пользователей и информацию о применяемых методах хеширования. Интересно, что совсем другой источник – Эдвард Сноуден – год спустя полностью подтвердил существование информационной базы АНБ, содержащей актуальные SSL/TLS-ключи крупнейших и наиболее популярных веб-ресурсов мира. Повторюсь, это позволяет прозрачно дешифровать любой HTTPS-трафик, связанный с этими сайтами и социальными сетями.

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

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

В качестве наиболее яркого примера из череды подобных инцидентов можно привести недавнее сообщение агентства Reuters [5], которое приводит документальные факты того, что широко известная криптографическая компания RSA Security на протяжении нескольких лет сотрудничала с АНБ. Согласно их двухстороннему контракту в криптографических продуктах RSA предпочтение должно было отдаваться алгоритму генератора псевдослучайных чисел (ГПСЧ) Dual EC DRBG. Как теперь известно, последний не только содержит скрытую уязвимость, но и стал самым популярным в мире ГПСЧ, например, именно его реализация применяется в Windows, OpenSSL и других известных проектах. Бэкдор встроен непосредственно в генератор случайных чисел – это универсальный и чрезвычайно удобный механизм избирательного снижения стойкости криптосистем, который никак не нарушает совместимость, не содержит никаких явных закладок в коде, имея лишь абстрактную математическую уязвимость в своем алгоритме. В этом случае на стороне атакующих вместо брутфорса можно использовать заранее просчитанную конечную последовательность псевдослучайных чисел. Возвращаясь к отечественным стандартам, в связи с этим замечу, что согласно ГОСТ 28147-89 таблицы замен вместе с сертификацией устройства/программы выдает непосредственно ФСБ. Очевидно, что от качества генерации такой таблицы зависит общая стойкость шифрования. Получается этакая государственно-зависимая криптография…

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

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

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

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

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

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

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

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

• Примерно 6% TLS-соединений и 7% SSH-соединений использовали небезопасный механизм обмена своими публичными ключами, вызванный главным образом недостаточной рандомизацией при генерации ключей (или со стороны исходных дефолтных ключей).
• В силу этого данному любительскому проекту удалось удаленно заполучить частные ключи RSA почти для 1% TLS-соединений и для 0,03% SSH-соединений.
• Проект смог удаленно заполучить частные ключи DSA для более 1% всех SSH-соединений по этим же причинам.
• Подчеркивается, что процент слабозащищенного трафика существенно больше указанного: выше приведены лишь цифры, по которым проект имел готовые методики атак, если же говорить о потенциально опасных долях, то их процент выше – под ударом находится 6-7% от всех HTTPS-соединений и более 10% от всех SSH-подключений в мире.
• Резюмируем главное: обнаружено, что большое число TLS-ключей имеет общие простые множители, то есть их факторизация заметно упрощена. Отметим при этом, что серверные ключи традиционно существуют в неизменном виде годами, их редко когда меняют. Поэтому с большой степенью вероятности можно предположить, что как минимум треть защищенного трафика в мире сгенерирована криптографическими средствами с ослабленным (заведомо?) ГПСЧ.

Кстати говоря, этот же проект любезно предлагает проверить устойчивость вашего публичного ключа (public SSH host key или TLS certificate) на их бесплатном онлайн-сервисе [9].

Промежуточный вывод

В заключение к первой части статьи сформулирую промежуточный вывод. Подобно тому, как даже обновленный антивирус не может гарантировать 100% защиту компьютера, а только лишь в состоянии усложнить жизнь хакерам-злоумышленникам, так и современные средства шифрования уже не могут гарантировать полную приватность передаваемых данных, а только отчасти усложняют жизнь тем же АНБ, ФСБ и другим спецслужбам.

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

***

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

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

1. Уголовное дело о DDoS-атаке против «Аэрофлота» – http://www.gazeta.ru/business/2011/06/25/3675597.shtml, http://roem.ru/2013/06/19/addednews74095.
2. Forward Secrecy – http://ru.wikipedia.org/wiki/Perfect_forward_secrecy, http://habrahabr.ru/post/133268.
3. Статистика Netcraft SSL survey 2013 – http://www.netcraft.com/internet-data-mining/ssl-survey.
4. ФБР и АНБ требуют доступ к мастер-ключам SSL/TLS популярных веб-ресурсов – http://www.itsec.ru/newstext.php?news_id=93711, http://www.opennet.ru/opennews/art.shtml?num=37511.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи