|
Несмотря на то, что все больше трафика подвергается
исследованию и ограничению, администраторы в основном
забывают про главный порт в их сети - 80-ый.
Пользователи, как и админы, постоянно бороздят просторы
Инета, как в рабочих целях так и в не очень. Так или
иначе, но большинству компаний нужно присутствие в Сети,
а это требует своего веб-сервера, размещенного у
провайдера или внутри собственной сети. С каждым новы
червем, багом, уязвимостью, найденной в IIS или Apache,
администраторы стараются все больше и больше закрыть
свой сервер от любопытных взглядов, внедряют IDS
(Intrusion Detection Systems) и IPS (Intrusion
Prevention Systems). Однако все это не 100% защита и ее
всегда можно обойти, о чем и будет рассказано в этой
статье.
Зачем нам HTTP туннелинг?
Ничего нового в самом туннелинге, конечно, нет.
Вероятно самым известным его применением является IPSec,
может быть SSH. Не все обеспечивают удаленный доступ
через IPSec или SSH, но если такой существует, то с
определенной вероятностью можно сказать, что на сервер
на котором они используются пробиться будет довольно
трудно. Посмотрим на сеть с другой стороны... Веб-сервер
- вот превосходная мишень для атаки. Именно с такого
сервера можно начать свое путешествие вглубь сети, даже
не взирая на то, если он защищен файрволом. Тут нам на
помощь и приходит HTTP туннелинг. Опасаясь различных
напастей админы внедряют все новые и новые системы
защиты, как на пути между инетом и сервером, так и на
сервере самом. В таких условиях использование HTTP
вероятно единственный способ обмануть их.
HTTP туннелинг позволяет клиенту инкапсулировать
трафик в HTTP заголовки. Затем трафик направляется к
серверу на другом конце канала и там пакеты программой
обрабатываются обратно, извлекаются данные из
заголовков, и только потом уже редиректятся к своей
конечной цели. По такой схеме можно передавать как UDP,
так и ТСР данные, это обусловлено самой природой
туннелирования.
Сейчас существует только две программы для HTTP
туннелирования. Одна с открытым кодом, другая продается
за деньги. Первая это GNU HTTPtunnel, вторая - HTTP Tunnel. Обе выполняют одну задачу
- передачу информации через HTTP.
HTTPtunnel в примере
Программу можно использовать для доступа к тем
портам, которые в нормальном состоянии недоступны.
Посмотрите на рисунок, слева атакующий, целевая система
- справа.

Роутер, допустим, имеет такие настройки:
inbound: permit tcp any host WWW port 80 permit
tcp any host WWW port 443 permit tcp any host
DNS/SMTP port 25 permit udp any host DNS/SMTP
port 53
outbound: permit ip any
any
Файрвол отстроен так:
inbound: permit ip host DNS/SMTP host SSH eq
22 permit ip host DNS/SMTP host SSH eq
80 permit ip host DNS/SMTP host SSH eq
443
outbound: permit ip any
any
Не обращайте внимание на некоторое упрощение схемы,
она достаточная для демонстрации. Представим, что
атакующему удалось взломать WWW сервер с IIS (ведь это
не так трудно представить? :)) и получить доступ к
командной строке. Хакер загружает скомпилированную
версию HTTP tunnel сервера (hts). Синтаксис командной
строки выглядит так:
hts.exe -F (SRC PORT) (TARGET):(DST PORT)
(SRC PORT) - порт который будет
форвардится (TARGET) - IP адрес хоста на который
будут посылаться данные (DST PORT) - целевой порт,
который будет принимать трафик.
В таком виде когда клиент посылает информацию на SRC
PORT и она будет пересылаться на DST PORT компьютера
TARGET. С установленным hts сервером атакующий стартует
клиента на своей системе и передает трафик на SRC PORT
сервера. Синтаксис клиента таков:
htc -F (SRC PORT) (TARGET):(DST PORT)
Все не более сложно: клиент слушает на SRC PORT и
передает на DST PORT компьютеру TARGET.
Вернемся к нашим баранам. Вот рисунок, иллюстрирующий
дальнейшее развитие ситуации: атакующий установил hts на
WWW и запустил клиента htc на своей системе.

Процесс hts слушает на 80 порту, в примере он
перенаправляет данные к 23 порту DNS/SMTP сервера.
Атакующий соединяется с 1025 портом на своей машине -
htc инкапсулирует трафик в HTTP заголовки - пересылает
на WWW на 80 порт - сервер принимает пакеты и вырезает
из них полезную информацию - передает на DNS/SMTP на 23
порт. Вот и выход - хотя телнетовский порт на прямую не
открыт, к нему мы достучались в обход и теперь с ним
можно делать практически все, что душе угодно.
Другая возможность - указать hts на удаленном сервере
на finger port (79) на SMTP/DNS машине и вывести список
всех пользователей системы. Дальше уже дело техники -
можно подбирать пароли к логинам брутфорсом, можно через
переполнение буфера в sadmind, в общем получить доступ к
серваку за роутером достаточно реально. Завоевав
SMTP/DNS можно и его использовать для дальнейшего
разворачивания атаки. Например, можно мониторить
соединения и определить потенциальные службы и
компьютеры, которые работают за файрволом, в
корпоративной сети за демилитаризованной зоной.
Обнаружив хост с SSH сервером можно использовать
SMTP/DNS и полученные данные о логинах/паролях для
соединения с новой целью...

Итак, становится ясно, что с использование HTTP
туннелинга можно обойти многие ограничения, налагаемые
администраторами. Это довольно удобный инструмент о
котором не следует забывать как защитникам, так и
нападающим :).
|