id: Гость   вход   регистрация
текущее время 22:40 28/03/2024
Владелец: SATtva (создано 20/09/2011 17:58), редакция от 20/09/2011 17:58 (автор: SATtva) Печать
Категории: криптография, криптоанализ, инфобезопасность, защита сети, протоколы, стандарты, атаки, ssl
http://www.pgpru.com/Новости/2011/ПредставленПервыйУспешныйСпособАтакиНаSSLTLS
создать
просмотр
редакции
ссылки

20.09 // Представлен первый успешный способ атаки на SSL/TLS


Тхай Дыонг (Thai Duong) и Джулиано Риццо (Juliano Rizzo), известные исследователи компьютерной безопасности, обладатели премии Pwnie Awards 2011 за разработку метода компрометации приложений ASP.NET, намерены на конференции Ekoparty 7 раскрыть завесу над новым способом атаки на SSL/TLS. Для осуществления атаки подготовлен инструментарий, развиваемый под именем BEAST (Browser Exploit Against SSL/TLS) и позволяющий организовать перехват передаваемого в рамках зашифрованного соединения Cookie с параметрами аутентификации пользовательской сессии. В частности, исследователи продемонстрировали успешный перехват защищенной сессии для сервиса PayPal и утверждают, что метод применим и для любых других сайтов.


Судя по всему представленная работа является первым удачным методом атаки против TLS 1.0 и SSL 3.0, позволяющим расшифровать на лету запросы, отправляемые через HTTPS. Например, метод позволяет получить доступ к важной конфиденциальной информации, фигурирующей при работе с такими сервисами, как online-банкинг, службы электронной коммерции и платежные системы. Проблему усугубляет то, что она основывается на принципиальных недостатках протоколов TLS 1.0 и SSL 3.0, устранить которые можно только значительно переработав протокол. Закрытые обсуждения возможных путей решения проблемы с разработчиками браузеров и поставщиками SSL-продуктов проводятся начиная с мая, но они пока привели только к неутешительному выводу – все предложенные методы решения проблемы приводили к нарушению совместимости протокола с некоторыми SSL-приложениями.


Атака проводится многоэтапно. Для успешного осуществления атаки требуется запуск JavaScript-кода в браузере клиента, который должен быть запущен после установки SSL-соединения браузера с сайтом, данные которого требуется перехватить (SSL-соединение остается открытым длительное время, поэтому у атакующего есть запас времени). JavaScript-код не требуется запускать в контексте атакуемого сайта, его достаточно открыть в новой вкладке, например, путем встраивания через iframe в какой-нибудь сторонний сайт, открытие которого можно стимулировать методами социальной инженерии. JavaScript-код используется для отправки на сайт с которым работает жертва фиктивных запросов с изначально известными контрольными метками, которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL, работающего на базе алгоритма AES.


После того как вспомогательный JavaScript-код запущен, на одном из промежуточных шлюзов осуществляется запуск сниффера (например, осуществив атаку в подконтрольной WiFi-сети). Задача сниффера сводится к выявлению связанных с определенным сайтом TLS-соединений, их перехват и расшифровка начальной части HTTPS-запроса, в которой содержится HTTPS Cookie (запросы вспомогательного скрипта отправляются через ранее установленный SSL-канал, при этом браузер добавит к этим запросам все ранее установленные Cookie). После того, как удалось воссоздать идентифицирующую HTTPS Cookie, осуществляется классическая атака, позволяющая вклиниться в активную сессию жертвы.


Расшифровка основана на методе угадывания содержимого отдельных блоков, часть которых содержит данные отправляемые подставным JavaScript-кодом. Если в процессе подбора предположение о содержимом блока оказывается верным, блочный шифр получит такие же входные данные для нового блока, как и для старого блока, произведя идентичный зашифрованный текст. На расшифровку байт за байтом всего содержимого идентификационной HTTPS Cookie, которая имеет размер 1000-2000 байт, для таких сайтов как PayPal тратится 5-10 минут. Для сайтов использующих вместо TLS 1.x и SSL 3.0 устаревший SSL 2.0 скорость подбора может быть кардинально увеличена.


Атака с использованием браузера является одним из возможных вариантов и может быть переработана для нападения на другие продукты, использующие TLS и SSL, такие как VPN или клиенты для мгновенного обмена сообщениями. По мнению исследователей, производители web-браузеров в скором времени добавят в свои продукты обходной путь блокирования подобных атак, но так как суть проблемы кроется в недоработке архитектуры TLS и SSL, полноценным решением проблемы может быть только переход на новый протокол. Например, проблеме не подвержены уже доступные протоколы TLS 1.1 или TLS 1.2, степень внедрения которых в браузерах и на серверах находится почти на нулевом уровне: из полутора миллионов проверенных серверов 600 тыс. поддерживают TLS 1.0, 600 тыс. SSL 3.0, 300 тыс. устаревший SSL 2.0, 838 – TLS 1.1 и только 11 TLS 1.2.


