Компания
908,05
рейтинг
21 октября 2014 в 17:10

Разработка → Этот пудель кусается: использование дыр в протоколе SSL 3.0



Интересующиеся веб-безопасностью хабражители уже в курсе очередной уязвимости в SSL, именуемой POODLE. Мы подробно рассмотрим, что же собой представляет эта уязвимость и каким именно образом позволяет злоумышленнику добраться до, казалось бы, защищенных данных пользователя, а также расскажем, как с этим зверем справилась команда Mail.Ru Group.

Исчерпывающее объяснение механизма использования POODLE приводится в статье This POODLE Bites: Exploiting The SSL 3.0 Fallback; ниже мы приводим перевод этой статьи.

Тем же, кого не слишком интересуют детали деятельности зловредного пса, напомним, что POODLE – это уязвимость в SSL 3, старой версии протокола, доживающей второй десяток. Существует два способа борьбы с уязвимостью:
  • Поставить на сервер патч, запрещающий в процессе хэндшейка откатываться на SSL3 при невозможности подключиться по TLS. Загвоздка в том, что такой метод работает, только если патч стоит и на сервере, и на клиенте. В настоящее время это реализовано только у Google Chrome (начиная с февраля 2014 года) и планируется в ближайшем обновлении Firefox. Получается, что обеспечение безопасности пользователей в определенной мере ложится на плечи самих пользователей.
  • Отключить SSL 3 на серверах, да и дело с концом. Просто и элегантно, но есть одно «но». Большая часть браузеров использует TLS версии 1.0 и выше, однако в мире все еще остались люди, не готовые расстаться с наследием прошлого, именуемым Internet Explorer версии 6, который просто не поддерживает новые версии протокола в конфигурации по умолчанию.

Наша статистика показывает, что через IE6 в Почту Mail.Ru заходят 0,2% пользователей. И, хотя в абсолютных величинах это не такая уж маленькая цифра, мы считаем, что безопасность — прежде всего. Поэтому мы отключили возможность соединения с клиентом по SSL3 в Почте, Облаке, Календаре, авторизационном центре и «Mail.Ru для бизнеса».

Для пользователей IE6 это означает, что Почта Mail.Ru, равно как и другие сервисы, выбравшие такой способ борьбы с POODLE, больше не будут им доступны. Вряд ли среди аудитории Хабра много приверженцев IE6, но советуем убедиться, что ваши родственники и друзья, не слишком дружащие с современными технологиями, обновили свои браузеры.

В случае с сервисами, которые предпочли первый способ защиты от уязвимости, если вы – пользователь Chrome, регулярно обновляющегося автоматически, – поздравляем, вы защищены. Если же вы предпочитаете другие браузеры, рекомендуем пользоваться свежим Chrome по крайней мере при доступе к общественному Wi-Fi, ведь именно в этом случае вы уязвимы. Почему именно тогда? Об этом можно узнать из предложенного ниже перевода.

SSL 3.0 [RFC6101] — это устаревший и небезопасный протокол. При решении большинства практических задач его уже заменили преемники, протоколы TLS 1.0 [RFC2246], TLS 1.1 [RFC4346] и TLS 1.2 [RFC5246], однако в них сохраняется обратная совместимость с SSL 3.0 для взаимодействия со старыми системами. Это позволяет избежать проблем с клиентскими устройствами при внедрении новых версий протоколов на серверах.

Но даже если и клиент, и сервер поддерживают TLS, то уровень безопасности в SSL 3.0 — вопрос все еще актуальный, поскольку многие клиенты применяют более старые протоколы, чтобы справляться с багами совместимости с серверами. И здесь мы хотели бы обсудить, как злоумышленники могут использовать эту ситуацию и взламывать протокол SSL 3.0. Речь пойдёт о POODLE-атаке (Padding Oracle On Downgraded Legacy Encryption), благодаря которой можно, например, перехватывать Secure HTTP-куки или содержимое заголовков HTTP-авторизации.

Мы также порекомендуем, какие нужно принять меры на клиентах и серверах, чтобы противостоять подобной атаке. Если простое отключение SSL 3.0 вам не подходит по причинам совместимости, то в имеющихся версиях TLS нужно использовать TLS_FALLBACK_SCSV.

Описание POODLE-уязвимости

