Атаки с «человеком посередине» хорошо известны. Мы неоднократно сталкивались с этой проблемой в «реальных» системах, когда за основу бралось какое–то решение, описанное в литературе, а затем над ним пытались надстроить криптосистему. Отметим еще, что этому греху подвержены многие системы, построенные на базе 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).