Специалисты обнаружили критическую уязвимость в протоколах SSL/TLS

Марш Рэй (Marsh Ray) и Стив Диспенса (Steve Dispensa) из компании PhoneFactor обнаружили критическую уязвимость в протоколах SSL/TLS, позволяющую злоумышленнику организовать подстановку своих данных в устанавливаемое между двумя точками защищенное соединение.

Для успешного проведения атаки злоумышленник должен иметь возможность вклинится в проходящий защищенный трафик, например, получить контроль над промежуточным шлюзом, прокси сервером или установить свое оборудование в разрыв сетевого кабеля (man-in-the-middle атака).

Удачно проведенная атака позволяет незаметно добавить свой текст в начало SSL/TLS сессии. Так как часто сеанс работы с сайтом состоит из множества разных SSL/TLS сессий, теоретически злоумышленник может под прикрытием обычной активности пользователя совершить угодные атакующему действия на сервере, при этом пользователь будет уверен, что совершает легитимные операции в рамках защищенного соединения.

Успешно проведенные примеры атак были продемонстрированы при работе различных типов клиентского ПО с web-серверами Apache и Microsoft IIS, также подобная атака возможна и при использовании TLS в IMAP.

Основная проблема обнаруженной уязвимости состоит в том, что уязвимость связана с недоработками дизайна протокола TLS, а именно методом организации согласования параметров в установленных соединениях, и не зависит от конкретных реализаций протокола.

Для OpenSSL уже выпущен временный патч, суть которого сводится к полному отключению операции согласования (negotiation).

Так как без изменения протокола решить проблему невозможно, в экстренном порядке ведущими производителями и стандартизирующими организациями отрасли был сформирован проект Project Mogul, задачей которого является разработка и принятие необходимых расширений стандарта TLS.

Сценарий атаки выглядит примерно так:

1. Атакующий вклинивается между клиентом и сервером, устанавливает HTTPS соединение с сервером.

2. Соединение со стороны клиента временно замораживается на незавершенной стадии.

3. Далее серверу отправляется запрос в защищенную область, сервер инициирует полностью новое соединение и запрашивает клиентский сертификат.

4. Атакующий перенаправляет не данной стадии все пакеты между клиентом и сервером в неизменном виде.

5. После завершения фазы проверки сертификата злоумышленник формирует свой HTTP запрос к защищенной области и выполняет его от имени клиента.