Для обеспечения совместимости со старыми версиями серверов многие TLS-клиенты используют downgrade dance: сначала делается попытка установления связи по протоколу последней версии. Если связь не устанавливается, делается новая попытка, но уже по более старому протоколу. В отличие от нормальной процедуры определения версии, поддерживаемой обеими сторонами (например, клиент обращается по протоколу TLS 1.2, а сервер отвечает по TLS 1.0), вышеописанная схема может быть инициирована из-за сетевых ошибок или действий злоумышленников. Если атакующие, контролирующие сеть на участке между клиентом и сервером, вмешиваются и препятствуют установлению соединения с версией протокола TLS 1.0 или выше, то клиенты сами переходят на использование SSL 3.0.

Протокол использует потоковое шифрование RC4, или блочное шифрование в режиме CBC. Главной проблемой RC4 является наличие смещений: чем больше соединений и потоков шифрования используется для отправки одних и тех же данных (например, пароля или HTTP-куки), тем больше можно извлечь из трафика информации, которая помогает осуществить дешифрование. Ниже будет показано, как можно совместить эффективную атаку на CBC-шифрование при использовании SSL 3.0 (при условии, что злоумышленник может модифицировать сетевой обмен между клиентом и сервером). При этом, в отличие от уязвимостей BEAST и Lucky 13, здесь нет каких-то обходных решений. У нас есть только небезопасный протокол SSL 3.0, и чтобы обеспечить надёжное шифрование, нужно избегать его использования.

Самая серьёзная проблема CBC-шифрования в SSL 3.0 заключается в том, что дополнение блоков (паддинг) может быть произвольным (за исключением последнего байта), на него не распространяется MAC (Message Authentication Code). Целостность дополнения не может быть полностью подтверждена в ходе дешифрования, поскольку в SSL 3.0 сообщение сначала подписывается с помощью MAC, затем дополняется паддингом, и уже после — шифруется блочным шифром. Паддинг от 1 до L байт (где L — размер блока в байтах) используется для получения целого числа блоков перед шифрованием. Легче всего пробить защиту, если есть целый блок паддинга, который (до шифрования) состоит из L-1 произвольных байт, за которыми следует одиночный байт со значением L-1. Для обработки входящей зашифрованной записи C1… Cn, когда также дан вектор инициализации С0 (где каждый Ci — один блок), принимающая сторона сначала определяет P1… Pn как Pi = DK(Ci) ⊕ Ci-1 (DK обозначает расшифровку одного блока с помощью сессионного ключа K). Затем проверяется и удаляется паддинг в конце сообщения и, наконец, проверяется и удаляется подпись MAC.

Если последний блок Cn целиком представляет собой паддинг, и атакующий заменяет Cn на любой более ранний шифрованный блок Ci из того же потока, то сообщение будет всё равно принято, при условии что DK(Ci) ⊕ Cn-1 имеет последний байт L-1, в противном случае он наверняка будет отклонён, что даёт возможность провести атаку Padding Oracle.

Вне лабораторных условий слабость SSL 3.0 может быть использована в MITM-атаках, когда злоумышленник расшифровывает Secure HTTP-куки, используя методику атаки BEAST. Чтобы осуществить POODLE-атаку, нужно:
  • Запустить JS- на www.evil.com, чтобы браузер жертвы отправил содержащий куки HTTPS-запрос на https://example.com
  • Перехватить и модифицировать запись SSL так, чтобы был достаточно большой шанс, что example.com примет изменённую запись. Если это произойдёт, то злоумышленник сможет расшифровать один байт из куки

Допустим, что каждый блок С содержит 16 байт — C[0]… C[15]. Также допустим, что нам стал известен размер куки (ниже покажем, как провести атаку, не зная размера куки). Размер MAC в SSL 3.0 обычно равен 20 байтам, так что «под слоем» CBC зашифрованный POST будет выглядеть так:

POST /path Cookie: name=value...\r\n\r\nbody ǁ 20byteMAC ǁ padding

Злоумышленник контролирует path и тело запроса, и потому может инициировать запросы, удовлетворяющие двум условиям:
  • Паддинг заполняет весь блок (зашифрованный в Cn)
  • Первый, пока ещё неизвестный, байт куки подставляется как последний в более раннем блоке (зашифрованном в Ci)

Далее атакующий заменяет Cn на Ci и перенаправляет эту модифицированную запись на сервер.

Чаще всего сервер её не принимает, и тогда атакующий отправляет новый запрос. Иногда (примерно один раз на 256 попыток) сервер принимает модифицированную запись и атакующий заключает, что Dk(Ci)[15] ⊕ Cn-1[15] = 15, а следовательно Pi[15] = 15 ⊕ Cn-1[15] ⊕ Ci-1[15]. Это раскрывает первый байт куки, до этого неизвестный. Атакующий переходит к следующему байту, одновременно изменяя размеры пути и тела запроса так, чтобы размер запроса не изменился, но местоположение заголовков сдвинулось. Это делается до тех пор, пока кука не будет расшифрована целиком. Ожидаемые общие трудозатраты — 256 запросов SSL 3.0 на один байт.

