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