Валерий Марчук

Вчера закончилась конференция 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