31.12.2008

Создание фальшивых SSL сертификатов или новогодний подарок для фишеров

Мы обнаружили уязвимость в Internet Public Key Infrastructure (PKI), используемой для выдачи цифровых сертификатов для Web сайтов. В качестве примера мы продемонстрировали часть атаки и успешно создали фальшивый CA сертификат, которому доверяют все современные браузеры. Сертификат позволяет нам выдать себя за любой сайт в интернете, использующий HTTPS, включая сайты банков и online магазинов.

Валерий Марчук
www.SecurityLab.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:

  • HTTPS
  • SSL VPN
  • S-MIME

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 сайтов и описание:

  1. Центр сертификации выпускает свой корневой сертификат и передает его через производителей браузеров клиентам. Эти корневые сертификаты находятся в «доверенном списке» на системе пользователя. Это означает, что все сертификаты, выданные этим CA, по умолчанию будут доверенными для пользователя.
  2. Компания, которая желает защитить пользователей своего сайта, приобретает сертификат для Web сайта в центре сертификации. Этот сертификат подписывается CA и гарантирует идентичность Web сайта для пользователя.
  3. Когда пользователь желает посетить защищенный Web сайт, браузер запрашивает у Web сервера сертификат. Если подпись будет подтверждена сертификатом CA в списке доверенных сертификатов, сайт будет загружен в браузер и обмен данными между сайтом и браузером будет происходить с использованием шифрования.

Следующая диаграмма демонстрирует сценарий атаки с подменой существующего Web сайта.

  1. Легитимный сертификат для Web сайта приобретается у коммерческого CA (голубой сертификат на диаграмме)
  2. Создается фальшивый CA сертификат (черный на диаграмме). Он содержит туже подпись, что и сертификат, выданный для Web сайта, поэтому, браузер полагает, что этот сертификат был выдан действительным CA.
  3. С помощью фальшивого CA, злоумышленник создает и подписывается новый сертификат для Web сайта (красный на диаграмме) с новым публичным ключом. Создается копия доверенного сайта, размещается на Web сервере с фальшивым сертификатом.
  4. Когда пользователь посещает защищенный сайт, браузер осуществляет поиск Web сайта. Существуют различные способы, с помощью которых злоумышленник может перенаправить пользователя на специально сформированный Web сайт. Этот Web сайт предоставит пользователь фальшивый сертификат, совместно с фальшивым CA сертификатом. Подлинность фальшивого сертификата для Web сайта подтверждается фальшивым CA сертификатом, который, в свою очередь, будет подтвержден коневым CA сертификатом. Браузер согласится принять такой сертификат и пользователь ничего не заметит.

Векторы атаки

Злоумышленник может осуществить атаку типа «человек посредине» и перехватить трафик целевого пользователя. Возможные векторы атак:

Атака по локальной сети:

  • Небезопасные беспроводные сети
  • ARP спуфинг
  • Автоматическое обнаружение прокси серверов

Удаленная атака:

  • DNS спуфинг
  • Компрометация маршрутизатора

Насколько опасна эта уязвимость?

Существующая проблема позволяет создать идеальные фишинговые сайты с действительными SSL сертификатами. Злоумышленник сможет обмануть даже профессионала, выбрав правдоподобное имя для центра сертификации. Имея возможность произвести атаку «человек посередине», злоумышленник сможет, незаметно для пользователя, перенаправить трафик на специально сформированный сервер и получить доступ к потенциально важным данным. Владельцы сайтов, которые используют SSL сертификаты, никак не смогут защитить своих клиентов. Даже если сертификат для Web сайта подписан алгоритмом SHA1, злоумышленник все равно может использовать фальшивый MD5 сертификат.

Какие существуют средства защиты?

На самом деле пользователи не могут сделать многого. Проблема заключается не в браузерах и не в SSL – а в центрах сертификации.

  • В качестве временного решения рекомендуется максимально ограничить количество центров сертификации, которым вы доверяете, и исключить из списка доверенных центры сертификации, перечисленные выше.
  • Все подробности уязвимости не разглашены, поэтому вероятность подобной атаки уменьшается.
  • Сертификат, который использовался для демонстрации уязвимости, является просроченным.
  • Компании могут настроить OSCP сервер и отозвать потенциально опасные сертификаты. Внимание, фальшивый сертификат может содержать некорректные данные о CRL и такой сертификат будет проблемно отозвать.

Ссылки

  1. http://www.win.tue.nl/hashclash/rogue-ca/
  2. http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt
  3. http://www.microsoft.com/technet/security/advisory/961509.mspx
  4. http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/
  5. http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx
или введите имя

