ноябрь    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 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

21.11.2024

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

Читать далее 

18.11.2024

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

Читать далее 

14.10.2024

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

Читать далее 

11.10.2024

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

Читать далее 

28.09.2024

Чем страшен ИИ, и с чем его едят

Читать далее 

13.06.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

показать все 

Главная / Архив номеров / 2014 / Выпуск №4 (37) / Это СОРМ, детка. Часть 2

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

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

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

Финансовые спецоперации по дискредитации и нейтрализации протоколов TLS/SSL против прямой криптографической атаки: что эффективнее?

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

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

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

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

В своем пресс-релизе Trustwave в меру доступной ей политкорректности пытался донести до ИТ-специалистов простую мысль, что дело это «обычное и распространенное», «все так делают». В чем вообще проблема?

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

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

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

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

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

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

Минутка безопасности

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

• SecureTrust CA [CRL]
• Secure Global CA [CRL]
• XRamp Global Certification Authority [CRL]
• XRamp Security Services GS CA [CRL]

Trustwave Holdings – частная американская компания, специализирующаяся на услугах в области информационно-сетевой безопасности. Удерживает 6% мирового рынка SSL-сертификации, имеет клиентов в 96 странах мира, ее офисы открыты в Чикаго, Сан-Пауло, Лондоне и Сиднее. Имеет собственные сервисы и программные продукты, связанные с сетевой безопасностью и аудитом корпоративных данных/сетей.

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

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

Аналогичные вещи творятся и на стороне системообразующего криптографического софта. В прошлый раз [1] я рассказывал о скандальной ситуации вокруг известных продуктов 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. Как видно, не мытьем, так катаньем, роль защищенных протоколов ради достижения «невинных целей» будет последовательно сводиться к нулю на самых разных уровнях: от их проектирования до реализации.

«Бабло побеждает зло»

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

Если сопоставить все сказанное, возвращаясь к загадочной истории с Facebook и ФСБ, запросто читающему чужую защищенную переписку (которую я изложил в качестве затравки в первой части этой статьи [1]), практически сам собой встает вопрос: а можно ли вообще доверять корневым центрам сертификации сегодня? К примеру, расположенным на территории РФ, а потому косвенно подчиненных тому же ФСБ РФ?

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

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

Лично я убежден, что подобные работы ведутся по всему миру, и Америка в этом смысле не уникальна, а выделяется скорее лишь масштабами такой деятельности.

Хронология затяжной войны против HTTPS

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

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

BEAST (2002 год)

Тхай Дыонг (Thai Duong) и Джулиано Риццо (Juliano Rizzo), известные исследователи компьютерной безопасности, публично представили в сентябре 2002 года новую концепцию атаки на SSL/TLS, которую назвали громким именем – BEAST (расшифровывается как Browser Exploit Against SSL/TLS).

Данная уязвимость поражала главным образом TLS 1.0, при этом она возможна лишь при использовании режима CBC в комбинации с AES. Эксплуатация этой бреши требует реализации дополнительного механизма контроля за передаваемым через SSL трафиком. Например, в браузере Chrome это может быть API WebSockets (поддержка которого там по умолчанию активирована) либо через использование стандартных функций таких плагинов, как Java.

На самом деле это достаточно сложный в организации метод, и многие специалисты по безопасности поспешили заявить, что это «исключительно теоретическая возможность». Эти скептические нападки «завели» первооткрывателей бага, потративших еще 10 лет, чтобы создать полностью рабочий эксплойт, который и продемонстрировали на конференции Ekoparty в 2011 году. Там у всех на виду они провели демонстрацию перехвата/дешифровки передаваемого в рамках зашифрованного соединения Cookie с параметрами аутентификации пользовательской сессии платежного сервиса PayPal. Это была первая успешная публичная атака против самых распространенных в то время протоколов – TLS 1.0 и SSL 3.0.

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

Во-первых, еще за семь лет до релиза эксплоита упомянутыми Дыонгом и Риццо, аналогичный тип атаки был детально описан Грегори Бардом (Gregory V. Bard). В качестве атакуемой цели в своей работе он рассматривал как раз протокол TLS. При этом он ссылался на практическое исследование Дэя (W. Dai) из проекта NetBSD от 2002 года, где описывается сложный метод атаки против SSH2.

Во-вторых, в том же 2002 году на конференции Eurocrypt был представлен доклад Сержа Воденеева (S. Vaudenay), в котором описывалась несколько иная методика атаки на TLS/SSL, впрочем, использующая аналогичные уязвимости режима CBС. Принципиальным здесь является то, что Воденеев сформулировал более общий метод атаки, который нацелен сразу на сонм из протоколов: как на TLS/SSL, так и на производные от них – IPSec, WTLS, SSH2 и др.

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

CRIME (2012 год)

