КриптоПро TLS против BEAST

Публикация: 09 Декабрь 2011 - 13:20, редакция: 30.12.2011 15:30

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

В сентябре 2011 года на конференции Ekoparty в Аргентине была представлена работа Дуонга (Duong) и Риццо (Rizzo), посвящённая практической реализации известной теоретической атаки на протокол SSL/TLS. Инструмент, созданный для проведения атаки, авторы назвали BEAST (Browser Exploit Against SSL/TLS).

Данная атака была предложена Бардом (Bard) за 7 лет до работы Дуонга и Риццо. Она основывается на особенностях режима сцепления блоков шифртекста (CBC) блочных шифров в случае возможности проведения нарушителем атаки с выбором открытого текста при заранее известном значении синхропосылки. Стоит заметить, что уже в этой работе, в дополнение к самому описанию метода криптоанализа, Бард рассматривал возможности применения данного метода и к протоколу TLS. Сама идея предложенного метода криптоанализа режима сцепления блоков шифртекста возникла у Дэя (Dai) ещё раньше — в 2002 году при исследовании протокола SSH.

Атака Барда-Дэя

Напомним, что при работе блочного шифра в режиме сцепления блоков шифртекста фиксируется синхропосылка C0 = IV, имеющая ту же длину, что и длина блока шифра. Затем, для получения каждого блока Ci (i = 1, 2, . . .) шифртекста вычисляется значение Ci=EK(Mi⊕Ci−1), где EK — функция зашифрования блока текста на ключе K. Предположим, нарушитель может осуществлять атаку с выбором открытого текста при известном IV. При этом он подозревает, что для полученного ранее шифртекста C=(C1|C2|...|Cm) некоторый блок Mi открытого текста M = (M1|M2|...|Mm) равен M. Для осуществления атаки нарушитель навязывает отправителю зашифрование сообщения, начальный блок которого равен M'= Ci−1⊕IV⊕M. В этом случае первый блок шифртекста будет равен C' = EK(M'⊕IV) = EK(Ci−1⊕IV⊕M⊕IV) = EK(Ci−1⊕M). Из этого следует, что Mi = M тогда и только тогда, когда C' = Ci.

Таким образом, перебирая различные значения M, нарушитель может узнать содержимое блока открытого текста.

Атака Барда-Дэя на практике: BEAST дешифрует куки-файл, передаваемый по TLS (или как аборигены съели куку)

Целью атаки BEAST является дешифрование куки-файла, передаваемого по защищённому соединению TLS. Действительно, в большинстве случаев информация об аутентификации пользователя на сайте хранится в виде куки-файла в его браузере. Таким образом, получив куки-файл, нарушитель может имперсонировать пользователя.

Как ясно из описания, для осуществления атаки Барда-Дэя нарушителю требуется иметь возможность:

  • читать пакеты в канале связи;
  • получать информацию о значении синхропосылки IV перед зашифрованием;
  • навязывать обладателю ключа блоки данных для зашифрования.

BEAST осуществляет атаку только на протоколы TLS 1.0 и SSL 3.0 (см. ранний вариант работы Дуонга и Риццо), поскольку в этих протоколах при использовании блочных шифров синхропосылкой для очередного пакета выступает последний блок шифртекста предыдущего пакета. Протоколы TLS 1.1 и 1.2 данной атаке не подвержены.

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

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

Версия BEAST, использованная для демонстрации атаки на конференции Ekoparty, для преодоления правил ограничения домена использовала найденную самими авторами уязвимость в виртуальной машине Java. На данный момент уязвимость уже исправлена.

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

Как защититься

Вообще говоря, применение BEAST на практике маловероятно, да и не нужно, исходя из сказанного выше. Так что можно спокойно жить дальше. Если сделать всё-таки что-то хочется, то далее описаны возможные варианты защиты.

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

В протоколах SSL/TLS проблема предсказуемости синхропосылки решена, начиная с версии TLS 1.1. Таким образом, одним из способов защиты является переход на новые версии протокола TLS. Однако, несмотря на то, что спецификация TLS 1.1 была разработана в 2006 году, поддержка этого протокола в современных распространённых браузерах и веб-серверах ограничена.

Другим возможным способом защиты является отказ от использования блочных шифров в SSL/TLS в пользу поточных. Например, набор алгоритмов шифрования TLS_RSA_WITH_RC4_128_SHA реализован во многих продуктах, и переход на него, скорее всего, не создаст проблем совместимости.

Российских пользователей, использующих сертифицированные СКЗИ, наверняка интересует, уязвимы ли российские реализации протокола TLS на основе алгоритма шифрования ГОСТ 28147-89 к данной атаке. В модуле КриптоПро TLS, входящем в СКЗИ КриптоПро CSP, изначально использовалось шифрование по ГОСТ 28147-89 в режиме гаммирования, т.е. поточный шифр. Кроме того, аналогом синхропосылки для шифрования очередного пакета в этом режиме является состояние регистров шифратора после обработки предыдущего пакета, и это состояние остаётся неизвестным нарушителю. Таким образом, КриптоПро CSP и совместимые с ним реализации протокола TLS неуязвимы к данному классу атак.

В следующих статьях блога мы планируем обсуждение других уязвимостей протокола TLS. Следите за обновлениями!

Беляев Анатолий
Гилязов Руслан
Леонтьев Сергей
Попов Владимир
Смирнов Павел
Смышляев Станислав