Pull to refresh

Comments 22

Даже несмотря на то, что TLS 1.1 уже пять лет, его используют единицы!
Дык в OpenSSL поддержки нет, вот и не используют.
В снапшотах версии openssl-1.0.1-stable поддержка TLS1.1 и 1.2 уже имеется.
В репах повсеместно 1.0.0 пока что. Будет доступна 1.0.1, начнут и серваки держать.
Версии протоколов SSL и TLS перепутаны в некоторых местах, надеюсь это только здесь, на бумаге все норм.
> На практике, однако, обычно используется блочные шифры, и описываемая нами атака применима именно для них.

На большинстве сайтов с https, которыми я регулярно пользуюсь:

Для аутентификации сообщений используется AES_256_CBC c SHA1, для обмена ключами используется DHE_RSA.
Который хоть и является блочным, не должен быть подвержен уязвимости если я правильно понимаю её характер.

> у атакующего должна быть возможность внедрить агент в браузер жертвы

Почему бы ему тогда не стырить куку через этот агент?
Я так понял, что агент может быть с другого сайта. А прочитать чужую куку нельзя.
Но остается небольшой нюанс — для того, чтобы скрипт или апплет могли отправлять данные по установленному жертвой соединению, необходимо обойти еще и ограничения SOP (same-origin policy, правило ограничения домена). Это важная концепция безопасности для некоторых языков программирования на стороне клиента, таких как JavaScript. Политика разрешает сценариям, находящимся на страницах одного сайта, доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц на разных сайтах. Проще говоря, запущенный на одной странице клиент не сможет делать запросы к нужному сайту (скажем, Paypal.com). Чтобы обойти политику SOP, авторы нашли в виртуальной машине Java 0day-уязвимость и написали для нее работающий сплоит. Только не думай, что это позволяет читать существующие кукисы. Если бы это было так, тогда зачем нужен был весь этот сыр-бор с зашифрованным трафиком? Используя сплоит для обхода SOP, можно отправлять запросы и читать ответы сервера (в том числе ответы с новыми кукисами), но нельзя считывать существующие кукисы, которые сохранены в браузере.

Вообще через Java-аплеты и без всяких уязвимостей много лишнего делать можно. Если нашли одну уязвимость на установку кук, могли бы найти и другую на чтение… :-)
Скажите, если в браузере уже есть агент злоумышленника, что ему мешает просто скопировать куки?
Подразумевается, что агент внедряется не с атакуемого сайта и что у него нет доступа к чужим кукисам.
Интересно что Paypal принимает регистрацию с мыльником на mailinator. Спасибо за статью, respect to Juliano and Thai.
Порадовало, что для того, чтобы обойти ограничения same-origin policy исследователи заодно нашли уязвимость в java машине и использовали её. Действительно, если уж находить уязвимости, то пачкой. Молодцы исследователи.
«— …и специального агента, написанного на JavaScript и Java, который должен быть подгружен в браузере жертвы…»

Дальше не читал, сделайте это первой строкой текста, а то, дойдя до того места, я почти поверил.
(ладно, читал я дальше, читал)
С таким же успехом можно найти еще уязвимость в java или где-нибудь еще с запуском кода произвольного на жертве и скопировать что надо, так хоть с шифрованием возиться не надо.
в одно вкладке у вас открыт вконтактик с iframe приложением, в другой вы открыли paypal чтобы купить подарок девушке, с которой общаетесь в первой вкладке… нэ?
lashtal все правильно сказал. Внедренный левый яваскрипт тем более с явой — уже пропущенная уязвимость. Открыв «вконтактик с iframe приложением» Вы фактически доверили все куки (читай акк) от вконтактика создателям iframe приложения. А данная уязвимость просто расширяет зону доверия.

Чтоб защититься от данной уязвимости совсем не обязательно ждать openssl 1.0.1. Достаточно:
1) FF+noscript+request policy
2) Юзайте платежные сайты (я.деньги, вебмани, пейпал и т.п.) в отдельном профиле броузера\отдельном броузере.
3) Не юзайте вконтактикНа левые сайты лазайте из-под другого отдельного профиля броузера. Т.е.: один профиль основной, один — «платежный», один — «левак».

Да-да, это сложно для рядового пользователя. Что ж, каждый сам себе злобный буратино. Но не стоит преувеличивать масштабы уязвимости.
Я конечно опоздал на два года :)
Но смысл был в том, что вы доверили iframe не только куки контакта (это как раз понятно), но и возможность отправлять любую фигню в PayPal (правда, из-за проблемы с SOP).
Это все еще выглядит невероятным стечением обстоятельств, но тем не менее уже реализуется хотя бы в лаборатории.
Не знаю как у вас, у меня давно во всех браузерах запрещена java. Я не знаю ни одного сайта, где она нужна, но зато знаю, что в ней куча дыр. К сожалению, аморальные маркетологи из сан/оракл впаривают свое решето всем пользователям без спроса при установке явы или явосодержащих программ. Вот кто они такие после этого?

UFO just landed and posted this here
Например интернет-банки подписывают ЭЦП документы из браузера с помощью джавы.
Не так. Клиент-банки многих банков реализованы как java-апплеты. Ключи хранятся на е-токенах. Но популярный метод взлома — это формирование поручений в рамках клиента как клиент, прятать их от клиента и давать возможным проводить банку. Вопрос в том, что встроиться в систему.
А иначе практически никак. Служба кртиптографии должна общаться с токеном и браузером. На стороне браузера это либо Java Applet, который вызывает методы этой службы и пользуется ЭЦП (который должен бы быть на usb-токене), либо как-то так же с ActiveX. Браузер передаёт документ на подпись, подписанный документ отправляется на сервер.
Можно было бы рассмотреть вариант с плагином для браузера, но там потенционально не меньше дыр.
А у меня мало того, что запрещена, так если даже разрешить — всё равно не работает ни на одном компе. IE8, Firefox 3.6, Firefox 5, Opera 11, Epiphany 3.
Sign up to leave a comment.