LINUX.ORG.RU

FREAK — ещё одна атака на TLS

 , , , ,


3

3

Исследователи из INRIA, IMDEA и Microsoft обнаружили новый тип атаки на SSL/TLS, названный FREAK (Factoring attack on RSA-EXPORT Keys). Злоумышленник может вклиниться в соединение и инициировать ослабление шифрования между клиентом и сервером, что повышает его шансы расшифровать трафик.

Ноги уязвимости (идентификатор CVE-2015-0204) растут из середины XX века, когда в США были приняты ограничения экспорта стойких шифров за пределы страны (длина ключа для симметричного шифрования не могла превышать 56 бит, а для асимметричного - 512 бит). Большинство ограничений были сняты к 2000 году, но некоторые программные продукты до сих пор поддерживают специальный набор шифров RSA_EXPORT, в которых применяется 512-битный ключ RSA. Ключи такой длины давно считаются недостаточно стойкими.

Из-за недостаточной проверки TLS Handshake, злоумышленник может инициировать переключение на RSA_EXPORT (даже если клиент не заявлял о его поддержке), после чего остаётся лишь подобрать ключ RSA-512. На мощностях Amazon EC2 это можно сделать за 7-8 часов. Ключ будет действителен до перезапуска веб-сервера.

Уязвимости подвержены, как клиентские, так и серверные системы, а также разнообразное ПО. В их числе:

  • OpenSSL (уязвимость исправлена в 0.9.8zd, 1.0.0p и 1.0.1k).
  • устаревшие версии Chrome на Mac OS и Android (выпущено экстренное обновление).
  • Internet Explorer на всех клиентских и серверных версиях Windows (доступен временный костыль).
  • Dolphin, Opera и встроенный браузер на Android.
  • Safari и Opera на OS X.
  • Safari и Dolphin на iOS.
  • Opera на Mac OS и Linux.
  • Blackberry Browser.

Firefox проблеме не подвержен, поскольку не использует OpenSSL.

С серверной стороны RSA_EXPORT поддерживается на 36.7% от общего числа сайтов и на 9.7% из миллиона крупнейших сайтов. Создан сервис для проверки своего сайта на наличие уязвимости. Проблема несколько смягчается тем, что многие из вышеуказанных сайтов используют уникальные ключи для каждого клиента.

Источники и подробности:

anonymous

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 4)

Бздуны сообщают, что в их LibreSSL такой уязвимости нет. Соответствующий легаси-код они оттуда давно выкинули.

anonymous
()

Firefox проблеме не подвержен, поскольку не использует OpenSSL.

ну хоть на что-то годное эти сотни мегабайт памяти идут

unt1tled ★★★★
()

А я свой браузер написал, он тоже неуязвим.

anonymous
()

А ведь кто-то без проблем со свистом использовал эту дыру, подумать только, продолжительное время...

Почему нельзя захардкодить отсутствие поддержки устаревших недостаточно стойких режимов работы библиотеки, пусть даже отвалится что-то устаревшее клиентское?

I-Love-Microsoft ★★★★★
()

Firefox проблеме не подвержен, поскольку не использует OpenSSL.

За что и люблю фоксика :)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Почему нельзя захардкодить отсутствие поддержки устаревших недостаточно стойких режимов работы библиотеки, пусть даже отвалится что-то устаревшее клиентское?

Потому что работоспособность ценят, как правило, гораздо выше безопасности. Подвергнешься ты атаке или нет - вопрос вероятности, будет ущерб большим или едва заметным - тоже хз. А за неработающий сервис точно уволят и наймут того, кто всё-таки починит, хоть и опасным способом. Никого при этом не волнует, что у клиента что-то там устарело и что это небезопасно.

selivan ★★★
()
Последнее исправление: selivan (всего исправлений: 2)
Ответ на: комментарий от selivan

Кстати, отсутствие работоспособности — тоже проблема безопасности, вида «отказ в обслуживании» (по крайней мере, так считает Э.Танненбаум). Даже, если служба была вручную выключена перестраховавшимся администратором.

