The ROBOT Attack – как работает и меры противодействия

Иногда в IT-отрасли случаются события, могущие послужить основой для сериала про зомби. Возвращение атаки Bleichenbacher’s Oracle Threat – как раз такой случай.

Daniel Bleichenbacher и атака на SSL

В 1998 году, когда везде используется SSL 3.0, а где-то и 2.0, исследователь Daniel Bleichenbacher из Швейцарии, на тот момент только недавно получивший Ph.D в Swiss Federal Institute of Technology в Цюрихе, и, работая в Bell Labs, публикует документ, из которого следует то, что ранее известные только на бумаге атаки класса adaptive chosen-ciphertext attack могут быть реализованы на практике.

Идея достаточно проста – найти сервер, который использует для работы с ключевым материалом SSL-сессии алгоритм RSA, согласно PKCS1 v1.5, и последовательно скармливать ему тестовые запросы, анализируя реакцию – это и называется адаптивной атакой на основе подобранного шифротекста (иногда используется сокращение CCA2 – “второй вариант chosen-ciphertext attack”). По скорости и реакции сервера на отправляемые данные можно будет угадать (если сервер не будет, как в реализации OpenSSL, пытаться скрыть это), из-за какой ошибки был отброшен конкретный вариант, и учесть это в дальнейшем переборе.

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

Через почти 20 лет появляется новая возможность для реализации этого класса атак – и её называют Return Of Bleichenbacher’s Oracle Threat, или ROBOT.

Разберёмся, что и как.

Актуальность атаки ROBOT

Массовость систем, потенциально уязвимых для The ROBOT, весьма впечатляет – это устройства Cisco, F5, Palo Alto Networks и прочих, софт от IBM и Citrix. Несмотря на то, что общий механизм эксплуатации уязвимости известен почти 20 лет, та же фирма IBM закрывает эту дыру в феврале 2018 года.

Какое отношение имеет атака ROBOT к Oracle

К фирме Oracle, известной решениями в области баз данных – никакого. Аббревиатура ROBOT получается от сокращения фразы Return Of Bleichenbacher’s Oracle Threat. Oracle здесь – не название фирмы, а термин из теории алгоритмов, обозначающий абстрактную машину, которая может подтвердить или опровергнуть ваше формализованное предположение. ROBOT – это “возвращение атаки Блейхенбахера, связанное с использованием “оракула”, т.е. многократного опробования удалённой системы с получением результата “угадал/не угадал”.

Уязвимость ROBOT связана со стойкостью RSA?

Нет. К самому алгоритму RSA никаких новых претензий от атаки ROBOT не выдвигается. Атака использует то, что можно много раз “потыкать” сервер, использующий RSA для создания ключевого материала конкретной сессии.

Нужно очень чётко понимать, что RSA может использоваться в SSL/TLS в разных частях задачи по установлению безопасного соединения:

Как алгоритм, нужный для подтверждения подлинности сервера/клиента;
Как алгоритм, нужный для выработки сеансовых ключей;

Использование в первом случае – это обычная и обязательная проверка сертификата сервера. Исключая редчайший вариант “сертификат с DSA” RSA-подпись – самый распространённый случай.

Во втором – это один из вариантов алгоритма, используемого для генерации ключевого материала. Атака возможна только в этом варианте. Факт наличия RSA-ключа у x.509v3-сертификата сервера никак не влияет на The ROBOT Attack.

Как проверить, уязвим ли мой сервер?

Сайт robotattack.org имеет встроенную форму для проверки хостов на уязвимость для The ROBOT Attack. Хороший сайт выглядит так:

Пример сайта, не уязвимого для The ROBOT Attack
(кликните для увеличения до 1273 px на 659 px)

, не очень хороший так:

Пример сайта, уязвимого к атаке The ROBOT Attack
(кликните для увеличения до 1071 px на 561 px)

Как на уровне настроек защититься от ROBOT?

Очень просто – надо не использовать cipher suites, начинающиеся с TLS_RSA. Вот такие:

Cipher suites, начинающиеся с TLS_RSA, потенциально небезопасны
(кликните для увеличения до 1077 px на 812 px)

Современный вариант – это TLS_ECDHE, алгоритм RSA в нём для работы с ключевым материалом не используется.

Надо учитывать одну тонкость – по стандарту TLS 1.2, сервер обязан поддерживать, в числе прочих, TLS_RSA_WITH_AES_128_CBC_SHA (см. статью про настройку TLS). Его поддержку можно отключать для всех современных систем, т.к. у них есть cipher suites и получше – но формально, отключая в целях защиты от The ROBOT данный вариант, вы делаете систему не совместимой с TLS 1.2. На реальное использование это не повлияет, т.к. клиенты сейчас поддерживают множество вариантов защиты сессии, но с точки зрения стандарта некий “минимальный клиент TLS 1.2” может уметь использовать только такой вариант и в результате не сможет подключиться. Впрочем, такие клиенты найдены не были – TLS 1.2 штатно поддерживается в ОС Microsoft уже с десяток лет, с Windows 7 / Server 2008 R2, и даже в них выбор cipher suites – весьма масштабный.

Как подстраховаться от подобного класса атак?

Самое лучшее – не использовать симметричные криптоалгоритмы – любые – в варианте работы в режиме CBC. Все приключения с padding’ом и последующими неприятностями отталкиваются именно от специфики данного режима работы алгоритмов с секретным ключом. Используйте те же алгоритмы, но с GCM.

Второй вариант – как можно быстрее внедряйте TLS 1.3; он не имеет проблем с данным классом атак.

Для удаления cipher suites по критерию “те, которые используют CBC”, можно воспользоваться утилитой ATcmd. Для этого, аосле запуска и перехода в контекст tls и ciphersuites, надо запросить список использующихся сейчас cipher suites командой list:

Просмотр всех cipher suites, использующих CBC
(кликните для увеличения до 997 px на 835 px)

, а после удалить все те, где используется режим CBC:

Отключение cipher suites, использующих CBC
(кликните для увеличения до 997 px на 1027 px)

Этот шаг, безусловно, уберёт возможность атаки The ROBOT как класс, однако может иметь побочные следствия в виде неработоспособности протоколов, которые используют жёстко заданные алгоритмы и не имеют возможности переключиться на другие. Пример – SSTP, у него жёстко заданы возможные для использования cipher suites, поэтому при отключении всех cipher suites с CBC возникнут проблемы при установке SSTP-based VPN. Так что делайте масштабные шаги с осторожностью и хорошо изучив последствия.

Вкратце всё.

Удачи и безопасных сетей!

Возможно, вам будет также интересно почитать другие статьи про TLS на нашей Knowledge Base