06 октября, 2009
Автор: Moxie Markinspike
Перевод: cens
В этой статье описаны новые приёмы для проведения недетектируемых Man-in-the-Middle (MitM) атак на большинство существующих реализаций SSL/TLS.
Протоколы 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).
Множество реализаций 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)
(Голосов: 19, Рейтинг: 3.94) |
Перед выходом в Интернет каждый пользователь ПК должен будет пройти обязательный курс подготовки и ...
Компания Mozilla сегодня выпустила два экстренных бюллетеня по информационной безопасности, где гово ...
Посетители форума Microsoft TechNet утверждают, что срок службы аккумулятора заметно сократился посл ...
Сайт премьер-министра Украины Юлии Тимошенко был взломан хакерами. Вместо стартовой страницы на сайт ...
На днях директор ФБР Роберт Мюллер заявил, что он собирается добиваться того, чтобы провайдеры из СШ ...
В январе 2010 года основное количество обращений пользователей по поводу активных заражений было свя ...
Только за январь число пострадавших в России от блокировщиков Windows составило несколько миллионов ...
По новой информации, клиентская операционная система Windows 8 выйдет уже в следующем году. Известно ...
Орджоникидзевский районный суд г. Екатеринбурга вынес решение по иску прокурора Орджоникидзевского р ...
В опубликованном на сайте Microsoft уведомлении говорится, что уязвимость может эксплуатироваться зл ...
Инициатива рассчитана на три года, предполагаемый объем инвестиций составит 151,5 млн рублей. До кон ...
В ходе исследования выяснилось, что 99% файлов, проходящих через торрент-сети, содержат нелиценз ...
Имеем паскалевую строку, прибывшую к нам в Сишную программу извне. Нам надо из паскалевской строки сделать Сишную. Я прав?
Что-то мне подсказывает, что для этого используется какая-либо стандартная библиотека. И функция тупо откидывает первый байт, копирует нужное количество символов из буфера А в буфер Б, добавляет в конец \0 и довольная возвращает указатель на Б. Правильно?
Тогда вопрос КАКОГО *** крендель писавший эту функцию не сподобился проверить наличие запрещенного символа в пределах пришедшей строки?
Это так сложно предположить, что из паскалевской строки, где разрешено "все-что-угодно", именно это "все-что-угодно" и прийдет?
memcpy(src + 1, dst, src[0]);
if (!strcmp(dst, currentDomain))
{
// ok
}
понятно, что нужно сделать, чтобы исправить ситуацию.
http://www.gentoo.org/security/en/gls...910-01.xml