+66 голосов |
Несколько удивился, не увидев этого в новостях КО. На прошлой неделе была презентована атака, по сути, позволяющая взламывать HTTPS-сессии (естественно, с ограничениями, куда без них). В качестве примера приводится расшифровка cookies и последующий «угон» сессии PayPal за 10 минут! Конец безопасному е-мейлу, онлайн-банкингу и шоппингу?! Паниковать или нет?! Будем разбираться.
Атака построена довольно хитро. Атакующий умудряется вбрасывать пакеты в зашифрованный канал, при этом перехватывая шифрованные пакеты. В результате умелого использования уязвимостей блочного шифрования SSL3.0/TLS1.0 атакующий расшифровывает необходимые ему данные. Потом – делает что хочет. Особенность этой атаки в том, что база для криптоанализа (длинные сеансы связи или интенсивный обмен пакетами) здесь требуется значительно меньшая (за счет умелого вброса правильно сгенерированных пакетов) – утверждается, что сессию можно вскрыть за 10-30 минут.
Для начала несколько интересных и волнительных фактов:
- Обычный пользователь проводит за онлайн-шоппингом/банкингом/платежами/почтой более 10-30 минут за сессию, так что угроза вполне реальна (достаточная база для криптоанализа).
- Атака производится на протоколы SSL 3.0 и TLS 1.0, используя ряд уязвимостей, известных начиная с 2006 года (5 с гаком лет!)
- Многие из этих уязвимостей в SSL3/TLS1.0 никогда не были закрыты
- Потому и SSL и TLS 1.0 считаются устаревшими, TLS 1.1 (не подверженный этой уязвимости) был выпущен в 2006 году, TLS 1.2 – в 2008 и обновлен в 2011.
- Так что, получается, нет проблемы? Проблема есть!
- Большинство браузеров не поддерживают TLS1.1+ (пока что – только IE8+/Win7 и Opera10+)
- А те, что поддерживают, не включают по умолчанию. А почему?
- А потому, что большинство веб-серверов не поддерживают TLS1.1+ (или он не включен по умолчанию, а админ не почесался).
- Кроме того, даже SSL3.0/TLS1.0 не подвержены этой атаке, при использовании потоковых шифров (RC4, тоже не самый надежный вариант, однако).
- Но многие сайты не поддерживают и этот механизм! Плюс, так как RC4 слабее, скажем, AES, по умолчанию будет выбран блочный режим с AES, оказавшийся уязвимым (блочный режим, не AES).
В общем, получилась ситуация «верхи не могут, низы не хотят»: если бы проблема было только на стороне клиента – все бы решилось быстрым обновлением браузеров. Но тут, похоже, придется обновить «весь Интернет». Вот выдержка из новости с красноречивой статистикой:
«Как обнаружили исследователи из компании Opera, только 0.25% сайтов поддерживают TLS 1.1, TLS 1.2 поддерживают 0.02%. Несмотря на то, что спецификации TLS 1.1/1.2 были разработаны достаточно давно, поддержка этих протоколов в некоторых популярных браузерах всё ещё не реализована. Это создаёт проблему для владельцев сайтов, которые хотели бы обновиться, но из-за боязни потерять клиентов делать этого не хотят»
Внизу поста есть секция с подробностями для любопытных, а пока разработчики браузеров, веб-серверов, библиотек SSL/TLS и прочие вебмастеры будут искать способ спасения мира, нам пользователям, необходимо решить важнейший вопрос:
К счастью, особого повода для паники нет. Атака опирается следующие факторы:
- Возможность перехвата трафика;
- Использование блочных шифров (CBC) в SSL3.0/TLS1.0;
- Достаточная база для криптоанализа (длинные сеансы связи или интенсивный обмен пакетами);
- Возможность вброса данных.
С первым фактором сделать ничего нельзя. Как только мы отправили пакет, мы его уже не контролируем. А вот с остальными – можно:
Администраторы веб-сайтов могут оперативно включить поддержку RC4 (или выставить ее более приоритетной, чем всякие блочные режимы). Google, как выяснилось, уже давно использует этот метод, так что GMail, GDocs, G+ и иже с ними – в относительной безопасности.
Аналогично, пользователи могут открутить поддержку всех блочных Cipher Suites (*_CBC_*) в браузере/ОС (и заодно поддержку SSL3/TLS1.0, если браузер позволяет). Правда, при этом некоторые сайты могут отказаться работать, но тут уже пользователю решать: или потенциальный риск, или потерпеть без данного ресурса.
Можно ограничить длительность сессии. С той же почтой можно работать не через браузер, а через почтовый клиент, а там TLS сессии будут покороче. На худой конец – периодически делать logout J.
И самое интересное – возможность вброса данных. Здесь используется всеми любимый XSS, но в новой форме. Как обычно, плагин NoScript для Firefox выручает.
Стараясь сохранить баланс между количеством подробностей, интересностью и краткостью изложения, завершу заметку здесь. Сухой остаток:
- Проблема есть, она реальна;
- Для реализации атаки не понадобилось открывать ни одной новой уязвимости – все было известно много лет;
- Неизвестно, сколько лет этот баг УЖЕ эксплуатировали;
- С проблемой можно бороться, если знать как.
В ближайшее время ожидаю всплеска постапокалиптических новостей на тему «конец Интернета», потом волны апгрейдов и глюков на веб-сайтах, потом все вернется на круги своя.
Ситуация на данный момент:
- Браузеры:
- Серверы:
- Поддерживают TLS1.1+: IIS7+, mod_gnutls для Apache;
- OpenSSL (наиболее популярный) поддерживает TLS 1.1 только в бетах;
- NSS (Chrome, Firefox и серверные реализации для Apache, Java и т.д.) поддерживает TLS1.1+ очень ограниченно;
- Все остальное – не поддерживает.
Сравнительно свежий документ, который расписывает, какие браузеры и веб-серверы что поддерживают (заодно приводит краткий экскурс в историю SSL/TLS).
Две подробных статьи с анализом:
- http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
- http://www.imperialviolet.org/2011/09/23/chromeandbeast.html
Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365
+66 голосов |