Источник: http://www.opennet.ru/opennews/art.shtml?num=31797


 
На страницу: 1, 2 След.
Комментарии [скрыть комментарии/форму]
— unknown (20/09/2011 20:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
При входе на https-сайт не должно быть смешанного контента (заблокированы http-баннеры), не должно быть открыто других вкладок и, как всегда (если сайт это позволяет), лучше не включать javascript?
— SATtva (20/09/2011 21:27)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Да, https-сайты необходимо открывать со специально выделенной машины с мандатной системой прав доступа и, по возможности, изолированной от интернета.
— Гость (20/09/2011 22:10)   <#>
не должно быть открыто других вкладок
А если все вкладки относятся к одному и тому же сайту — это меняет дело? Например, разные wiki-документы pgpru.com.
— Гость (21/09/2011 11:04)   <#>
Нужен новый стандарт на протокол защищенной связи. Он в первую очередь должен быть предельно прост и свободен от legacy костылей, которыми переполнен SSL. Код референсной реализации должен занимать до 1000 строк, чтобы любой специалист покопавшись в них полдня, мог убедится что уязвимостей там нет, ибо негде. Сейчас же в OpenSSL без бутылки не разберешся, все тонкости протокола не растолкуешь на пальцах, не удивительно что в нем раз за разом находят дыры.
— Гость (21/09/2011 11:46)   <#>
600 тыс. поддерживают TLS 1.0, 600 тыс. SSL 3.0

SSL 3.0 =?= TLS 1.0
— SATtva (21/09/2011 11:49)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Нет. http://en.wikipedia.org/wiki/S.....tory_and_development
— Гость (21/09/2011 11:55)   <#>
Раскурите плиз.ку
— Гость (21/09/2011 13:34)   <#>
изолированной от интернета.

Во-во..
А еще копьютер вообще не должен быть подключен к интернету, и находиться в подвале.
А на голове должна быть шапка с фольги(!).
— Гость (22/09/2011 11:25)   <#>
Поясните, пожалуйста, а что такое "HTTPS Cookie"? Это то же, что и http cookie, или нечто, связанное с шифрованием и относящееся к SSL?
— SATtva (22/09/2011 11:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Это обычный HTTP cookie с флагом "secure", т.е. передаётся только по защищённому каналу.
— sentaus (22/09/2011 12:21)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
А вот не совсем понял, эта атака – развитие какой-то ранее известной теоретической атаки, перешедшей сейчастаким образом в практическую плоскость? TLS 1.1 и TLS 1.2 не подвержены атаке, в них она была учтена?
— Гость (22/09/2011 13:04)   <#>
Это обычный HTTP cookie с флагом "secure"

Спасибо!

развитие какой-то ранее известной теоретической атаки

Может быть, это новое применение прошлой атаки этих исследователей (что-то про дешифрование данных ASP.Net, основанное на дополнении блока шифртекста и разных кодах ошибок в ответах сервера), потому что в TLS >= 1.1 убраны различные коды ошибок
— Гость (22/09/2011 16:44)   <#>
Разъясните пожалуйста детальней механизм уязвимости. Насколько я понял, js генерит известный открытый текст и по его зашифрованному виду каким-то образом выполняется дешифрация уже неизвестного открытого теста. Это уязвимость протокола ssl или алгоритма шифрования aes? И потом, если запущен скрипт, то разве он не может получить сессионный ключ из оперативной памяти и передать его по сети. Тогда и сниффер не нужен.

Интересуют ещё два важных вопроса.

1 Каким образом можно использовать этот способ для вскрытия
vpn. Полагаю, запуском программы делающей тоже что и этот скрипт, например внедрив её в популярное приложение. Но тогда она и сама может украсть ключ из памяти и передать по сети без использования сниффера.

2. Следует ли из этого что vpn через ssh безопасней чем vpn через ssl.

При входе на https-сайт не должно быть смешанного контента (заблокированы http-баннеры)

Какой смысл https-сайту внедрять данный скрипт если он и так имеет открытый текст. Или вы имеете в виду что такой сайт может случайно содержать сторонний контент, который содержит этот скрипт?
— Гость (22/09/2011 18:25)   <#>
Это уязвимость протокола ssl или алгоритма шифрования aes?
Ну уж точно не второе.

если запущен скрипт, то разве он не может получить сессионный ключ из оперативной памяти и передать его по сети
JS с прямым доступом к оперативной памяти? Да нихрена ж себе!

Следует ли из этого что vpn через ssh безопасней чем vpn через ssl.
Оно не следует, а попросту всегда так было. SSH'у уделяется слишком повышенное внимание, в отличие от других протоколов.

такой сайт может случайно содержать сторонний контент
Не понял, что вы имеете в виду, но https сайты часто имеют смешанный контент, чтобы крутить баннеры на странице. Ссылки на баннеры — ссылки на сторонние сайты, со своими наворотами и динамическим обновлением. Они вообще плохо дружат с https.
— Гость (22/09/2011 19:14)   <#>
Вы имеете в виду что js не имеет инструкций для работы с памятью? Предполагаю что js-скрипт может доставить на клиентскую машину удалённую программу и запустить. Я не системный программист, поэтому не представляю себе сложность реализации такой программы, но принципиально это возможно.

ssh вроде бы использует библиотеку openssl, поэтому неочевидна большая защищённость vpn-ssh по сравнению с vpn-ssl, без понимания деталей обсуждаемой уязвимости.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3