Infra_HDC ★★★★★
()
Ответ на: комментарий от anonymous

Да ладно, у них еще 100500 дыр в запасе.

anonymous
()

Интересно, если (когда) они найдут ещё один баг, то пока название ему не придумают, информацию о нём не опубликуют? Это ведь так важно, давать уязвимостям имена...

xaizek ★★★★★
()

Вот для этого и существует FIPS mode, чтобы всякая legacy non-secure нечисть случайно не заработала.

slyjoeh ★★★
()
Ответ на: комментарий от HyperCOGENT

Нет, совсем нет. Большинство современных веб-серверов используют динамические ключи, т.е. работают со временными RSA 512-битовыми ключами так же, как с EDH: на каждое подключение новый ключ. Все веб-серверы постарше генерируют ключ при запуске, т.е. после перезагрузки будет уже другой ключ. Плюс, нужно не забывать, что это работает только если на сервере поддерживается EXPORT-шифрование.

ValdikSS ★★★★★
()
Ответ на: комментарий от Infra_HDC

Ну это всё красивая теория, а на практике менеджмент видит два состояния сервиса: «работает и приносит деньги»/«не работает и не приносит деньги». А вообще звучит логично

selivan ★★★
()

А чё это так мелкософт сильно заинтересовалось SSL`ем(уже второй пост с SSL и мелкомягкими)? Или среди ихних индусов нашелся чувак который умеет думать?
А - дошло, АНБ не нравится проект и они решили попросить помощи у дизанеростроителей....

drfaust ★★★★★
()
Ответ на: комментарий от selivan

Работоспособность какого софта нарушится при отключении EXPORT шифров?

Legioner ★★★★★
()

Чем эта атака отличается от любой другой атаки, направленной на понижение стойкости шифра? Завтра найдут какой-нибудь другой слабый шифр, найдут 2% серверов из топ10000, которые не отключили этот шифр и назовут атаку BREAK?

TLS на редкость кривая штука, на самом деле. Какой смысл добавлять в TLS более стойкие шифры, если активный MITM всегда может заставить стороны общаться по самому слабому шифру? Выкинуть давно пора этот TLS вместе с кучкой дармоедов и придумать что-нибудь получше.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Уязвимость заключается как раз в возможности понижения шифра. Обычно, такое сделать нельзя, т.к. ciphersuites и от сервера, и от клиента, подписаны.

ValdikSS ★★★★★
()
Ответ на: комментарий от ValdikSS

Уязвимость заключается как раз в возможности понижения шифра. Обычно, такое сделать нельзя, т.к. ciphersuites и от сервера, и от клиента, подписаны.

Обмен шифрами производится до начала шифрованной сессии, как они могут быть подписаны? Сервер же не знает ничего про клиента. MITM перехватит трафик и от имени клиента скажет, я умею только <самый слабый шифр, поддерживаемый сервером>. Дальнейшая сессия будет зашифрована им.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Не совсем. Перед самым началом TLS-сессии, и клиент, и сервер посылают сообщение Finish, в котором содержится хеш от всех переданных ранее сообщений, включая ClientHello и ServerHello.

ValdikSS ★★★★★
()

Heartbleed вреден, он всех затмил.

t184256 ★★★★★
()
Ответ на: комментарий от anonymous

Правда, я пишу не бред, попросту эта уязвимость охватывает тоже много чего.

HyperCOGENT
()

Я так понимаю что клиенты на JSSE тоже не подвержены этой атаке?

ricie
()
Ответ на: комментарий от drfaust

А - дошло, АНБ не нравится проект и они решили попросить помощи у дизанеростроителей....

Сколько же идиотов на ЛОРе...

anonymous
()

и Microsoft

Думал там одни манагеры

splinter ★★★★★
()

не до конца понятно, риску подвержена новая сессия или уже существующая?
походу еще одну лазейку у спец служб отобрали.

mika77
()
Ответ на: комментарий от mika77

походу еще одну лазейку у спец служб отобрали.

скорее спецслужбам надоело поддерживать старую и не очень эффективную дыру

WARNING ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.