CAPTCHA
Перат
31-12-2008 10:10:27
# В качестве временного решения рекомендуется максимально ограничить количество центров сертификации, которым вы доверяете, и исключить из списка доверенных центры сертификации, перечисленные выше. Может, лучше просто запретить использование сертификатов с MD5, независимо от центра сертификации?
0 |
GAW
31-12-2008 12:28:06
Представляешь сколько есть легитимных сайтов, использующих сертификаты, подписанные md5? Сколько денег и времени будет потрачено на замену этих сертификатов? Сколько программ должно быть переписано? Это не только браузеры, коих и так пруд-пруди, а всяческие клиент-банки, VPN-ы и т.д...
0 |
Bugg
31-12-2008 13:28:09
О чем это вы?! PKI изначально предполагает, что любой подписанный сертификат может быть отозван, равно как и скомпрометированный корневой сертификат может и должен быть забракован по иным каналам доставки. Если PKI-вендор и/или его клиенты не озаботились механизмом обновления CRL, это их пробелмы, и жертвовать безопасностью всех пользователей ради кучки балбесов, по-моему, смысла никакого нет. Тем более, ради тех копеечных трат, практически равных нулю, сколько на самом деле будет стоить замена сертификатов, по крайней мере, для почтовых и веб-сайтов. А на счет специального оборудования и ПО... Тут могут возникнуть сложности, но это, опять же, проблемы балбесов и их клиентов. Подумайте, чем замена CA-сертификатов в данной стиуации отличается от их плановой замены раз в год-несколько? Ничем. Поэтому если вдруг (!) для отдельного вендора замена сертификатов на клиентах представляет особые трудности, делать скидку здесь не на что, я считаю.
0 |
66342
03-01-2009 15:42:17
Представляешь сколько есть легитимных сайтов, использующих сертификаты, подписанные md5? Сколько денег и времени будет потрачено на замену этих сертификатов? Сколько программ должно быть переписано? Это не только браузеры, коих и так пруд-пруди, а всяческие клиент-банки, VPN-ы и т.д... Об этом по хорошему надо было беспокоться, когда были только теоретические атаки на MD5 без приложения к протоколам. Вот из PGP MD5 был убран в 2004 году.
0 |
31-12-2008 10:25:36
только я расслабился перед Новым годом >1.Легитимный сертификат для Web сайта приобретается у коммерческого CA (голубой сертификат на диаграмме) Поскольку первый пункт нереален, то и все остальные пункты нереальны. Посмотрю я на вас, если вы вдруг напишете в Thawte или Verisign - выдайте-ка мне, люди добрые, новый сертификат на чужой Интернет банк. А сама теоретическая основа атаки тоже теперь невозможна - RapidSSL подправили. И вот еще ответ сотрудника Verisign про невозможность этой атаки https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php
0 |
11-01-2009 11:43:06
Ксива, не тормози. В первом пункте запрашивается сертификат для абстрактного веб-сайта.
0 |
ДЕД МОРОЗ
31-12-2008 11:18:32
Всех с Новым Годом Так же отдельные поздравления Билл Гейтсу
0 |
Bugg
31-12-2008 13:48:13
Секлаб занят перепечатыванием чужих статей... Могли бы, для разнообразия, дать оценку состоятельности PKI интернета в сегодняшнем виде. В данный момент атака считается сложно реализуемой, но продемонстрированной на практике. Исследователи собрали 30 000 сертификатов для Web серверов, 9 000 из которых были подписаны MD5, 97% сертификатов принадлежали RapidSSL.Кем считается, мелкософтом? Там вообще замалчивают истинную суть проблемы и пишут откровенный бред. Дэйв Эйтел, например, уже озвучил позицию Immunity. О сложности проведения атаки он не говорит - скорее, наоборот: I don't see why people think this would be hard to replicate and hasn't been done previously to RapidSSL. Is it because no one other than that one team can do math or buy PS3s? Уязвимость распространяется на все протоколы, использующие SSL: * HTTPS * SSL VPN * S-MIME SSH не уязвим к этой атаке.IPsec забыли, DNSSEC. OpenSSH тоже, хоть и не по умолчанию, поддерживает аутентификацию по доверенным сертификатам.
0 |
mr_gfd
01-01-2009 17:47:29
O dnssec u ssh бред сказал.
0 |
Bugg
02-01-2009 10:05:43
Не бред. Расширяйте кругозор.
0 |
RU_LIDS
01-01-2009 22:51:16
ipsec только в случае применения X.509 аутентификации, либо L2TP over IPSec. PSK и RSASIG аутентификации не подвержены!
0 |
Bugg
02-01-2009 10:13:04
ipsec только в случае применения X.509 аутентификацииТак и DNSSEC уязвим "только в случае" применения RSA/MD5, который не рекомендован в RFC и не должен использоваться. Я хотел сказать, что уязвимость заключается в возможности подбора коллизий для подписанного MD5-хеша, и что ей подвержены не только SSL и X.509 PKI, но и другие аналогичные протоколы. Кстати, IPsec широко применяется с сертификатами, и его авторам статьи уж точно надо было упомянуть.
0 |