Выполнение cross-site websocket hijaking

Вернемся обратно к вебу, точнее к его будущему. В НТМL5 появилось множество технологий, в том числе и такая технология, как веб-сокеты.

Веб-сокеты это такой протокол, который позволяет установить полнодуплексное соединение между браузером и сервером по протоколу ТСР. То есть вместо обычного безсесионного НТТP с его «запрос-ответ» мы имеем обычное ТСP-подключение, где любая из сторон может слать данные, и это все в рамках одной ТСР-сессии.

Несмотря на невысокую распространенность применения веб-сокетов, все современные браузеры их поддерживают (даже ИЕ).

Далее немного фактов, Веб-сокеты работают на тех же портах, что и сам веб-сервер, HTTPS поддерживает. Они обозначаются схемой «ws://» и «wss://» для защищенного подключения. Данные внутри веб-сокета (после установки подключения) не шифруются, a только маскируются.

Для того чтобы установить подключение, веб-сервер посылает GEТ-запрос на веб-сервер для инициализации соединения. Основное отличие этого запроса от обычного дополнительные заголовки (заголовки после HOST):

GET / НТТР/1.1
Host: victim.ru
Origin: http://evil.org
sес-wеЬsосkеt-кеу G54ЗzsUvsЕ7ЕWрzорР2НRw==
sec-websocket -Version: 13
Connection: Upgrade
Upgrade: websocket

Последние два указывают браузеру на переход на веб-сокет. Далее версия протокола и случайное значение, для защиты от «поддельных запросов» (хотя не очень понятно, какая там атака может быть). Очень важный заголовок Origin, указывает, c какого сайта было инициализировано подключение.
Ответ от сервера будет следующим:

HTTP/1.1. 101 Web socket Protocol Handshake
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-typel х-websocket -extensions) x-websocket -version, x-websocket -protocol
Access-Control-Allow-Origin: http:/victim.ru
Sec-WеbsocketАссерt: 5Lw1Lqhх7Ркхbbt9+Rp+bVзх4)g=? 
Upgrade: websocket

Последние два заголовка аналогичны. далее три заголовка в стиле CORN, которые указывают возможность отсьлки кредам дополнительных заголовков, a также с какого домена это разрешено. Ho фактически эта троица ни на что не влияет, потому как сразу после получения ответа создается веб-сокет (To есть обычное ТCР-подключение), где уже передается текст или данные. Формат пакетов вполне минимален: несколько бит для фрагментации, маски и размера данных в пакете a далее данные.

И самый важный момент веб-сокет изначально спроектирован для межсайтового взаимодействия, a потому SOP фактически на него не действует. Еще, возможно, интересен вопрос a том, как мы можем узнать (с точки зрения пентестера), поддерживаются ли веб-сокеты в данном конкретном приложении.

Ho были попробованы различные методы, и единственный выявленный вариант протыкать указанным выше запросом все пути на сайте (так как, например, на запрос к корню, сервер вернет нам 404, a на какой-нибудь web/char разрешение на коннект).

О’кей, теперь перейдем к самой атаке на сокеты c таким забавным названием, как Cross-Site Websocket Hijacking. Она на самом  деле проста. Суть ее в том, что мы c нашего сайта (origin’a) можем создать веб-сокеты с атакуемым веб-приложением от имени юзера (зашедшего на наш сайт).

Тут ведь в чем дело: во-первых, инициировать создание веб-сокета к атакуемому веб-приложению мы можем c любого сайта. A во-вторых, при инициализирующем запросе автоматически подставятся куки (или НТТР-аутентификация), так как это обычный GЕТ-запрос, только с дополнительными заголовками. Фактически получается, что это обычная CSRF-атака, только на выходе мы имеем веб-сокет, с помощью которого можем общаться с веб-приложением от имени юзера.

Теперь немного о тонкостях. Kaк ты видел в ответе от сервера, там есть различные заголовки. Например, Access-Control-Allow-Origin, который должен был бы защищать юзера: если eго браузер получает в этом поле другой сайт, чем TOT, с которого мы инициировали веб-сокет, то браузер должен веб-сокет не устанавливать.

[ad name=»Responbl»]

Ho увы, ни на что заголовок не влияет. Получается, что вся ответственность за защиту лежит на самом веб-приложении. Как вариант, оно должно проверять Origin из клиентского запроса и, если он похож на нужный, только тогда разрешать подключение. Тут, правда, есть еще тонкость, что веб-сокеты можно использовать и без браузера, c обычных приложений, но тогда заголовка Origin уже не будет.

Возможно, у тебя возник вопрос: a что нам СSWSН может дать? С одной стороны, ничего универсального. Это не xss, где мы c JS можем творить чудеса. Несмотря на название, лучше воспринимать это как что-то похожее на CSRF.
C другой стороны, если функционал приложения через веб-сокеты велик, то, учитывая возможность и слать запросы, и получать ответы, мы можем сделать очень многое.

И немного о практике. К сожалению, всеми любимый Burp (1.6) умеет лишь снифать передаваемые данные, a отправлять произвольные запросы в веб-сокет не умеет. Зато это умеют делать ZAP и гораздо менее известный продукт IronWASP (www.ironwаsр.org). Для тестирования самой атаки можно воспользоваться и онлайн-сервисом goo.gl/vMiOsu.
Спасибо за внимание и успешных познаний нового!