Как обойти HTTPS с помощью proxy.

Сегодня мы раскажем вам о относительно старой атаке – возможности «Обхода» НТТРS в браузере. Если точнее, возможности внедрить свой JavaScript-кoд в любой сайт, защищенный НТТРS, при условии, что злоумышленник может «вставить» свой прокси в настройках браузера жертвы. Да, эта атака не работает на современных топовых браузерах. Но, во-первых, еще шесть лет назад ей были подвержены все они, а во-вторых, она служит отличным примером основных проблем с НТТРS (SSL). Да и с технологической точки зрения интересна.

Давай представим себе ситуацию, что атакующий может провести на пользователя man-in-the-middle атаку. Причем не просто « находиться » гдето посередине между сервером и пользователем, а быть прокси-сервером для подключения между ними. То есть в настройках браузера/ОС пользователя должен быть указан прокси атакующего. Хотя это может показаться невыполнимым, но на практике есть ряд ситуаций , когда это происходит. Вот самые типовые.

Корпоративная сеть, все пользователи ходят через корпоративный прокси . Мы производим DNS- или АRР-спуфинг и подменяем официальный прокси на свой. Также есть автоматическое включение прокси с использованием технологии WPAD (Web Proxy Autodiscovery Protocol), которая по умолчанию активирована в Windows-cиcтeмax ( «Автоматическое определение настроек» в IE).

Далее. Почему нам так важно именно стать прокси-сервером? Дело заключается в уникальности работы через них. Если при обычном подключении по SSL данные идут напрямую и, не считая первых SSL-пакетов, там все зашифровано, то с прокси добавляется еще один шаг, который не зашифрован.

Итак, по RFC, для работы по НТТРS через прокси был придуман дополнительный метод – CONNECТ. Когда пользователь пытается подключиться по НТТРS к серверу, его браузер сначала посылает запрос плейн-текстом на прокси такого вида:

1 2	CONNECT defcon-russia:443 НТТР/1.1 Host: defcon-russia

Прокси же пытается подключиться по указанному IP и порту и, если все хорошо, отвечает:

1	НТТР/1.0 200 Connection estabished

При этом он не обрывает подключение (ТСР) , а начинает просто пересылать весь трафик от пользователя на сервер . То есть отсюда и далее идет обычное подключение по SSL. Теория, я думаю, ясна. Перейдем к самой уязвимости, которая была в браузерах.

Подключение по HTTPS через proxy

Проблема была в том, что браузер обрабатывал ответ прокси (например, ошибку при подключении) в контексте домена сайта , к которому он подключался. И что еще круче – JavaScript тоже работал! Прокси-серверу ничего не стоило вернуть браузеру ошибку со своим JS и из него получить те же куки, например.

Атака HTTPS с proxy

Хотелось бы подчеркнуть здесь, что фактически ничто не нарушало само НТТРS-соединение. Оно как было зашифровано и нетронуто , так и осталось. Проблема была уровнями выше – в same origin policy (SOP) браузера, по которому все было вполне корректно : вне зависимости от того , откуда пришли данные, если origin тот же, значит, и доступ есть. Причем разработчики разрешали вывод ошибок от proxy из хороших побуждений – чтобы у пользователя была возможность видеть кастомную информацию о причинах ошибки подключения.