Ингве Петтерсен продолжает изучать проблемы уязвимостей и тестировать веб-серверы на вопрос незакрытых брешей.
На прошлой неделе появились сообщения о новой уязвимости в OpenSSL, которой были подвержены все версии библиотеки. Эта новая уязвимость, часто называемая уязвимостью CCS, относится к типу MITM (Man In The Middle) и позволяет атакующему «подслушать» или изменить данные, пересылаемые между клиентом и сервером, обманывая обе стороны — клиент и сервер, чтобы установить соединение между ними с использованием предсказуемых ключей шифрования.
Проблема CCS
Уязвимость эксплуатируется следующим образом: атакующий, имеющий возможность подключиться и контролировать трафик между клиентом и сервером, внедряет определенные сообщения протокола TLS (в частности — сообщения Change Cipher Spec (CCS)) в поток данных ранее, чем любая из сторон ожидала бы их получить. Сообщение CCS, которое не является частью сообщений квитирования, указывает получателю, что все последовательные записи Протокола TLS, полученные от отправителя, зашифрованы недавно созданными ключами шифрования.
Данное сообщение предназначено для отправки после того, как стороны обменялись достаточной информацией для создания ключей шифрования. К сожалению, оказалось, что OpenSSL (как на стороне клиента, так и на стороне сервера) не проверяет, были ли завершены все процедуры и принят подтверждающий сигнал, и продолжает создавать ключи шифрования без использования секретного ключа, отправленного клиентом. В результате стороны начинают осуществлять квитирование, используя предсказуемые ключи шифрования, позволяя атакующему дешифровать и/или изменять передаваемые данные.
Можно ли было избежать данной уязвимости?
Главная причина появления данной проблемы заключается в том, что при обработке сообщений CCS в OpenSSL не проводилось проверки, пришло ли сообщение в то время, в которое оно и ожидалось. Вместо этого просто выполнялась обычная последовательность действий по созданию и использованию ключей шифрования. Возможно, более тщательная проверка последовательности действий и соответствия требуемых условий могли бы предотвратить проблему.
Если не учитывать ошибки реализации, то данная проблема относится к той же категории, что и Renego (а также недавняя, связанная с Renego проблема тройного квитирования): уязвимость стала возможной потому, что методы TLS, используемые для проверки надёжности квитирования, не включали всю необходимую информацию, гарантирующую надёжность соединения.
В этом случае, на мой взгляд, достаточно было незначительных изменений в реализации протокола TLS для предотвращения проблемы CCS. Как я сказал выше, сообщение CCS не является частью протокола квитирования по причинам, связанным с производительностью. CCS не относится к сообщениям квитирования (хотя и является важной частью процесса квитирования), поэтому не включено в процесс проверки целостности квитирования, который призван гарантировать, что клиент и сервер отправили и получили все сообщения квитирования, и что не было произведено никаких изменений в этих сообщениях во время их пересылки. В результате сообщения CCS могут быть добавлены и удалены атакующим без угрозы быть обнаруженным, если стороны не осуществляют контроль времени получения сообщений.
Я предполагаю, что проблему можно было бы предотвратить, включив CCS в данные, используемые для проверки целостности квитирования. Если бы это было сделано, то дополнительные сообщения CCS, используемые в данном случае атакующим, нарушили бы проверку целостности, и клиент и сервер были бы неспособны отправить правильные значения друг другу, потому что они будут видеть различное квитирование и последовательности сообщений CCS, после чего разорвали бы соединение из-за несоответствия, таким образом устраняя уязвимость.
Продукты, подверженные уязвимости
Уже известно, что данная атака будет работать с любой версией клиентов, использующих OpenSSL, если они связываются с уязвимым сервером, использующим OpenSSL 1.0.1 (pre-1.0.1h). Пока неизвестно, подвержены ли угрозе клиенты OpenSSL, подключающиеся к серверам, использующим более старые версии OpenSSL (pre-0.9.8za или pre-1.0.0m), т. к. фактически брешь для атак была создана в версиях 1.0.1 в связи с упрощением некоторых процедур проверки.
Клиенты OpenSSL экстенсивно используются в устройствах под управлением Android как встроенным браузером, так и приложениями, таким образом, программное обеспечение этих устройств должно быть обновлено. Кроме того, основанные на Konqueror браузеры, популярные в Linux/KDE, также используют OpenSSL для поддержки TLS, если мне не изменяет память. Стек OpenSSL TLS может также использоваться (особенно на Linux, но также и других платформах) серверами и клиентами, по крайней мере, для электронной почты, чата, для авторизации и в основанных на SSL сетях VPN, а также в различных сценариях, написанных с использованием Python или других языков. Пользователи должны обновить данное программное обеспечение, как только патчи станут доступными.
Клиенты, не основанные на стеке OpenSSL, не являются уязвимыми (включая браузер Opera 12, который использует OpenSSL только для crypto примитивов, и при этом использует свою собственную реализацию TLS).
Смягчающий фактор
Данная уязвимость требует, чтобы и клиент, и сервер были уязвимы. Таким образом, пользователь, желающий избежать проблемы, должен лишь убедиться, что использует клиенты или версии клиентов, не подверженные данной уязвимости.
Насколько данная уязвимость опасна
Можно сказать, что данная уязвимость не настолько опасна, как Heartbleed, но я оценил бы её как более серьезную, чем проблема Renego. Heartbleed открывал доступ к частным данным на сервере, включая закрытый ключ, в то время как Renego позволял «только» внедрять запросы и данные в начале соединения. Новая проблема позволяет атакующему подключаться к соединению, и таким образом эта уязвимость является более серьезной, чем предварительное внедрение данных, но менее серьезной, чем утечка данных с сервера, которая может дать злоумышленникам закрытые ключи или данные пользователей, соединения которых не были прерваны.
Число затронутых серверов
Используя доступную информацию и, в частности, информацию и примеры от Адама Лэнгли, работающего в Google, я добавил новый тест для своего сканера TLS Tester и выполнил сканирование моей обычной подопытной группы из 540000 серверов, чтобы обнаружить, сколько серверов затронуто этой проблемой.
Согласно данным, которые я получил спустя неделю после раскрытия уязвимости, 17.3% отсканированных серверов оказались определенно уязвимыми, поскольку они используют уязвимые версии OpenSSL 1.0.1, в то же время ещё 37.8% используют уязвимые версии OpenSSL версии 1.0.0 или более ранние и, таким образом, теоретически уязвимы. В общей сложности приблизительно 55% выбранных серверов ненадёжны и должны быть исправлены.
Интересно будет посмотреть, как быстро эта проблема будет исправляться в ближайшие недели и месяцы.
Ситуация с Vivaldi.net
Говоря о собственных серверах Vivaldi.net, которые используют Apache и OpenSSL для TLS, нужно отметить, что они были исправлены вскоре после того, как патчи стали доступными, и на данный момент не затронуты проблемой.
От переводчика
На самом деле тема для меня не очень близкая, поэтому в переводе наверняка есть несоответствия в терминологии. Всех заинтересованных приглашаю читать оригинал статьи.
Автор: Shpankov