Поскольку паддинг скрывает точный размер полезного содержимого, размер куки не становится сразу же очевиден. Но запросы GET /, GET /A, GET /AA,… позволяют злоумышленнику вычислить границы блоков. Достаточно максимум 16 подобных запросов, чтобы узнать размер дополнения, а следовательно и размер куки.

Рекомендации

Вышеописанная атака требует соединения по протоколу SSL 3.0, поэтому его отключение в клиенте или на сервере (или с обеих сторон) позволяет полностью избежать неприятностей. Если хотя бы одна сторона поддерживает только SSL 3.0, то здесь медицина бессильна, и необходимо серьёзное обновление, чтобы избежать небезопасного шифрования. Если SSL 3.0 — не единственный поддерживаемый протокол и он не отключён, то тогда атака возможна при downgrade dance (переключении клиента на более низкие версии ради совместимости с сервером).

Отключение SSL 3.0 может быть нецелесообразным, если вам нужно периодически работать со старыми системами. Механизм TLS_FALLBACK_SCSV решает общую проблему для разных версий протокола, и мы полагаем, что это особенно критично для систем, поддерживающих совместимость с SSL 3.0. Ниже объясняется алгоритм работы TLS_FALLBACK_SCSV.

TLS-клиенты, использующие downgrade dance, должны включать значение 0x56, 0x00 в ClientHello.cipher_suites во время каждого даунгрейда версии протокола. Это значение служит сигналом, благодаря которому обновлённые серверы могут отказаться от установления соединения в случае downgrade-атаки. Клиенты должны всегда переходить на следующую более низкую версию (например, если начал с TLS 1.2, то попытаться на TLS 1.1, затем на TLS 1.0, затем SSL 3.0). В случае с TLS_FALLBACK_SCSV, пропуск версии также может помешать успешному соединению.

TLS-серверы, когда во входящем соединении встречается 0x56, 0x00 в ClientHello.cipher_suites, сравнивают ClientHello.cipher_version с самой высокой версией протокола, поддерживаемой сервером. Если сервер поддерживает более высокую версию, чем клиент, то соединение обрывается с ошибкой.

Такое использование TLS_FALLBACK_SCSV даёт уверенность, что SSL 3.0 будет использоваться только при работе со старыми системами: атакующие не могут более инициировать понижение версии протокола. Если же обе стороны допускают использование SSL 3.0, но одна из них не поддерживает TLS_FALLBACK_SCSV, то атака всё ещё возможна.

Список литературы

  • [BEAST] T. Duong, J. Rizzo: “Here Come The ⊕ Ninjas”, 2011.
  • [draft-ietf-tls-downgrade-scsv-00] B. Möller, A. Langley: “TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”, Internet-Draft draft-ietf-tls-downgrade-scsv-00, 2014.
  • [Lucky13] N.J. AlFardan, K.G. Paterson: “Lucky Thirteen: Breaking the TLS and DTLS Record Protocols”, IEEE Symposium on Security and Privacy, 2013.
  • [RC4biases] N.J. AlFardan, D.J. Bernstein, K.G. Paterson, B. Poettering, J.C.N. Schuldt: “On the Security of RC4 in TLS and WPA”, USENIX Security Symposium, 2013.
  • [RFC2246] T. Dierks ,C. Allen: “The TLS Protocol Version 1.0”, RFC2246, 1998.
  • [RFC4346] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC4346, 2006.
  • [RFC5246] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC5246, 2008.
  • [RFC6101] A. Freier, P. Karlton,P. Kocher: “The Secure Sockets Layer (SSL) Protocol Version 3.0”, RFC6101, 1996(published as Historic RFC in 2011).
  • [tlscbc] B. Möller: “Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures”, http://www.openssl.org/~bodo/tlscbc.txt, 2004.
Автор: @valievkarim

