Несмотря на то, что все больше трафика
подвергается исследованию и ограничению,
администраторы в основном забывают про
главный порт в их сети - 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 туннелинга можно обойти многие
ограничения, налагаемые администраторами.
Это довольно удобный инструмент о котором
не следует забывать как защитникам, так и
нападающим :).