Это свежий сиквел BEAST от тех же авторов – очередная стратегия обхода средств защиты, добавленных производителями браузеров для блокирования BEAST. Базируется на старых идеях и, как видно из названия CRIME (Compression Ratio Info-leak Made Easy), применима лишь при использовании опции сжатия передаваемых данных. Суть атаки сводится к простому факту: поток сжимается браузером на этапе до шифрования, в силу чего не подвергается дополнительной рандомизации, что и делает в итоге теоретически возможным перехват сессионных Cookie.

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

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

TLS Timing или Lucky Thirteen (2013 год)

Вариация на базе вышеописанных атак, в основе которой лежит криптографическая timing-атака. Под ударом опять режим шифрования CBC в реализациях протоколов SSL, TLS и DTLS (к проблемным можно отнести, например, такие известные библиотеки, как OpenSSL, GnuTLS, PolarSSL, OpenJDK, CyaSSL, MatrixSSL, yaSSL и NSS). Суть этой атаки сводится к перехвату трафика (MiTM), в котором атакующий «на лету» подменяет несколько последних оригинальных блоков на свои собственные подставные, при этом измеряя время реакции сервера. Дело в том, что любой полученный сервером зашифрованный блок обрабатывается заметно быстрее, если он заполнен корректно, и наоборот.

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

BREACH (2013 год)

BREACH – это относительно новый вид атаки на HTTPS, впервые обнародованный на конференции Black Hat 2013. Название расшифровывается как Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext. Это незначительная вариация метода CRIME, позволяющая в очередной раз обойти меры противодействия предыдущим атакам. На этот раз злоумышленниками анализируются особенности изменения потока при сжатии протокола HTTP, а не при сжатии на уровне TLS/SSL, как это было в случае с CRIME. Но, несмотря на то что атакуется именно сжатый HTTP, BREACH сфокусирован исключительно против TLS, который является всего-навсего криптографической «оберткой» поверх обычного HTTP.

Если для защиты от CRIME специалисты предлагают отключить сжатие в TLS/SSL, то в случае с BREACH рекомендуется дополнительно отключить и режим gzip/deflate на уровне HTTP. В продолжение несколько странной для меня логики подобных советов от некоторых специалистов ИБ можно в шутку порекомендовать «не рубить хвост кота по частям» и сразу отключить сам веб-сервер, чтобы одним махом предотвратить и все остальные виды атак. Если же говорить серьезно, то, поскольку BEAST, Lucky13 и CRIME/BREACH используют общую схему атаки, предлагаю далее в образовательных целях обобщить единую структуру этих уязвимостей.

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

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

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

AlFBPPS (2013 год)

Данный метод атаки полностью сосредоточен на шифре RC4, который часто применяется в протоколе TLS. Несмотря на то что в той же популярной библиотеке OpenSSL доступно множество альтернативных шифров (например, AES, Blowfish, DES, Triple-DES и т.д.), а сам RC4, по мнению некоторых экспертов, уже устарел, беспристрастная статистика показывает, что RC4 сегодня применяется примерно в половине всего мирового TLS-трафика. В данной атаке используются все те же «внедренные» строки-метки, которые после огромного количества повторений позволяют уверенно выявлять их в зашифрованном пакете, попутно атакуя остальные соседние данные. Иначе говоря, рандомизация у RC4, разработанного в 1987 году RSA, оказалась не такая уж идеальная, как это казалось специалистам первоначально.

Эта методика впервые была представлена публично на конференции Fast Software Encryption 2013 в Сингапуре одним из ее разработчиков – Дэном Берштейном (Dan Bernstein), профессором Иллинойсского университета в Чикаго. Несмотря на то что тогда ему потребовалось 32 часа и миллионы итераций HTTPS-запросов для осуществления взлома, впоследствии алгоритм атаки был оптимизирован и ускорен.

По иронии судьбы за несколько лет до релиза этой методики наделавшая шуму BEAST мотивировала массовую миграцию с CBC на RC4 в качестве надежной защиты от взломов типа BEAST/Lucky13, ощутимо подстегнув популярность именно этого шифра. В результате на данный момент по разным замерам около 50-60% всех мировых сайтов использует RC4 для инициализации своих HTTPS-соединений. Отсюда очевидно, что хак TLS/RC4 упал на очень благодатную почву, исследователям еще предстоит до конца осознать его опасность.

Разработчики этого метода решили не придумывать страшные названия и окрестили эту методику взлома по первым буквам фамилий ее исследователей: AlFardan-Bernstein-Paterson-Poettering-Schuldt – AlFBPPS.

***

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

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

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

1. Савчук И. Это СОРМ, детка. Часть 1. //Спецприложение «БИТ. Бизнес & информационные технологии», №1, 2014 г. – С. 8-11 (http://bit.samag.ru/archive/article/1336).

В начало⇑

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

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