19 смертных грехов, угрожающих безопасности программ
Шрифт:
Остальные обсуждаемые в этой главе вопросы в большей степени связаны с кодом клиента, так как сервер часто аутентифицирует клиента по паролю или с помощью какого–то другого механизма. Но если используются клиентские сертификаты, то следует применять ту же методологию анализа и к коду сервера.
Для каждой точки входа, защищенной SSL, проверьте, сравнивается ли сертификат со списком известных хороших сертификатов (список разрешенных). В этом случае программа обычно не обращается к коммерческой инфраструктуре PKI, а реализует собственные средства управления сертификатами.
Если сертификат находится в списке допустимых, то все равно остается риск, что он отозван. Не исключено
Если программа не обращается к списку допустимых сертификатов, проверьте, выполнены ли все перечисленные ниже проверки:
□ сертификат подписан известным УЦ или имеется цепочка подписей, ведущая к известному УЦ;
□ срок действия сертификата еще не истек;
□ имя хоста сравнивается со значением в соответствующем подполе хотя бы одного из двух полей: DN или subjectAltName (последнее появилось в версии спецификации Х.509 v3);
□ неудачное завершение любой из этих проверок программа рассматривает как ошибку аутентификации и отказывается устанавливать соединение.
Во многих языках программирования для решения этой задачи приходится глубоко забираться в документацию или даже в сам код. Например, может ветретиться такой код на языке Python, в котором используется стандартный модуль «socket», включенный в Python 2.4:
import socket
s = socket.socket
s.connect((\'www.example.org\', 123))
ssl = socket.ssl(s)
Совершенно не ясно, какие именно проверки библиотека SSL выполняет по умолчанию. В случае Python ответ таков: согласно документации, библиотека не проверяет абсолютно ничего. В других языках могут проверяться срок действия и цепочка доверия, но тогда вы должны быть уверены, что имеется приемлемый список УЦ, и предпринять какие–то действия, если это не так.
Анализируя, насколько правильно реализована работа с отозванными сертификатами, посмотрите, используются ли вообще CRL–списки или протокол OCSP. И в этом отношении API сильно различаются, поэтому лучше изучить тот API, который применен в конкретной программе; поиска по словам «CRL» или «OCSP» без учета регистра обычно достаточно.
В случае, когда используются один или оба этих механизма, нужно обращать внимание на следующие вопросы:
□ производится ли проверка до отправки данных;
□ что происходит, если проверка завершается неудачно;
□ как часто загружаются CRL–списки;
□ проверяются ли сами CRL (особенно если они были загружены по обычному протоколу HTTP или LDAP).
Ищите код, который «заглядывает внутрь» сертификата в поисках некоторых деталей, например, значения поля DN, но не выполняет нужных криптографических операций. Так, следующий фрагмент греховен, поскольку проверяет лишь, что в сертификате есть текст «CN=www. example. сот», но ведь кто угодно мог выпустить для себя сертификат с таким именем:
X509Certificate cert = new X509Certificate;
if (cert.Subject == "CN=www.example.com") {
// Ура, мы общаемся с example.com!
}
Тестирование
В настоящее время имеется несколько программ, которые автоматизируют атаку с «человеком посередине» против HTTPS. В частности, к ним относятся dsniff и ethercap. Впрочем, они работают только против HTTPS,
поэтому при использовании против совместимого с HTTPS приложения должны отображать какое–нибудь окно или иным способом оповещать об ошибке, поскольку в противном случае под угрозой может оказаться вся инфраструктура приложения.К сожалению, по–настоящему стабильные инструменты для автоматизации атак с «человеком посередине» общего назначения против SSL–приложений существуют только в хакерском подполье. Если бы в вашем распоряжении был такой инструмент, то вы могли бы дать ему действительный сертификат, подписанный известным УЦ, например VeriSign, и посмотреть, сумеет ли он расшифровать передаваемые по каналу данные. Если да, значит, исчерпывающая проверка подлинности сертификата не произведена.
Чтобы протестировать, как проверяются отозванные сертификаты по CRL–спискам и OSCP, можно просто проанализировать весь исходящий от приложения трафик за достаточно длительный период времени, сравнивая протоколы и адреса получателей с известными значениями. Если проверка по OSCP производится, то на каждую аутентификацию должен приходиться один запрос по этому протоколу. Если ведется проверка по CRL–спискам и она правильно реализована, то списки должны загружаться периодически, скажем, раз в неделю. Поэтому не удивляйтесь, если в коде проверка по CRL–списку присутствует, а в реальном трафике ее следов не видно. Очень может статься, что список уже был загружен и сохранен на локальном компьютере, чтобы избежать лишнего запроса.
Примеры из реальной жизни
Любопытно, что, несмотря на чрезвычайно широкое распространение этого греха (в тот или иной момент от этой проблемы страдали по меньшей мере 90% приложений, в которых использовался SSL, но не HTTPS), во время работы над книгой в базе данных CVE не было ни одного сообщения на эту тему. Нет их и в других аналогичных базах. В CVE обычно заносятся сведения об уязвимостях в популярных приложениях, а этот грех больше присущ специализированным программам, существующим в единственном экземпляре. Тем не менее примеры у нас имеются.
Почтовые клиенты
Протоколы отправки и приема электронной почты уже довольно давно поддерживают SSL–расширения. Они существуют для протоколов РОРЗ, IMAP и SMTP. Когда такой протокол установлен, клиент регистрируется как обычно, но все это происходит в SSL–защищенном туннеле. Разумеется, перед входом в туннель клиент должен аутентифицировать сервера.
Сразу после появления этих протоколов многие почтовые клиенты не реали–зовывали проверку сертификатов вовсе. Те же, которые что–то делали, не проверяли имя хоста, открывая возможность для атаки. И по сей день большинство клиентов не поддерживают ни CRL–списки, ни протокол OCSP (даже в виде необязательной опции).
Когда в 2001 году появилась операционная система Mac OS X, входивший в нее почтовый клиент вообще не поддерживал SSL. Поддержка была добавлена в следующем году, в версии 10.1, но программа была уязвима для обсуждавшихся выше атак. И только в версии 10.3 авторы наконец осознали необходимость тщательной аутентификации серверных сертификатов (в том числе и проверки полей DN и subjectAltName).
Web–браузер Safari
В протокол HTTPS встроен более тщательный контроль сертификатов, чем предполагается по умолчанию в SSL, и прежде всего потому, что этого требуют спецификации протокола. Если быть точным, HTTPS обязан проверять попадание текущей даты в период действия сертификата, прослеживать всю цепочку доверия от сертификата до корневого УЦ и сравнивать имя хоста с записанными в сертификате данными (хотя допускаются и некоторые исключения).