Комментарии (13)

  • 0
    Цитата: «поэтому его отключение в клиенте или на сервере (или с обеих сторон) позволяет полностью избежать неприятностей. Если хотя бы одна сторона поддерживает только SSL 3.0, то здесь медицина бессильна»
    вводит в ступор. Так достаточно отключения на одной из сторон или нет?
  • +3
    Да, полностью отключенный SSL 3.0 в клиенте или на сервере не позволит хакеру провести атаку.
    Потому что стороны никогда не начнут общение по этой версии протокола.
    Но если какая-то из сторон (клиент или сервер) поддерживает только SSL версии 3.0, то требуется обновление — потому что если отключить на другой стороне SSL 3.0, то они просто не смогут установить соединение.
    То есть, исправить уязвимость со стороны сервера можно, но ценой того, что клиенты, умеющие только SSL 3.0 перестанут работать совсем.
  • +5
    На работе через GPO всем отключили SSL3.
    И туже отвалились два Банк клиента, Один из них всемирно известный банк.
    Прям даже не знаю показывать ли пальцем?
    А у второго вообще рейтинг безопасности https — F в ssllab.com.
    • 0
      конечно показывать! без этого ничего не сдвинется с места.
  • +1
    Есть еще одна защитная мера если хочется оставить SSLv3 — на стороне сервера накатить патч, который позволит использовать RC4 только для SSLv3, и включить RC4. Практическая эксплуатация уязвимости в RC4 намного сложнее чем POODLE.
    • 0
      есть и более эффективная мера: ограничить время сессии и увеличить длину ключа, привязав его к IP, — что сведет атаку к статистически невозможной за время жизни сессии с одним ключом (при ограничении на число запросов с одного IP)
      • 0
        Вы сейчас предлагаете решить проблему протокола путем изменения приложения.
        • 0
          это позволит не отключать пользователей Windows XP и сократить расходы на техническую поддержку таких пользователей
          • +1
            ограничить время сессии… привязать к IP

            может стоить намного больше, чем пользователи WinXP < sp3
  • –1
    Послушайте, какая нахрен «защита данных»,
    гневный хейт в адрес идиотов из мейлру
    когда вы, во-первых, сначала мой ящик заблокировали вообще без причины и потребовали кучу данных «указанных при регистрации» (несмотря на то, что при регистрации много лет назад я никакие данные не указывал) и отказывались что-либо делать, присылая стандартные отписки. Помогла только несколькодневная ругань с их твиттер-аккаунтом.

    Потом заблокировали мой второй ящик, опять же, без причины. Я их послал и забил на ящик, т.к. почти не пользовался им.

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

    НАХРЕНА, блин? Как только ящик будет разблокирован, все сервисы, которые были на этот ящик зарегистрированы, будут переведены на нормальную почту, а этот ящик удалён.


    Основной мой посыл – о какой «защите данных» вы можете говорить, когда все данные могут быть потеряны из-за бессмысленной блокировки аккаунта без возможности нормального восстановления?
    • 0
      p.s. если кто-нибудь из мейл.ру прочитает это и сможет адекватно, а не дефолтной отпиской, ответить – было бы очень здорово.

      p.p.s. простите за оффтопик.
      • +1
        «Бессмысленных» блокировок аккаунтов не бывает: в каждом случае существует конкретная причина, и наша цель – это действительно защита данных пользователей. Теперь по пунктам.
        Первый ящик никогда не блокировался. Была необходимость восстановить пароль, поскольку Вы его забыли. В таких случаях мы всегда запрашиваем у пользователя большое количество информации. Мы понимаем, почему это может вызвать раздражение, но это необходимое зло, ведь мы должны удостовериться, что пароль восстанавливает именно владелец ящика, а не кто-либо другой. Что касается Вашего второго ящика и ящика Вашей жены – с обоих была зафиксирована подозрительная активность, которая позволяла допустить, что доступ к аккаунтам получил злоумышленник. Именно поэтому они были заблокированы. Однако, к сожалению, в случае с ящиком Вашей жены блокировка действительно сработала с задержкой и произошла уже после того, как Вы сменили пароль. Приносим за это извинения, мы работаем над улучшением этой системы. Пожалуйста, проявите терпение и понимание и все-таки заполните форму для восстановления пароля.
        • 0
          Спасибо за ответ и расследование!

          Ок, первый не блокировался, но процедура та же самая. Зачем «подтверждать личность», когда у меня уже был полный доступ к ящику – я не понимаю в принципе. Какая-то абсолютно бессмысленная и глупая бюрократия.

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

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

          И, главная мысль, которую я однажды всё-таки смог донести до моего банка (!), что безопасность, мешающая пользоваться самому владельцу, приносит вреда НАМНОГО больше, чем какой бы то ни было взлом.
          Не понимаю, почему банк, в котором мои деньги, согласился со этим, а почтовый сервис, где всего-то переписка и некоторые регистрационные данные, считает, что он лучше знает, что мне нужно.

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка