Интересующиеся веб-безопасностью читатели уже в курсе очередной уязвимости в 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...rnrnbody ǁ 20byteMAC ǁ padding
Злоумышленник контролирует path и тело запроса, и потому может инициировать запросы, удовлетворяющие двум условиям:
- Паддинг заполняет весь блок (зашифрованный в Cn)
- Первый, пока ещё неизвестный, байт куки подставляется как последний в более раннем блоке (зашифрованном в Ci)
Далее атакующий заменяет Cn на Ci и перенаправляет эту модифицированную запись на сервер.
Чаще всего сервер её не принимает, и тогда атакующий отправляет новый запрос. Иногда (примерно один раз на 256 попыток) сервер принимает модифицированную запись и атакующий заключает, что Dk(Ci)[15] ⊕ Cn-1[15] = 15, а следовательно Pi[15] = 15 ⊕ C-1[15] ⊕ C-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
