Новая техника позволяет атакующему получать полный контроль над приложениями в клиентском браузере, прослушивать коммуникации, подменять контент на веб-сайтах и осуществлять на них действия от лица жертвы. При этом не производится подмена серверных сертификатов, что позволяет избежать обнаружения атаки.
Протокол TLS используется для безопасной передачи данных, однако серьезные уязвимости в нем обнаружены не впервые — две предыдущие ошибки безопасности получили название Logjam и Bar Mitzvah.
Подробности атаки
Для осуществления атаки злоумышленнику необходимо каким-либо образом убедить жертву установить специально изготовленный клиентский SSL-сертификат, ключ от которого известен атакующему. В дальнейшем это позволяет «убедить» клиентский софт в том, что он взаимодействует с доверенным сервером, в то время как на самом деле коммуникация осуществляется с атакующим.
Для успешного осуществления атаки также необходимо совпадение нескольких факторов:
1) Сервер для соединения должен поддерживать шифрование (EC)DH, иметь сертификат ECDSA без «X509 Key Usage» или «X509 Key Usage» с выставленным KeyAgreement (по данным исследователей, такие серверы составляют как минимум 9,25% от всех доступных HTTPS-серверов из списка миллиона самых популярных сайтов Alexa.com).
2) Клиент должен поддерживать клиентские сертификаты следующих типов:
- rsa_fixed_dh
- dss_fixed_dh
- rsa_fixed_ecdh
- ecdsa_fixed_ecdh
3) Клиент должен поддерживать Non-ephemeral (EC)DH и клиентские сертификаты из следующего списка:
- TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
- TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_DH_DSS_WITH_AES_128_CBC_SHA
- TLS_DH_RSA_WITH_AES_128_CBC_SHA
- TLS_DH_DSS_WITH_AES_256_CBC_SHA
- TLS_DH_RSA_WITH_AES_256_CBC_SHA
- TLS_DH_DSS_WITH_AES_128_CBC_SHA256
- TLS_DH_RSA_WITH_AES_128_CBC_SHA256
- TLS_DH_DSS_WITH_AES_256_CBC_SHA256
- TLS_DH_RSA_WITH_AES_256_CBC_SHA256
- TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
- TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
- TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
- TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
- TLS_DH_DSS_WITH_SEED_CBC_SHA
- TLS_DH_RSA_WITH_SEED_CBC_SHA
- TLS_DH_RSA_WITH_AES_128_GCM_SHA256
- TLS_DH_RSA_WITH_AES_256_GCM_SHA384
- TLS_DH_DSS_WITH_AES_128_GCM_SHA256
- TLS_DH_DSS_WITH_AES_256_GCM_SHA384
- TLS_ECDH_ECDSA_WITH_NULL_SHA
- TLS_ECDH_ECDSA_WITH_RC4_128_SHA
- TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_RSA_WITH_NULL_SHA
- TLS_ECDH_RSA_WITH_RC4_128_SHA
- TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
Как злоумышленники устанавливают сертификат для атаки
Авторы исследования выделяют несколько возможностей установки зловредных сертификатов на атакуемые клиентские приложения.
Злоумышленники могут создать специальную версию программного продукта, в котором сертификат для атаки установлен по умолчанию. Также установить его может и киберпреступник, работающий в компании, которая занимается разработкой софта. В таком случае продукт не будет содержать никаких явных уязвимостей, полностью соответствуя спецификации TLS, таким образом ничто не будет указывать на наличие бэкдора.
Кроме того, несмотря на то, что механизм генерации и установки клиентских сертификатов, использующийся в современных браузерах, не подразумевает передачу секретного ключа с клиентского компьютера, распространенной практикой среди различных компаний и организаций является распространение предварительно сгенерированных пар ключей клиентам. В некоторых ОС (например, в Apple iOS) даже предусмотрена функциональность для облегчения установки пар ключей, присланных по email. Соответственно, злоумышленники могут убедить жертву установить зловредный сертификат с помощью методов социальной инженерии.
Также установить зловредный ключ в список доверенных может специально разработанное Android¬-приложение, что приводит к возможности атаки на TLS-соединения других приложений. Подобный способ атаки был реализован на Android 4.4.
На видео ниже представлена proof-of-concept демонстрация атаки, разработанной австрийскими исследователями:
Уязвимые клиенты
Исследователи обнаружили, что реализация TLS в библиотеке BouncyCastle подвержена новой атаке. Это означает, что любой клиентский софт, использующий реализацию TLS BouncyCastle может быть уязвимым перед атакой.
Кроме того, уязвима и TLS-библиотека операционной системы Mac OS X (Secure Transport). В ходе эксперимента удалось успешно осуществить атаку, которая не была детектирована, на браузер Safari в версиях OS X до 10.5.3. В более поздних версиях операционной системы клиент должен подтвердить выбор клиентского сертификата — однако в том случае, если жертва установит зловредный сертификат, при последующих соединения атака также не будет детектироваться. Атаку не удалось воспроизвести на Mac OS X версий 10.8, 10.9 и 10.10.
Наиболее распространенные версии библиотеки OpenSSL (0.9.8, 1.0.0, 1.0.1) не поддерживают опции TLS, необходимые для проведения атаки (что делает такие системы, как Google Android не подверженным ей). Однако в исходном коде библиотеки исследователи обнаружили свидетельства наличия планов по реализации поддержки этих опций — и один из разработчиков более новой версии OpenSSL 1.0.2 подтвердил частичное добавление таких возможностей. Это позволяет утверждать, что клиентские приложения, использующие эту версию библиотеки OpenSSL также могут быть уязвимы перед описанной атакой.
Информация, представленная в исследовании, до ее публичного разглашения была передана Google, Microsoft и Apple, поэтому разработчики популярных браузеров имели возможность выпустить соответствующие исправления, препятствующие осуществлению атаки.
Как защититься прямо сейчас
Для снижения вероятности осуществления атаки авторы исследования рекомендуют провайдерам услуг и сервисов, которые используют технологию TLS, выполнить два шага:
- Отключить поддержку non-ephemeral (EC)DH handshakes;
- Установить расширение X509 Key Usage для сертификатов ECDSA и DSS, а также отключить флаг KeyAgreement.
Кроме того, исследователи рекомендуют разработчикам клиентского софта внести исправления в код программных продуктов:
- Отключить опции non-ephemeral (EC)DH handshake;
- Или, как минимум, отключить поддержку аутентификации с использованием шифрования (EC)DH.
Разработчикам реализаций библиотек TLS рекомендуется немедленно проверить их на предмет поддержки расширений X509 Key Usage, а также пометить в документации функции, использующие шифрование (EC)DH, как устаревшие и опасные.
Очевидно, что выпуск патчей от производителей займёт какое-то время, а затем нужно будет обновить всё описанное ПО, что едва ли можно сделать «прямо завтра». Всё это время злоумышленники могут использовать уязвимости для атак. Поэтому эксперты Positive Technologies рекомендуют использовать специализированные средства защиты, которые позволяют защититься уже сейчас.
Так система контроля защищенности MaxPatrol позволяет обнаруживать веб-, почтовые и другие серверы, подверженные описанной атаке, а также целому ряду других уязвимостей SSL/TLS.
В свою очередь с помощью межсетевого экрана PT Application Firewall можно выявлять уязвимые клиентские приложения, и находить подозрительные соединения, которые потенциально могут использоваться злоумышленниками для осуществления атаки.
Комментарии (6)
DarkByte
17.09.2015 16:34+11Для осуществления атаки злоумышленнику необходимо каким-либо образом убедить жертву установить специально изготовленный клиентский SSL-сертификат, ключ от которого известен атакующему.
Так может сразу корневой сертификат убедить его установить? Процесс установки то примерно такой же, по крайней мере под Windows.creker
17.09.2015 16:39Тоже так подумал, но вот то, что браузер показывают исходный серт, все таки искупает. Тут уже не поможет привычный совет тыкать в адресную строку и проверять, что там за серт и есть ли он вообще.
galaxy
17.09.2015 20:08+7И ни слова о механизме атаки…
Короче, в двух словах:
1. Подсунули клиенту серт со статическими параметрами Диффи-Хеллмана
2. Встали между клиентом и сервером
3. В ответ на запрос клиента потребовали нужный режим обмена ключами (статический DH) и аутентификацию клиента по серту, отдали клиенту оригинальный серт сервера
4. Теперь мастер-пароль клиентом будет сгенерен на основе параметров серверного серта (публичных) и клиентского серта (который клиенту был подсунут в шаге 1). Злоумышленнику все это известно
5. PROFIT
Правда, обязательных условий многовато.merlin-vrn
18.09.2015 08:41+3Так это такая завуалированная реклама MaxPatrol — в блоге разработчика. Зачем описывать механизм атаки?
Что до условий, то я помню был в 2012 шум по поводу другой атаки, практически нереальной, которую потом закрыли, внеся уязвимость Heartbleed, которую реализовать легко.
grossws