|
|||||||||||||
|
|||||||||||||
Такая возможность есть и практически на всех уровнях модели OSI. Широко известны инструменты туннелирования, использующие служебные заголовки протоколов сетевого уровня TCP/UDP. Однако практическое применение таких туннелей ограничено из-за их низкой пропускной способности. Более широкие перспективы для построения скрытых коммуникационных каналов основываются на использовании прикладных протоколов. Здесь есть возможность быстрой передачи больших объемов произвольной информации в качестве полезной нагрузки самого протокола, а не кода внутри его служебных заголовков. Одним из таких протоколов является HTTP. Основное поле для использования скрытых каналов это локальные сети, имеющие доступ в Интернет. Как правило, работа с сетевыми сервисами за пределами домашней сети жестко регламентируется различными системами контроля доступа. Эта статья является практической, в ней мы рассмотрим два способа использования протокола HTTP для туннелирования произвольных данных протоколов сетевого уровня. Оба метода могут быть использованы как для доступа из локальной сети за ее пределы, так и для обратной задачи. ССTT(Covert Channel Tunneling Tool) Инструмент Туннелирования в Скрытых Канналах. CCTT позволяет создавать коммуникационные каналы через системы контроля сетевого доступа с потоками данных, которые позволяют:
|
Новости
20 бoлeзнeй oт кoта
Опасность вейпинга
Вpeднa ли coя жeнщинaм
Вcя пpавда o яйцаx
Вpaчи нaпoмнили o pискe зapaзиться гeпaтитoм в сaлoнaх кpaсoты
В кaкoе время сyтoк лyчше не лечиться
Tиxий чаc дважды в нeдeлю cнижаeт pиcк инфаpкта и инcульта в два pаза
Слaдкaя гaзиpoвкa вoздействyет нa opгaнизм
Почeмy витaминныe добaвки нe пpиноcят пользы
|
Для использования CCTT необходимо установить его клиентскую часть в локальной сети и серверную во внешней сети. В качестве канала передачи между ними могут выступать TCP, UDP соединения и TCP соединения с использованием метода HTTP CONNECT через локальный HTTP прокси сервер или через цепь HTTP прокси серверов. Одна из интересных особенностей CCTT это работа в режиме реверсивного прокси. ССTT клиент устанавливает соединение с CCTT сервером (TCP, UDP, HTTP CONNECT) и регистрируется на нем как реверсивный прокси. CCTT сервер, находящийся за пределами локальной сети, принимает соединения от клиентов, находит соответствующую запись в таблице зарегистрированных реверсивных прокси и использует уже открытое соединение с соответствующим прокси, как канал для передачи данных. ССTT клиент, принимает эти данные и устанавливает соединение с нужным сервисом внутри локальной сети. Так же есть возможность кодировать поток данных между CCTT клиентом и сервером.
В большинстве локальных сетей использование метода HTTP CONNECT запрещено на внутреннем HTTP прокси сервере. В этом случае может работать технология, реализованная в проекте Firepass. Здесь используется метод HTTP POST. Firepass клиент располагается на сервере внутри локальной сети и «слушает» несколько TCP/UDP портов. Как только устанавливается соединение с ним, Firepass клиент отправляет HTTP/1.1 POST запрос на веб сервер во внешней сети. Он может сделать это как напрямую, так и с использованием локального HTTP прокси сервера. Ресурс, на который он отправляет POST запрос, это Firepass сервер. В заголовке первого HTTP запроса указываться адрес, порт и протокол сервиса во внешней сети с которым необходимо установить соединение. Firepass сервер, получив первый запрос, порождает новый процесс – “менеджер соединения”, который и будет устанавливать дальнейшее соединение со внешним сервисом.. Далее Firepass клиент с некоторым интервалом отправляет серверу HTTP POST запросы с TCP/UDP данными, полученными от своего клиента. Эти данные отправляются на целевой сервис с использованием «менеджера соединения». Данные же полученные от сервиса проходят обратный путь и возвращаются Firepass клиенту в качестве HTTP ответа на очередной POST запрос. В некоторых случаях, если позволяет конфигурация сети и DMZ возможно проникновение извне в локальную сеть через, например, корпоративный веб сервер. В этом случае Firepass сервер работает на корпоративном веб сервере, а Firepass клиент общается с ним из внешнего мира. Одно из достоинств технологии использованной в Firepass это множество вариантов размещения его серверной части. Требуется только веб сервер и возможность устанавливать с него исходящие TCP/UDP соединения.
Заключение
Приведенные здесь методы, показывают только несколько вариантов использования протокола HTTP в качестве среды передачи произвольных данных. В целом же можно сказать, что если в локальной сети есть клиент с возможностью отправлять/принимать HTTP запросы (методы GET, POST, CONNECT), то для него так же всегда есть возможность использования HTTP как туннеля для протоколов сетевого и прикладного уровня.
Это неплохо работающий способ обойти файрвол и достучаться до внутренних хостов локальной сети через веб-сервер, который открыт «наружу».
Если можно залить на этот сервер специальный веб-сценарий, то с большой вероятностью получишь возможность обращаться к узлам из локальной сети этого сервера, которые при этом в инете не открыты! Любое подобное решение состоит из двух частей — клиента и сервера, которые инкапсулируют трафик в обычные HTTP GET- и POST-запросы и передают в таком виде данные между собой.
Данные при этом сжимаются, криптуются и кодируются в base64. Существует много реализаций подобного подхода, в том числе немало коммерческих. Есть две бесплатные разработки: reDuh и HTTPTunnel. Мне приглянулась первая, так как ее серверная часть (та, которая заливается на веб-сервер) доступна в трех вариациях: на JSP, PHP и ASPX. В зависимости от того, какие технологии используются на веб-сервере, можно выбрать подходящий вариант.
Клиентская часть при этом написана на Java и, соответственно, может быть запущена под любой ОС.Рассмотрим конкретный пример.
Допустим, пентестер Иван, проводя исследование, нашел в некотором вебсценарии уязвимость и может загрузить на сервер скрипт для HTTP-туннелинга.
При этом ему стало известно, что где-то внутри локалки находится RPD-сервер с названием хоста term-serv.victim.com, к которому нет доступа «снаружи» из-за файрвола. Брандмауэр пропускает к вебсерверу только HTTP-трафик и больше ничего. Подключиться к этому серверу и другим хостам из внутренней локальной сети Иван может с помощью HTTPтуннелинга. Это выглядит так:
1. Иван заливает на сервер скрипт reDuh.jsp, который становится доступным по некоторому адресу (пусть это будет ubunt00.victim.com/uploads/reDuh.jsp). Это серверная часть, и она не нуждается в настройке.
2. На локальной машине запускается клиентская часть reDuh — reDuhClient. Это консольное приложение, которому в качестве параметра для запуска передается адрес только что загруженного скрипта:
$ java reDuhClient ubunt00.victim.com 80 /uploads/reDuh.jsp
3. Указать адрес серверной части мало — необходимо еще отконфигурировать туннели с помощью админки, которая по умолчанию запускается на 1010 порту.
Ивану требуется пробросить локальный порт 1234 на порт 3389 (RPD) хоста termserv.victim.com, поэтому правило будет следующим:
[createTunnel]
1234:term-serv.victim.com:3389
4. Все, теперь если Иван подключится с помощью любого RDP-клиента к localhost:1234, то весь его TCP-трафик будет инкапсулироваться в HTTP-запросы, которые передаются на ubunt00.victim.com/uploads/reDuh.jsp, а оттуда уже переадресуются на целевой сервер. Таким образом, он получит желанный доступ к удаленному рабочему столу.
Тут надо сказать, что reDuh не ограничивает количество соединений, поэтому ты можешь создать несколько туннелей для разных хостов и разных сервисов (например, SSH) и использовать их одновременно! Ради интереса я попробовал еще и HTTPTunnel, которая оказалась не менее замечательной разработкой.
Ее большой плюс заключается в наличии специальной клиентской версии с удобным GUI-интерфейсом (только для Windows).
Серверная часть есть в двух вариантах: на PHP и Perl’е. При этом HTTPTunnel может работать в качестве SOCKS-сервера.
Соответственно, подключаясь к внутренним хостам (например, в том же самом RDP-клиенте), ты можешь сразу указывать внутренний адрес хостов для подключения (если возвращаться к нашему примеру, то это term-serv.victim.com).
Но при этом надо предварительно позаботиться о том, чтобы в настройках программы был прописан локальный SOCKS, созданный HTTPTunnel. На случай, если какое-то приложение не поддерживает работу через прокси, его трафик можно принудительно соксофицировать с помощью FreeCap, tsocks или любых других аналогичных приложений.
seo & website usability | html | os faq | hardware faq | memory | video | cpu | hdd | mainboard faq | printer & scaner | modem | mobiles | hackzone |
На главную | Cookie policy | Sitemap