Лекция
Это окончание невероятной информации про криптоанализ.
...
(открытый текст). Несмотря на аналогию, это несколько необычная ситуация по сравнению с другими атаками оракула, которые мы видели.
Чтобы проиллюстрировать, как такая атака может работать, используем вымышленную схему сжатия, которую мы только что придумали: TOYZIP. Он ищет строки текста, которые уже появлялись ранее в тексте, и заменяет их тремя байтами-заполнителями, которые указывают, где найти более ранний экземпляр строки и сколько раз он там встречается. Например, строка helloworldhello может быть сжата в helloworld[00][00][05] длиной 13 байт по сравнению с оригиналом 15-ти байт.
Предположим, взломщик пытается восстановить открытый текст формы password=..., где сам пароль неизвестен. В соответствии с моделью атаки Келси, взломщик может попросить сервер сжать, а затем зашифровать сообщения формы (открытый текст, за которым следует X), где X — произвольный текст. Когда сервер закончил работу, он сообщает длину результата. Атака идет следующим образом:
Взломщик: Пожалуйста, сожми и зашифруй открытый текст без каких-либо заполнений.
Сервер: Длина результата 14.
Взломщик: Пожалуйста, сожми и зашифруйте открытый текст, к которому добавлено password=a.
Сервер: Длина результата 18.
Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=] + a
Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=b.
Сервер: Длина результата 18.
Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=с.
Сервер: Длина результата 17.
Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=c]. Это предполагает, что оригинальный открытый текст содержит строку password=c. То есть пароль начинается с буквы c
Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=сa.
Сервер: Длина результата 18.
Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=с] + a
Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=сb.
Сервер: Длина результата 18.
(… некоторое время спустя…)
Взломщик: Пожалуйста, сожми и зашифруй открытый текст, к которому добавлено password=со.
Сервер: Длина результата 17.
Взломщик отмечает: [оригинал 14] + [три байта, которые заменили password=co]. По той же логике взломщик делает вывод, что пароль начинается с букв co
И так далее до тех пор, пока не будет восстановлен весь пароль.
Читателю простительно думать, что это чисто академическое упражнение и такой сценарий атаки никогда не возникнет в реальном мире. Увы, как мы вскоре увидим, в криптографии лучше не зарекаться.
Наконец, после подробного изучения теории, мы можем посмотреть, как эти методы применяются в реальных криптографических атаках.
Если атака нацелена на браузер и сеть жертвы, что-то будет проще, а что-то — сложнее. Например, увидеть трафик жертвы легко: достаточно сидеть с ней в одном и том же кафе с WiFi. По этой причине потенциальным жертвам (т. е. всем) обычно рекомендуется использовать зашифрованное соединение. Будет посложнее, но все равно возможно, выполнение HTTP-запросов от имени жертвы на какой-то сторонний сайт (например, Google). Злоумышленник должен заманить жертву на вредоносную веб-страницу со скриптом, который сделает запрос. Веб-браузер автоматически предоставит соответствующую сеансовую куку.
Это кажется удивительным. Если Боб зашел на evil.com, неужели скрипт на этом сайте может просто попросить Google отправить пароль Боба по электронной почте на attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), и он был популярен примерно в середине 90-х. Сегодня, если evil.com попробует такой трюк, Google (или любой уважающий себя сайт) обычно ответит: «Отлично, но ваш токен CSRF для этой транзакции будет… ммм… три триллиона и семь. Пожалуйста, повторите это число». Современные браузеры применяют нечто под названием «политика одинакового происхождения» (same-origin policy), согласно которой скрипты на сайте A не получают доступа к информации, отправленной веб-сайтом B. Поэтому скрипт на evil.com может отправлять запросы к google.com, но не может прочитать ответы или на самом деле завершить транзакцию.
Мы должны подчеркнуть, что если Боб не использует зашифрованное соединение, все эти защиты бессмысленны. Взломщик может просто прочитать трафик Боба и восстановить сеансовую куку Google. С этой кукой он просто откроет новую вкладку Google, не выходя из собственного браузера, и выдаст себя за Боба, не встречаясь с досадными политиками same-origin policy. Но, к сожалению для взломщика, такое встречается все реже. Интернет в целом давно объявил войну незашифрованным соединениям, и исходящий трафик Боба, вероятно, зашифрован, нравится ему это или нет. Кроме того, с самого начала внедрения протокола трафик также сжимался перед шифрованием; это была обычная практика для уменьшения задержки.
Здесь в игру вступает CRIME (Compression Ratio Infoleak Made Easy, простая утечка через коэффициент сжатия). Уязвимость, которую показали в сентябре 2012 года исследователи безопасности Джулиано Риццо (Juliano Rizzo) и Тай Дуонг (Thai Duong). Мы уже разобрали всю теоретическую базу, которая позволяет понять, что они сделали и как. Взломщик может заставить браузер Боба отправлять запросы в Google, а затем прослушивать ответы в локальной сети в сжатом, зашифрованном виде. Поэтому у нас есть:
Здесь взломщик контролирует запрос и имеет доступ к сниферу трафика, включая размер пакетов. Вымышленный сценарий Келси воплотился в жизнь.
Понимая теорию, авторы CRIME создали эксплоит, который может украсть сеансовые куки для широкого спектра сайтов, включая Gmail, Twitter, Dropbox и Github. Уязвимость затронула большинство современных веб-браузеров, в результате чего были выпущены патчи, которые молча похоронили функцию сжатия в SSL, чтобы она вообще не использовалась. Единственным защищенным от уязвимости стал почтенный Internet Explorer, который вообще никогда не использовал сжатие SSL.
В октябре 2014 года команда безопасности Google навела шороху в сообществе безопасности. Они смогли эксплуатировать уязвимость в протоколе SSL, исправленную более десяти лет назад.
Оказалось, что хотя на серверах работает замечательный новенький TLSv1.2, многие оставили поддержку устаревшего SSLv3 ради обратной совместимости с Internet Explorer 6. Мы уже говорили об атаках на понижение, так что можете представить себе происходящее. Хорошо организованный саботаж протокола рукопожатия — и серверы готовы вернуться на старый добрый SSLv3, по сути отменив последние 15 лет исследований в сфере безопасности.
Для исторического контекста, вот краткое резюме истории SSL вплоть до версии 2 от Мэтью Грина:
Transport Layer Security (TLS) — самый важный протокол безопасности в интернете. [..] почти каждая транзакция, которую вы проводите в интернете, зависит от TLS. [..] Но TLS не всегда был TLS. Протокол начал свою жизнь в Netscape Communications под названием "Secure Sockets Layer" или SSL. Ходят слухи, что первая версия SSL оказалась настолько ужасной, что разработчики собрали все распечатки кода и закопали на секретной свалке в Нью-Мексико. Как следствие, первая общедоступная версия SSL на самом деле является версией SSL 2. Она довольно страшненькая, и [..] это был продукт середины 90-х, которые современные криптографы рассматривают как «темные века криптографии». Многие из самых отвратительных криптографических атак, о которых мы знаем сегодня, еще не были обнаружены. В результате разработчикам протокола SSLv2 пришлось по существу нащупывать путь в темноте, и они столкнулись с множеством ужасных монстров — к их огорчению и нашей выгоде, поскольку атаки на SSLv2 оставили бесценные уроки для следующего поколения протоколов.
После этих событий, в 1996 году, разочарованная компания Netscape переработала протокол SSL с нуля. Результатом стал SSL версии 3, который исправил несколько известных проблем безопасности своего предшественника.
К счастью для взломщиков, «несколько» не означает «все». В целом, SSLv3 предоставлял все необходимые строительные блоки для запуска атаки Воденэ. Протокол использовал блочный шифр в режиме CBC и небезопасную схему заполнения (это исправили в TLS; следовательно, возникла необходимость в атаке на понижение). Если вы помните схему заполнения в нашем первоначальном описании атаки Воденэ, схема SSLv3 очень похожа.
Но, к несчастью для взломщиков, «похожая» не означает «идентичная». Схема заполнения SSLv3 имеет вид «N произвольных байт, за которыми следует число N». Попробуйте в таких условиях выбрать воображаемый блок зашифрованного текста и пройти через все этапы оригинальной схемы Воденэ: вы обнаружите, что атака успешно извлекает последний байт из соответствующего блока открытого текста, но дальше не проходит. Расшифровка каждого 16-го байта зашифрованного текста — отличный фокус, но это не победа.
Столкнувшись с неудачей, команда Google прибегла к крайнему варианту: они переключились на более мощную модель угроз — ту, которая использовалась в CRIME. Если предположить, что злоумышленник — это скрипт, запущенный на вкладке браузера жертвы, и он может извлечь сеансовые куки, атака все равно остается впечатляющей. Хотя более широкая модель угроз менее реалистична, но в предыдущем разделе мы уже видели, что эта конкретная модель осуществима.
Учитывая такие более мощные возможности взломщика, теперь атака может продолжиться. Учтите, что злоумышленник знает, где в заголовке отображается зашифрованный сеансовый файл куки, и управляет длиной предшествующего ему HTTP-запроса. Поэтому он способен манипулировать HTTP-запросом так, чтобы выровнять последний байт куки в соответствии с концом блока. Теперь этот байт подходит для расшифровки. Можно просто добавить к запросу один символ, а предпоследний байт куки останется на том же месте и пригоден для подбора тем же методом. Атака продолжается таким образом, пока файл куки не будет восстановлен полностью. Это называется POODLE: Padding Oracle on Downgraded Legacy Encryption, заполняющий оракул на пониженном устаревшем шифровании.
Как мы уже упоминали, у SSLv3 были недостатки, но он кардинально отличался от предшественника, поскольку дырявый SSLv2 представлял собой продукт другой эпохи. Там можно было прервать сообщение на середине: соглашусь на это только через мой труп превращалось в соглашусь на это; клиент и сервер могли встретиться в интернете, установить доверие и обменяться секретами перед глазами злоумышленника, который потом легко выдавал себя и за того, и за другого. Еще и проблема с экспортной криптографией, которую мы упомянули при рассмотрении FREAK. Это были криптографические Содом и Гоморра.
В марте 2016 года команда исследователей из разных технических областей собралась вместе и сделала поразительное открытие: SSLv2 по-прежнему используется в системах безопасности. Да, злоумышленники больше не могли понижать современные сеансы TLS до SSLv2, поскольку эту дыру закрыли после FREAK и POODLE, но они все еще могут подключаться к серверам и инициировать сеансы SSLv2 самостоятельно.
Вы спросите, какое нам дело, что они там делают? У них уязвимый сеанс, но это не должно влиять на другие сеансы или безопасность сервера — правильно? Ну, не совсем. Да, так и должно быть в теории. Но нет — потому что генерация сертификатов SSL накладывает определенное бремя, в результате чего многие серверы используют одни и те же сертификаты и, как следствие, одни и те же ключи RSA для соединений TLS и SSLv2. Что еще хуже, из-за бага OpenSSL в этой популярной реализации SSL фактически не работала опция «Отключить SSLv2».
Это сделало возможной кросс-протокольную атаку на TLS, которую назвали DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, расшифровка RSA с помощью устаревшего и ослабленного шифрования). Напомним, что это не то же самое, что атака на понижение; взломщику не нужно действовать как «человек в середине» и не нужно вовлекать клиента для участия в небезопасном сеансе. Злоумышленники просто сами инициируют небезопасный сеанс SSLv2 с сервером, атакуют слабый протокол и восстанавливают закрытый серверный ключ RSA. Этот ключ также действителен для соединений TLS, и с этого момента никакая безопасность TLS не спасет его от взлома.
Но для взлома нужна рабочая атака против SSLv2, которая позволяет восстановить не только конкретный трафик, но и секретный серверный ключ RSA. Хотя это и сложная постановка, но исследователи могли выбрать любую уязвимость, которую полностью закрыли после SSLv2. В конечном итоге они нашли подходящий вариант: атака Блайхенбахера, о которой мы упоминали ранее и которую подробно объясним в следующей статье. SSL и TLS защищены от этой атаки, но некоторые случайные функции SSL в сочетании с короткими ключами в криптографии экспортного класса, сделали возможным определенную реализацию DROWN.
На момент публикации уязвимости DROWN были подвержены 25% топ-сайтов интернета, и атаку можно было провести со скромными ресурсами, доступными даже для озорных хакеров-одиночек. Для извлечения ключа RSA сервера требовалось восемь часов вычислений и $440, а SSLv2 сменил статус с «устаревшего» на «радиоактивный».
Это не криптографическая атака в том смысле, как описанные выше; это переполнение буфера.
Мы начали с некоторых базовых методов: брутфорс, интерполяция, понижение, кросс-протокол и предвычисления. Затем рассмотрели одну продвинутую технику, возможно, главный компонент современных криптографических атак: это атака оракула. Мы довольно долго с ней разбирались — и поняли не только принцип в основе, но и технические детали двух конкретных реализаций: атаки Воденэ на режим шифрования CBC и атаки Келси на протоколы шифрования с предварительным сжатием.
При обзоре атак на понижение и с предварительными вычислениями мы кратко изложили атаку FREAK, которая использует оба метода, поскольку целевые сайты опускаются до слабых ключей, а затем повторно используют одни и те же ключи. Для следующей статьи мы оставили (очень похожую) атаку Logjam, которая нацелена на алгоритмы с открытым ключом.
Затем мы рассмотрели еще три примера применения этих принципов. Во-первых, CRIME и POODLE: две атаки, которые полагались на способность взломщика внедрять произвольный открытый текст рядом с целевым открытым текстом, потом изучать ответы сервера и затем, используя методологию атаки оракула, использовать эту скудную информацию для частичного восстановления открытого текста. CRIME пошла по пути атаки Келси на сжатие SSL, в то время как POODLE вместо этого использовал вариант атаки Воденэ на CBC с тем же эффектом.
Затем мы обратили внимание на кросс-протокольную атаку DROWN, которая устанавливает с сервером соединение по устаревшему протоколу SSLv2, а потом восстанавливает секретные серверные ключи с помощью атаки Блайхенбахера. На данный момент мы пропустили технические детали этой атаки; как и Logjam, ей придется подождать, пока мы хорошенько не изучим криптосистемы с открытым ключом и их уязвимости.
Выводы из данной статьи про криптоанализ указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое криптоанализ, атаки на систему шифрования и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Криптография и криптоанализ, Стеганография и Стегоанализ
Часть 1 Криптоанализ, Атаки на систему шифрования
Часть 2 Интерполяция - Криптоанализ, Атаки на систему шифрования
Часть 3 Брендовые уязвимости: CRIME, POODLE, DROWN - Криптоанализ, Атаки на систему
Комментарии
Оставить комментарий
Информационная безопасность- Криптография и криптоанализ, Стеганография и Стегоанализ
Термины: Информационная безопасность- Криптография и криптоанализ, Стеганография и Стегоанализ