19 смертных грехов, угрожающих безопасности программ
Шрифт:
CAN–2004–0155
Многие системы, в которых используются протоколы высокого уровня, например SSL, пали жертвой этой проблемы. Серьезные ошибки были обнаружены даже в базовых реализациях основных программ обеспечения безопасности. В качестве впечатляющего примера можно привести сообщение CAN–2004–0155 из базы данных CVE.
Программа Каше IKE (Internet Key Exchange – обмен ключами через Интернет) Daemon является частью реализации протокола IPSec, широко используемого для организации виртуальных частных сетей (VPN). Она по умолчанию входит в состав дистрибутивов нескольких операционных систем. Во время инициализации соединения
Разработчики, очевидно, думали, что вызываемая функция возвращает признак успеха, только если подпись действительна. На самом же деле ничего подобного не происходит, функция всегда завершается успешно. Следовательно, проверка подписи всегда дает положительный результат. И потому кто угодно может создать фальшивый сертификат Х.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 и посмотреть, не получил ли он в результате доступ к чужой учетной записи. Желая войти от имени конкретного лица, он может подождать, пока жертва зарегистрируется, затем войти и вычитать по единице из полученного от системы идентификатора, пока не доберется до номера, присвоенного жертве.
Генераторы случайных чисел, которые применяются уже много лет, с точки зрения безопасности не выдерживают никакой критики. Пусть даже числа выглядят случайными, противник все равно может угадать следующее число. Даже применяя хороший генератор случайных чисел, вы должны убедиться в том, что его внутреннее состояние не легко предсказать, а это совсем не простая задача.
Рассмотрим проблему внимательнее. Для этого опишем три разных механизма:
□ некриптографические генераторы псевдослучайных чисел (некриптографические PRNG);