- Beast
- Drown
- Heartbleed
- Man in the middle
- Poodle
- Secure sockets layer
- Выбор режима подмены ssl-сертификата
- Завершение истории
- Исключение серверов из перехвата шифрованного трафика
- Пассивное наблюдение
- Подмена сертификата
- Подмена сертификата шифрования, firewall, agents, антивирусы, системы безопасности
- Пользовательские интерфейсы
- Привязка ssl-сертификата к серверу
- Создание фальшивых ssl сертификатов или новогодний подарок для фишеров
Beast
Одна из самых первых атак на SSL и TLS 1.0, обнаруженная в 2021 году. Как и POODLE, BEAST
особенности CBC-шифрования. Злоумышленники внедряют на клиентскую машину JavaScript-агент или Java-апплет, который подменяет сообщения при трансляции данных по TLS или SSL. Так как злоумышленникам известно содержание «подставных» пакетов, они могут с их помощью расшифровать вектор инициализации и прочитать остальные сообщения к серверу, например cookie-файлы для аутентификации.
На сегодняшний день уязвимости BEAST по-прежнему подвержен ряд сетевых инструментов: прокси-серверы и приложения для защиты локальных интернет-шлюзов.
Как защититься. Атакующему необходимо регулярно посылать запросы, чтобы расшифровывать данные. В VMware рекомендуют сократить длительность SSLSessionCacheTimeout — с пяти минут (рекомендация по умолчанию) до 30 секунд. Такой подход усложнит реализацию планов злоумышленникам, хотя и окажет некоторый негативный эффект на производительность.
Помимо этого нужно понимать, что в скором времени уязвимость BEAST может уйти в прошлое сама по себе — с 2020 года крупнейшие браузеры прекращают поддержку TLS 1.0 и 1.1. В любом случае с этими протоколами работает менее 1,5% всех пользователей браузеров.
Drown
, хакер может расшифровать одну из примерно тысячи TLS-сессий клиента.
О DROWN впервые стало известно в 2021 году — тогда ей оказалась подвержена треть серверов в мире. На сегодняшний день она не утратила актуальности. Из 150 тысяч самых популярных сайтов 2% до сих пор поддерживают SSLv2 и уязвимые механизмы шифрования.
Как защититься. Необходимо установить патчи, предложенные разработчиками криптографических библиотек, отключающие поддержку SSLv2. Например, две такие заплатки представили для OpenSSL (в 2021 году это были обновления 1.0.1s и 1.0.2g).
Heartbleed
Одна из самых крупных уязвимостей в софте —
. Её обнаружили в 2021 году в библиотеке OpenSSL. На момент объявления об ошибке количество уязвимых веб-сайтов
— это примерно 17% защищенных ресурсов в сети.
Атака реализуется через небольшой модуль Heartbeat расширения TLS. TLS-протокол требует, чтобы данные передавались непрерывно. В случае длительного простоя происходит разрыв и приходится заново устанавливать соединение. Чтобы справиться с проблемой, серверы и клиенты искусственно «зашумляют» канал (RFC 6520, стр.5), передавая пакет случайной длины.
Уязвимость присутствовала во всех версиях библиотеки между 1.0.1 и 1.0.1f включительно, а также в ряде ОС — Ubuntu до 12.04.4, CentOS старше 6.5, OpenBSD 5.3 и других. Полный список есть на сайте, посвященном Heartbleed. Хотя патчи против этой уязвимости были выпущены практически сразу после её обнаружения, проблема остается актуальной до сих пор. Еще в 2021 году работало почти 200 тыс. сайтов, подверженных Heartbleed.
Как защититься. Нужно обновить OpenSSL до версии 1.0.1g или выше. Можно также отключить Heartbeat-запросы вручную с помощью опции DOPENSSL_NO_HEARTBEATS. После обновления специалисты по ИБ рекомендуют перевыпустить SSL-сертификаты. Замена нужна на случай, если данные о ключах шифрования все же попали к хакерам.
Man in the middle
Если мы не можем «влезть» в защищённое соединение, то почему бы не установить два разных соединения: одно между клиентом и атакующим (который в данном случае притворяется сервером), и второе между атакующим и сервером?
От этого алгоритм Диффи-Хелмана не защищён. Но SSL, в отличии от ДХ, требует аутентификацию сервера, и поэтому такой подход также обречён на неудачу. Клиент при установлении соединения ждёт от сервера аутентификации (она при использовании SSL обязательна). Но вместо сервера он будет соединён с атакующим, который не владеет цифровым сертификатом, соответствующим имени сайта.
Есть два способа решения проблемы отсутствия сертификата:
- Создать необходимый сертификат самостоятельно, и самому подписать его. Такие сертификаты называются «самоподписанными». Однако система цифровых сертификатов требует возможности проверить состоятельность сертификата. Для этого используются «удостоверяющие центры» (Certification authority, CA), которые могут подписывать сертификаты сайтов (и не только), а также подписывать сертификаты других удостоверяющих центров. Сертификаты корневых CA – их немного – внесены в браузер разработчиками. И браузер считает сертификат подлинным только если он находится в конце цепочки сертификатов, начинающейся с одного из CA, где каждый следующий сертификат подписан предыдущим в цепочке.
- Получить у удостоверяющего центра сертификат для какого-то сайта, и использовать его для атаки. Не годится, так как в каждом сертификате сайта указан домен, для которого он выдан. В случае несовпадения домена в адресной строке с доменом, указанным в сертификате – браузер начнёт бить тревогу.
В обоих случаях браузер покажет жертве какую-нибудь пугающую картинку, например такую:
Poodle
Впервые об атаке
стало известно в 2021 году. Уязвимость в протоколе SSL 3.0 обнаружил специалист по ИБ Бодо Мёллер (Bodo Möller) с коллегами из Google.
Ее суть заключается в следующем: хакер вынуждает клиента выполнить подключение по SSL 3.0, эмулируя разрывы связи. Затем он ищет в зашифрованном в CBC-режиме трафике специальные сообщения-метки. С помощью серии подставных запросов злоумышленник получает возможность реконструировать содержимое интересующих его данных, например cookies.
SSL 3.0 — устаревший протокол. Но вопрос его безопасности все еще актуален. Клиенты используют его, чтобы избежать проблем совместимости с серверами. По некоторым данным, почти 7% из 100 тыс. самых популярных сайтов все еще поддерживают SSL 3.0.
Также существуют модификации POODLE, целью которых являются более современные TLS 1.0 и TLS 1.1. В этом году появились новые атаки Zombie POODLE и GOLDENDOODLE, которые обходят защиту TLS 1.2 (они по-прежнему связаны с CBC-шифрованием).
Как защититься. В случае с оригинальным POODLE нужно отключить поддержку SSL 3.0. Однако в этом случае есть риск получить проблемы с совместимостью. Альтернативным решением может стать механизм TLS_FALLBACK_SCSV — он гарантирует, что обмен данными по SSL 3.
0 будет проводиться только со старыми системами. Злоумышленники больше не смогут инициировать понижение версии протокола. Способ защиты от Zombie POODLE и GOLDENDOODLE — отключение поддержки CBC в приложениях на базе TLS 1.2. Кардинальным решением станет переход на TLS 1.3 — в новой версии протокола не используется CBC-шифрование.
Secure sockets layer
Протокол SSL используется уже более десяти лет, и информации о нём в Сети предостаточно.
Так что я лишь выделю основные свойства SSL, а детали их реализации желающие могут изучить самостоятельно:
Вариантов для перехвата данных, передаваемых через SSL немного:
Выбор режима подмены ssl-сертификата
В окне настроек выберите приемлемый режим перехвата:
- Для автоматической генерации агентом корневого SSL-сертификата при установке на компьютер пользователя, выберите опцию Автоматический режим. Созданный корневой сертификат будет помещен в базу доверенных создателей сертификатов и автоматически использоваться агентом для последующей выдачи дочерних сертификатов, подписанных по умолчанию именем издателя Falcongaze SecureTower.
Для смены имени издателя сертификата, которое будет указано в сведениях о безопасности соединения, задайте нужное имя в поле Имя в SSL- сертификате.
- Для использования пользовательского SSL-сертификата в качестве корневого при перехвате шифрованного трафика, выберите опцию Пользовательский режим. Пользовательский сертификат должен быть предварительно сгенерирован и добавлен в базу системы. Для указания сертификата из базы системы выберите его имя в раскрывающемся списке Пользовательский сертификат либо нажмите кнопку Пользовательские сертификаты для добавления файлов сертификата и закрытого ключа в базу системы.
В открывшемся окне нажмите кнопку Добавить сертификат и укажите файлы сертификата и ключа одним из предложенных ниже способов:
- Укажите путь к существующим файлам сертификата и закрытого ключа в полях окна Добавление пользовательских сертификатов, используя кнопку
.
- Для генерации нового сертификата нажмите кнопку Сгенерировать сертификат. Введите в открывшемся окне имя нового сертификата, время его действия и укажите пути, по которым будут храниться вновь созданные файлы сертификата(*.cer) и закрытого ключа(*.pvk). Нажмите кнопку Сгенерировать.
- Если требуется добавить сертификат, ранее сгенерированный в формате PFX, нажмите кнопку Конвертировать из сертификата в формате PFX. Укажите путь и пароль к файлу сертификата в формате PFX, а также путь к файлам сертификата(*.cer) и закрытого ключа(*.pvk), в которые требуется конвертировать исходный файл. Нажмите кнопку Конвертировать для завершения конвертации.
Завершение истории
А история, начатая в
Исключение серверов из перехвата шифрованного трафика
Для работы с исключениями из процесса подмены сертификатов, нажмите кнопку Исключения SSL – серверов.
В окне менеджера исключений отображен перечень серверов (хостов), исключенных из процесса подмены по умолчанию. Для добавления нового исключения нажмите кнопку Добавить исключение.
Пассивное наблюдение
Не годится, так как передаваемые данные зашифрованы временным ключом. Ключ этот известен и клиенту и серверу, но его невозможно вычислить, лишь наблюдая со стороны за трафиком.Примером того, как можно реализовать защиту от пассивного наблюдения является алгоритм Диффи-Хеллмана.
Подмена сертификата
Между пользователем и сервером устанавливается управляемый узел с легитимным SSL-сертификатом, активно перехватывающий трафик. Этот узел выдаёт себя за легитимный сервер, предъявляя валидный сертификат, и появляется возможность провести MITM-атаку.
Согласно исследованию команд из Mozilla, Google и ряда университетов, примерно 11% защищенных соединений в сети «прослушиваются». Это — результат установки подозрительных корневых сертификатов на компьютерах пользователей.
Как защититься. Пользоваться услугами надежных SSL-провайдеров. Проверить «качество» сертификатов можно с помощью сервиса Certificate Transparency (CT). Помочь с обнаружением «прослушки» могут и облачные провайдеры — уже сегодня некоторые крупные компании предлагают специализированные инструменты для мониторинга подключений по TLS.
Другим способом защиты станет новый стандарт ACME, который автоматизирует получение SSL-сертификатов. При этом он добавит дополнительные механизмы для проверки собственника сайта. Подробнее о нем мы писали в одном из наших предыдущих материалов.
/ Flickr / Yuri Samoilov / CC BY
Подмена сертификата шифрования, firewall, agents, антивирусы, системы безопасности
Подмена сертификата шифрования
Чтобы убедиться в отсутствии факта перешифровки https-трафика антивирусными программами или proxy. Для этого существует два метода:
Зайдите на портал диагностики, в раздел “Проверка связи” (
https://help.kontur.ru/check). Если в какой-то строчке не стоит галочка, а значение в столбике “Сертификат” подсвечено красным – сертификат подменяется. Необходимо выявить, какой программой выдан сертификат, и настроить её таким образом, чтобы она не вмешивалась в криптографию нашего сервера, либо “научить” программу работать с ГОСТ-овской криптографией. Описание программ, которые могут влиять на подмену сертификата ниже.Зайдите на сайт
https://auth.kontur.ru, нажмите левой клавишей мыши по значку «замкА»(возле адресной строки) либо правой кнопкой мыши на страницеСвойстваСертификаты и проверьте, какой сертификат сервера предлагается клиенту. Сертификат должен быть таким:
Если сертификат другой, значит на стороне абонента происходит перешифровка https-трафика. Необходимо выявить, какой программой выдан сертификат, и настроить её таким образом, чтобы она не вмешивалась в криптографию нашего сервера, либо “научить” программу работать с ГОСТовской криптографией. Описание программ, которые могут влиять на подмену сертификата ниже.
Firewall
1. StaffCop Agent(
http://www.staffcop.ru/help/standard/agent.htm) Система контроля доступа, система учета рабочего времени, контроль и ограничение доступа. Подменяет сертификат на auth.kontur.ru
Решение: отключить/настроить данный агент.
2. На ISA-сервере: bluecoat proxy: не поддерживает ГОСТ-шифрование. Подменяет сертификат на auth.kontur.ru
Решение: отключить/настроить proxy.
3. На ISA-сервере: McAfee Web Gateway 7.2.0.1.0.13253(может быть установлен на прокси-сервере): не поддерживает ГОСТ-шифрование, ошибка The SSL handshake could not be performed. error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number.
Решение: настроить так чтобы пропускал и не вмешивался в пакеты от серверов СКБ Контур. Пустить трафик в обход прокси.
4. На ISA-сервере: Kerio: подменяет содержимое страниц.
5. Adguard (
http://adguard.com/ru). Фильтр интернет-рекламы. Подменяет сертификат сервера на
https://reg.kontur-pf.ru
Решение: добавить сайты контура в исключение данной программы.
Антивирусы:
1. Avast Особенности: подменяет сертификаты сайтов с ГОСТ-овским шифрованием, блокирует открытие некоторых https-сайтов.
Решение: отключить активную защиту для https-сайтов: для этого зайти в настройки Аваста – Активная защита – Веб-экран – Настройки – снять галочки
2. ESET Smart Security: при связи с сервером pki.kontur-extern.ru выдает ошибку: Базовое соединение закрыто: Соединение было неожиданно закрыто
Решение: Отключить фильтрацию https-протоколов в ESET Smart Security. Для этого надо:
Открыть ESET/Выбрать “Настройка”/Справа внизу выбрать “Дополнительные настройки”/Слева выбрать “Интернет и электронная почта”/Выбрать подпункт “Защита доступа в интернет”/Посередине выбрать блок “Веб-протоколы”/В подразделе “Настройка модуля” снять галочку с пункта “Включить проверку протокола HTTPS”
3. На ISA-сервере: Searchinform: состоит из компонента EndpointSniffer и агента SIFilterSvc.exe (служба под LocalSystem).
Особенности: подменяет сертификат уже на самом ПК(CN = Generic Root CA, C = EN), в логах NetWorkMonitor не отбражается.
Решение: Отключить службу SIFilterSvc.exe.
4. Falcongaze SecureTower: Система SecureTower, созданная для обеспечения информационной безопасности и защиты информации в компании представляет собой программный продукт, решающий две основные задачи: защита информации от утечки, а также анализ эффективности работы персонала (
http://falcongaze.ru/products/secure-tower/). Не работает с ГОСТ-ом.
Решение: Отключить/настроить
5. Spider Gate (dr.web):
Решение: Отключить фильтрацию https-протоколов в Spider Gate (dr.web)
6. Kaspersky Internet Security
Решение:
http://support.kaspersky.ru/6271 – тут находится инструкция по отключению фильтрации https-протоколов в KIS, в зависимости от версии Касперского некоторые элементы интерфейса могут отличаться.
Также возможно вмешательство надстроек Kaspersky Internet Security, которые необходимо отключить:
Kaspersky Protection;
Kaspersky Protection Toolbar;
Также нужно отключить:
1. Внедрение скриптов Касперского и проверку защищенных соединений:
Примерная инструкция (может отличаться в зависимости от версии Касперского):
Настройки -> Дополнительно -> Сеть -> Внедрять в трафик скрипт для взаимодействия с веб-страницами.
2. Отключить “Автоматически активировать расширениеKaspersky Protection в браузерах” . Примерная инструкция(может отличаться в зависимости от версии Касперского):
Настройки -> Защита -> Веб-Антивирус (или Веб-Защита) -> Расширенные настройки.
Вирусы/adware/рекламные программы
1. Researchbar:
Издатель в сертификате: ZAO TNS Gullup Media
решение: удалить researchbar
2. pBot:
Издатель в сертификате: Copper Sphere
решение:
1) Если программа видна в “Программы и компоненты” – удалить оттуда.
2) Если программа не видна в “Программы и компоненты”, но диагностика в разделе “Антивирусы и программы” указывает на присутствие данной программы, она покажет пути, где лежат исполняемые файлы. Их нужно будет удалить вручную.
3) Если в диагностике ничего нет, проверить путь “C:Documents and Settings%Username%Application DataPBot”, удалить при наличии.
Назад к списку статей
Пользовательские интерфейсы
Разработчики браузеров используют методику кнута и пряника, чтобы заставить пользователей заботиться о своей безопасности. Ярко-красная картинка, показанная выше, а также необходимость нажимать лишнюю кнопку «Продолжить всё равно» – это кнут, который побуждает пользователей избегать сайтов, где есть нарушения в работе SSL.
Каков же пряник? Единственное «поощрение» за посещение сайтов, правильно использующих SSL – зеленый цвет или картинка «замочка» в адресной строке.
Сайты, правильно использующие SSL, с разным классом сертификатов:
К сожалению, последнее встречается даже на крупных сайтах, лишний раз снижая внимание пользователей к этому значку в адресной строке.
По картинкам видим, что кнут используется чаще и сам по себе заметнее, чем пряник.
Привязка ssl-сертификата к серверу
Для определения соответствия “сервер-сертификат” нажмите кнопку Привязки сертификатов и следуйте рекомендациям, приведенным далее:
- Для привязки к определенному серверу корневого сертификата на вкладке Корневые сертификаты, нажмите кнопку Добавить сертификат для сайта. Введите имя хоста (доменное имя), на которое будут выданы дочерние сертификаты и к которому будет привязан корневой сертификат, в поле Имя хоста (IP-адрес). Выберите один из предустановленных корневых сертификатов в раскрывающемся списке поля Корневой сертификат либо нажмите кнопку Пользовательские сертификаты для добавления и указания файлов сертификата и закрытого ключа на компьютере пользователя.
- Для привязки к определенному серверу уже имеющегося сертификата, выберите вкладку Пользовательские сертификаты. Агент не будет генерировать для указанных в данной вкладке серверов новые дочерние сертификаты, а будет использовать для процедур подмены сертификаты, заданные пользователем. В открывшемся окне в поле Имя хоста (IP-адрес) введите имя хоста (доменное имя), к которому будет привязан сертификат. Выберите один из сертификатов в раскрывающемся списке поля Сертификат: (если сертификаты уже добавлялись ранее) либо нажмите кнопку Пользовательские сертификаты для выбора пользовательских сертификатов из списка либо добавления и указания файлов сертификата и закрытого ключа на компьютере пользователя.
Создание фальшивых ssl сертификатов или новогодний подарок для фишеров
Мы обнаружили уязвимость в Internet Public Key Infrastructure (PKI), используемой для выдачи цифровых сертификатов для Web сайтов. В качестве примера мы продемонстрировали часть атаки и успешно создали фальшивый CA сертификат, которому доверяют все современные браузеры. Сертификат позволяет нам выдать себя за любой сайт в интернете, использующий HTTPS, включая сайты банков и online магазинов.
Валерий Марчук
www.my-sertif.ru
Вчера закончилась конференция 25C3 (25th Chaos Communication Congress) в Берлине. Одним из самых громких докладов на конференции стал доклад Александра Сотирова (Alexander Sotirov), Марка Стивенса (Marc Stevens) и Джекоба Аппельбаума (Jacob Appelbaum) – MD5 considered harmful today: Creating a rogue CA certificate. В этой статье я кратко опишу суть уязвимости и постараюсь ответить на возможные вопросы.
«Мы обнаружили уязвимость в Internet Public Key Infrastructure (PKI), используемой для выдачи цифровых сертификатов для Web сайтов. В качестве примера мы продемонстрировали часть атаки и успешно создали фальшивый CA сертификат, которому доверяют все современные браузеры. Сертификат позволяет нам выдать себя за любой сайт в интернете, использующий HTTPS, включая сайты банков и online магазинов»[1].
Суть уязвимости
Многие центры сертификации до сих пор используют MD5 хеши для проверки подлинности сертификатов. С 2004 года достоверно известно, что MD5 хеши являются слабыми с криптографической точки зрения. Злоумышленник может создать фальшивый сертификат-посредник центра сертификации (CA), и с его помощью, подписать произвольное количество сертификатов, например, для Web серверов, которые будут считаться доверенными для коневых сертификатов – тех, которые находятся в «доверенном списке» в вашем браузере. Александру Сотирову, Марку Стивенсу и Джекобу Аппельбауму удалось создать фальшивый сертификат, выдающий себя за подлинный сертификат от RapidSSL. Для генерации фальшивого сертификата было сделано 4 покупки действительных сертификатов у RapidSSL, и использовался кластер из 200 станций Sony PlayStation 3 для коллизионной атаки. В основе атаки лежит метод обнаружения коллизий в MD5 хешах. В данный момент атака считается сложно реализуемой, но продемонстрированной на практике.
Исследователи собрали 30 000 сертификатов для Web серверов, 9 000 из которых были подписаны MD5, 97% сертификатов принадлежали RapidSSL.
Воздействие уязвимости
Злоумышленник может произвести атаку типа «человек посередине», выдать себя за доверенный хост и перехватить потенциально важные данные. Для выполнения необходимых подсчетов злоумышленники могу использовать ботнет средних размеров и получить необходимые результаты в довольно короткие сроки.
Уязвимые протоколы
Уязвимость распространяется на все протоколы, использующие SSL:
SSH не уязвим к этой атаке.
Компании, выпускающие уязвимые сертификаты
- RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1 - FreeSSL (бесплатные временные сертификаты, предлагаемые RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications - TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de - RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority - Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com - verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA – Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Сценарий атаки
Атакующий запрашивает легитимный сертификат для Web сайта у коммерческого центра сертификации (CA), которому доверяют браузеры. Поскольку запрос является легитимным, CA подписывает сертификат и выдает его злоумышленнику. Для атаки используется CA, который использует алгоритм MD5 для генерации подписей для сертификатов. Второй сертификат – сертификат посредника центра сертификации, который можно использовать для выдачи сертификатов для других сайтов. Поскольку MD5 хеши обоих сертификатов – действительного и фальшивого – одинаковые, цифровая подпись, полученная от коммерческого CA, может быть просто скопирована в фальшивый CA сертификат, который будет оставаться действительным.
Ниже приведена схематическая диаграмма того, как должны работать сертификаты для Web сайтов и описание:
- Центр сертификации выпускает свой корневой сертификат и передает его через производителей браузеров клиентам. Эти корневые сертификаты находятся в «доверенном списке» на системе пользователя. Это означает, что все сертификаты, выданные этим CA, по умолчанию будут доверенными для пользователя.
- Компания, которая желает защитить пользователей своего сайта, приобретает сертификат для Web сайта в центре сертификации. Этот сертификат подписывается CA и гарантирует идентичность Web сайта для пользователя.
- Когда пользователь желает посетить защищенный Web сайт, браузер запрашивает у Web сервера сертификат. Если подпись будет подтверждена сертификатом CA в списке доверенных сертификатов, сайт будет загружен в браузер и обмен данными между сайтом и браузером будет происходить с использованием шифрования.
Следующая диаграмма демонстрирует сценарий атаки с подменой существующего Web сайта.
- Легитимный сертификат для Web сайта приобретается у коммерческого CA (голубой сертификат на диаграмме)
- Создается фальшивый CA сертификат (черный на диаграмме). Он содержит туже подпись, что и сертификат, выданный для Web сайта, поэтому, браузер полагает, что этот сертификат был выдан действительным CA.
- С помощью фальшивого CA, злоумышленник создает и подписывается новый сертификат для Web сайта (красный на диаграмме) с новым публичным ключом. Создается копия доверенного сайта, размещается на Web сервере с фальшивым сертификатом.
Когда пользователь посещает защищенный сайт, браузер осуществляет поиск Web сайта. Существуют различные способы, с помощью которых злоумышленник может перенаправить пользователя на специально сформированный Web сайт. Этот Web сайт предоставит пользователь фальшивый сертификат, совместно с фальшивым CA сертификатом. Подлинность фальшивого сертификата для Web сайта подтверждается фальшивым CA сертификатом, который, в свою очередь, будет подтвержден коневым CA сертификатом. Браузер согласится принять такой сертификат и пользователь ничего не заметит.
Векторы атаки
Злоумышленник может осуществить атаку типа «человек посредине» и перехватить трафик целевого пользователя. Возможные векторы атак:
Атака по локальной сети:
- Небезопасные беспроводные сети
- ARP спуфинг
- Автоматическое обнаружение прокси серверов
Удаленная атака:
- DNS спуфинг
- Компрометация маршрутизатора
Насколько опасна эта уязвимость?
Существующая проблема позволяет создать идеальные фишинговые сайты с действительными SSL сертификатами. Злоумышленник сможет обмануть даже профессионала, выбрав правдоподобное имя для центра сертификации. Имея возможность произвести атаку «человек посередине», злоумышленник сможет, незаметно для пользователя, перенаправить трафик на специально сформированный сервер и получить доступ к потенциально важным данным. Владельцы сайтов, которые используют SSL сертификаты, никак не смогут защитить своих клиентов. Даже если сертификат для Web сайта подписан алгоритмом SHA1, злоумышленник все равно может использовать фальшивый MD5 сертификат.
Какие существуют средства защиты?
На самом деле пользователи не могут сделать многого. Проблема заключается не в браузерах и не в SSL – а в центрах сертификации.
- В качестве временного решения рекомендуется максимально ограничить количество центров сертификации, которым вы доверяете, и исключить из списка доверенных центры сертификации, перечисленные выше.
- Все подробности уязвимости не разглашены, поэтому вероятность подобной атаки уменьшается.
- Сертификат, который использовался для демонстрации уязвимости, является просроченным.
- Компании могут настроить OSCP сервер и отозвать потенциально опасные сертификаты. Внимание, фальшивый сертификат может содержать некорректные данные о CRL и такой сертификат будет проблемно отозвать.
Ссылки
- http://www.win.tue.nl/hashclash/rogue-ca/
- http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt
- http://www.microsoft.com/technet/security/advisory/961509.mspx
- http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/
- http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx