Атака нулевым символом против SSL/TLS сертификатов

Moxie Marlinspike

Основы

  Протоколы SSL и TLS разработаны с целью обеспечения секретности, достоверности и целостности связи как от пассивных, так и от активных действий злоумышленников. SSL и TLS полностью доверяют структуре сертификатов x509 для доставки аутентификационных данных и оба участника SSL/TLS соединения имеют возможность идентифицировать друг друга с помощью сертификата x509v3.

  Изначальной целью комитета стандартов x509 было создание структуры сертификата, который смог бы уникально идентифицировать каждого в глобальной системе каталогов (http://en.wikipedia.org/wiki/Directory_Information_Tree). Несмотря на то, что это требование никогда полностью не было реализовано, SSL/TLS не нуждается в серьёзной проверке иерархической части сертификата. Для протоколов SSL/TLS для идентификации каждого конкретного сервера используется поле "common name" в заголовке x509 сертификата. Большая часть информации в поле "distinguished name" просто игнорируется. Например, PayPal запишет www.paypal.com в поле "common name", Ebay запишет www.ebay.com, а Bank Of Amerika - www.bankofamerica.com.

  Процесс подписания запросов в современных центрах сертификации (CA) полностью доверяет этому соглашению. Лица, посылающие им запросы на подписание сертификатов, проверяются на основе владения доменом, который записан в поле "common name". Например, CA проверяет технический или административный контакт из базы данных WHOIS и посылает письмо с подтверждением.

  Важно то, что идентификационная информация ассоциирована только с корневым доменом, большинство CA полностью игнорируют содержимое поддоменов, которое может содержаться в подписи. Например, Verisign не проверяет, посылаете ли вы запрос на www.ebay.com или на verisign.eats.children.ebay.com, или даже на this.subdomain.does.not.exist.ebay.com, пока вы можете доказать, что владеете доменом ebay.com

Суть уязвимости

  x509 сертификаты сформированы с помощью нотации ASN.1. Она поддерживает большое количество типов строковых данных, но все они представляются в виде варианта строки PASCAL.В памяти PASCAL строки представлены байтами, указывающими длину строки и последовательностью самих строковых данных. Это отличается от представления строк Си, которые в памяти представляют собой последовательность байт, которая завершается единственным символом NULL.

Строка PASCAL:
[0x04 (длина)][0x44 ('D')][0x41 ('A')] [0x54 ('T')] [0x41 ('A')]

Строка Си:
[0x44 ('D')][0x41 ('A')] [0x54 ('T')] [0x41 ('A')] [0x00 (NULL)]

  Важным моментом в представлении строк PASCAL является то, что нулевые символы (NULL) воспринимаются так же, как и любые другие символы в строке и не имеют какое-либо специальное значение. Это обозначает, что мы легко можем вставить NULL символ в любое поле нашего x509 сертификата, включая поле "common name".

  Некто может выслать центру сертификации запрос, в котором "common name" будет сформирован особым образом:
www.paypal.com\0.thoughtcrime.org

  Как отмечено выше, центр сертификации проигнорирует префикс и проверит только корневой домен, thoughtcrime.org. Если человек, выпустивший запрос - легитимный владелец домена thoughtcrime.org (и, вероятно, он им будет), он будет способен доказать своё право владения доменом центру сертификации без особых сложностей.

  На данный момент, большинство современных имплементаций SSL/TLS воспринимают поля, извлечённые из x509 сертификатов как обычные строки Си, используя обычные функции Си для сравнения и манипуляций с ними. Как результат, сравнение строк "www.paypal.com\0thoughtcrime.org" и "www.paypal.com" будет возвращать значение "идентичны". Вследствие чего владелец сертификата "www.paypal.com\0thoughtcrime.org" может предоставлять свой сертификат соединениям, направленным на www.paypal.com, эффективно обходя защиту SSL/TLS, что позволяет, например, проводить недетектируемую атаку man-in-the-middle (человек посередине).

  Ошибка до сих пор присутствует в Microsoft crypto api, уязвимость эксплуатируется с помощью утилиты sslsniff против всех клиентов, работающих под управлением операционной системы Windows (IE, Chrome, Safari).

Универсальные Wildcard сертификаты

  Множество реализаций SSL/TLS пали жертвами этой уязвимости, но Network Security Services от компании Mozilla оказался в самом тяжёлом положении. Достаточно только заплатить немного больше денег за wildcard сертификат и получить *\0.thoughtcime.org, чтобы полностью скомпрометировать NSS. Из-за способа, которым пользуется NSS для проверки совпадения сертификата, такой сертификат будет подходить для ВСЕХ доменов.

  В то время, как другие имплементации SSL/TLS требуют разных сертификатов для разных сайтов, в коммуникации которых хочет вклиниться злоумышленник, для NSS достаточно, чтобы злоумышленник получил единственный сертификат для того чтобы перехватывать весь трафик приложений NSS (Firefox, Thunderbird, Evolution, Pidgin, AIM) к любому серверу.

Реализация атаки

  Sslsniff был обновлён для поддержки MitM атаки на SSL/TLS.

  Переводил cens, специально для UInC (www.uinc.ru)