Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
6. Убедитесь, что аутентификационные сообщения нельзя подделать. В частности, если для аутентификации применяется цифровая подпись на открытом ключе, проверьте, можно ли доверять открытому ключу другой стороны. Обычно для этого нужно либо свериться со статическим списком известных сертификатов, либо воспользоваться инфраструкторой открытых ключей (PKI), контролируя попутно все относящиеся к делу поля сертификата. Подробнее см. грех 10.
7. Если процедура аутентификации может быть атакована, проверьте, относится ли это только к первой успешной попытке входа в систему или также и ко всем последующим. Если начальная аутентификация может быть атакована, а последующие – нет, то аудитор должен признать, что оснований для беспокойства куда меньше, чем в случае, когда угрозе атаки с «человеком посередине» подвержены все соединения. Обычно при этом запоминаются верительные грамоты хоста и при последующем соединении с тем же хостом сравниваются с предъявленными.
Тестирование
Как и в большинстве других случаев применения криптографии к защите сети, довольно трудно доказать корректность системы, тестируя ее как черный ящик. Гораздо проще обнаружить такого рода проблемы в ходе анализа кода.
Примеры из реальной жизни
Атаки с «человеком посередине» хорошо известны. Мы неоднократно сталкивались с этой проблемой в «реальных» системах, когда за основу бралось какое–то решение, описанное в литературе, а затем над ним пытались надстроить криптосистему. Отметим еще, что этому греху подвержены многие системы, построенные на базе SSL или TLS.
Существуют даже инструменты для эксплуатации общих проявлений этой уязвимости, в том числе для атаки с «человеком посередине» на протоколы SSL и SSH. Например, dsniff.
Помимо распространенных случаев неправильного применения SSL/TLS, есть примеры, когда протокол аутентифицированного обмена ключами (скажем, Kerberos) используется для аутентификации, но выработанный ключ не применяется в криптографических целях. В результате нет никакой криптографической связи между аутентификацией и последующими сообщениями (обычно последующие сообщения вообще не подвергаются никакой криптографической обработке).
В настоящее время в базе данных CVE есть 15 сообщений, включающих фразу «man–in–the–middle». Но наш опыт показывает, что эта проблема куда более распространена, чем кажется на основе этой цифры.
Атака с «человеком посередине» на Novell Netware
Это пример неправильной сборки протокола из составных частей. В феврале 2001 года компания BindView обнаружила возможность атаки с «человеком посередине» против операционной системы Novell Netware, в которой использовался некорректный протокол обмена ключами и аутентификации. Этот «самописный» протокол был основан на схеме обмена ключами на базе алгоритма RSA, а не Диф–фи–Хеллмана. Авторы попытались выполнить аутентификацию по парольному протоколу, но не сумели надлежащим образом аутентифицировать сами сообщения, необходимые для обмена ключами. Протокол проверки пароля шифровался с помощью RSA–ключей, но пароль не использовался для проверки того, что ключи действительно принадлежат участникам. Противник мог подделать сервер, и тогда клиент передал бы противнику валидатор пароля, зашифрованный своим открытым ключом. После этого противник мог предъявить этот валидатор серверу, и это сработало бы, следовательно, противник мог выступить в роли «человека посередине».
CAN–2004–0155
Многие системы, в которых используются протоколы высокого уровня, например SSL, пали жертвой этой проблемы. Серьезные ошибки были обнаружены даже в базовых реализациях основных программ обеспечения безопасности. В качестве впечатляющего примера можно привести сообщение CAN–2004–0155 из базы данных CVE.
Программа Каше IKE (Internet Key Exchange – обмен ключами через Интернет) Daemon является частью реализации протокола IPSec, широко используемого для организации виртуальных частных сетей (VPN). Она по умолчанию входит в состав дистрибутивов нескольких операционных систем. Во время инициализации соединения аутентификация производится на основе либо предварительно разделенных ключей, либо сертификатов Х.509 с цифровой подписью RS А Когда применяются сертификаты Х.509, Daemon контролирует поля сертификата, но неправильно проверяет корректность подписи RSA
Разработчики, очевидно, думали, что вызываемая функция возвращает признак успеха, только если подпись действительна. На самом же деле ничего подобного не происходит, функция всегда завершается успешно. Следовательно, проверка подписи всегда дает положительный результат. И потому кто угодно может создать фальшивый сертификат Х.509 с правильно заполненными полями, подписать его и пройти аутентификацию.
Это не проблема протокола IPSec как такового. Мы имеем лишь ошибку в одной из его реализаций. Этот пример показывает, что даже реализация хорошо известных протоколов может оказаться трудным делом. Подобные ошибки были обнаружены также в Microsoft CryptoAPI (CAN–2002–0862) и в программном обеспечении VPN компании Cisco (CAN–2002–1106).
Искупление греха
Мы настоятельно рекомендуем пользоваться готовыми решениями на базе протоколов SSL/TLS или Kerberos при условии, что они реализованы правильно! Убедитесь, что вы производите все действия, необходимые для надлежащей аутентификации (см. грех 10). Также убедитесь, что выработанный в результате обмена ключ применяется для последующей аутентификации всех сообщений. В случае SSL/TLS это обычно происходит автоматически. (Обычно подозрения падают, скорее, на качество аутентификации.) Но в других системах ключ – это конечный результат, а забота о его правильном применении ложится на вас.
Не проектируйте собственные протоколы. Есть очень много тонких мест, где легко допустить ошибку. Если вы полагаете, что необходим нестандартный протокол, поручите эту задачу криптографу. Мы могли бы составить список свойств, на которые следует обращать внимание, но это лишь вселило бы в вас чувство ложной уверенности. В кругу специалистов, занимающихся проектированием шифров, часто говорят, что «любой может построить шифр, который сам не сумеет вскрыть», но очень редко удается сделать нечто такое, что не поддается усилиям всего сообщества криптографов. То же относится к протоколам аутентификации и обмена ключами.
Если в системе уже используется некий «самописный» протокол, рассмотрите возможность перехода на готовое решение. В этом случае риск, что нечто реализовано неверно, уменьшается, а природа возможных проблем хорошо описана, как, например, для SSL/TLS. Кроме того, мы рекомендуем нанять криптографа для анализа имеющегося протокола. Было бы прекрасно, если бы он предъявил доказательство корректности или, по крайней мере, продемонстрировал устойчивость к атакам, описанным к литературе по криптографии. Его выводы должны быть представлены на суд экспертов.
Дополнительные защитные меры
Нам неизвестны Дополнительные защитные меры от этого греха.
Другие ресурсы
□ Protocols for Authentication and Key Establishment by Colin Boyd and Anish Mathuria (Springer, 2003)
Резюме
Рекомендуется
□ Уясните, что обмен ключами сам по себе часто не является безопасной процедурой. Необходимо также аутентифицировать остальных участников.
□ Применяйте готовые решения для инициализации сеанса, например SSL/ TLS.
□ Убедитесь, что вы разобрались во всех деталях процедуры строгой аутентификации каждой стороны.
Стоит подумать
□ О том, чтобы обратиться к профессиональному криптографу, если вы настаиваете на применении нестандартных решений.
Грех 18. Случайные числа криптографического качества
В чем состоит грех
Представьте, что вы играете в онлайновый покер. Компьютер тасует и сдает карты. Вы получаете свои карты, а какая–то другая программа сообщает, что на руках у партнеров. Хотя такой сценарий кажется преувеличенным, но нечто подобное случалось на практике.
Случайные числа применяются для решения разных задач. Помимо тасования колоды, они часто используются для генерирования криптографических ключей и идентификаторов сеансов. Если противник может (хотя бы с небольшой вероятностью) предсказать следующее число, то этого может оказаться достаточно для вскрытия системы.
Подверженные греху языки
Случайные числа – это одна из основ криптографии, поэтому они встречаются в самых разных языках. И ошибки при их использовании тоже присущи любому языку.
Как происходит грехопадение
Самый серьезный грех при работе со случайными числами заключается в том, что они не используются там, где следует. Предположим, например, что вы пишете программное обеспечение Интернет–банкинга. Чтобы отслеживать состояние клиента, вы посылаете клиенту кук, содержащий идентификатор сеанса. Допустим, что идентификаторы выделяются последовательно. Что может случиться? Если противник следит за куками и видит, что получил номер 12, то он может изменить свой номер в куке на 11 и посмотреть, не получил ли он в результате доступ к чужой учетной записи. Желая войти от имени конкретного лица, он может подождать, пока жертва зарегистрируется, затем войти и вычитать по единице из полученного от системы идентификатора, пока не доберется до номера, присвоенного жертве.
