RSS

Компьютерная терминология    1_9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  .....  A  Б  В  Г  Д  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч

HTTP протокол

Cкрытые каналы в протоколе прикладного уровня HTTP

В любом наборе информации, будь то исполняемая программа, графическое изображение или сетевой протокол есть пути переноса дополнительных «скрытых» данных.

Такая возможность есть и практически на всех уровнях модели OSI. Широко известны инструменты туннелирования, использующие служебные заголовки протоколов сетевого уровня TCP/UDP. Однако практическое применение таких туннелей ограничено из-за их низкой пропускной способности. Более широкие перспективы для построения скрытых коммуникационных каналов основываются на использовании прикладных протоколов. Здесь есть возможность быстрой передачи больших объемов произвольной информации в качестве полезной нагрузки самого протокола, а не кода внутри его служебных заголовков. Одним из таких протоколов является HTTP.

Основное поле для использования скрытых каналов это локальные сети, имеющие доступ в Интернет. Как правило, работа с сетевыми сервисами за пределами домашней сети жестко регламентируется различными системами контроля доступа. Эта статья является практической, в ней мы рассмотрим два способа использования протокола HTTP для туннелирования произвольных данных протоколов сетевого уровня. Оба метода могут быть использованы как для доступа из локальной сети за ее пределы, так и для обратной задачи.

ССTT

(Covert Channel Tunneling Tool) Инструмент Туннелирования в Скрытых Канналах. CCTT позволяет создавать коммуникационные каналы через системы контроля сетевого доступа с потоками данных, которые позволяют:

  • получить shell на внешнем сервере из внутренней сети.
  • предоставить shell с сервера находящегося во внутренней сети внешнему серверу.
  • установить канал позволяющий TCP соединения (SSH, SMTP, POP и т.д.) между внешним сервером и компьютером во внутренней сети.
  • Для использования CCTT необходимо установить его клиентскую часть в локальной сети и серверную во внешней сети. В качестве канала передачи между ними могут выступать TCP, UDP соединения и TCP соединения с использованием метода HTTP CONNECT через локальный HTTP прокси сервер или через цепь HTTP прокси серверов. Одна из интересных особенностей CCTT это работа в режиме реверсивного прокси. ССTT клиент устанавливает соединение с CCTT сервером (TCP, UDP, HTTP CONNECT) и регистрируется на нем как реверсивный прокси. CCTT сервер, находящийся за пределами локальной сети, принимает соединения от клиентов, находит соответствующую запись в таблице зарегистрированных реверсивных прокси и использует уже открытое соединение с соответствующим прокси, как канал для передачи данных. ССTT клиент, принимает эти данные и устанавливает соединение с нужным сервисом внутри локальной сети. Так же есть возможность кодировать поток данных между CCTT клиентом и сервером.

    Firepass

    В большинстве локальных сетей использование метода 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-туннелирование

    Это неплохо работающий способ обойти файрвол и достучаться до внутренних хостов локальной сети через веб-сервер, который открыт «наружу».

    Если можно залить на этот сервер специальный веб-сценарий, то с большой вероятностью получишь возможность обращаться к узлам из локальной сети этого сервера, которые при этом в инете не открыты! Любое подобное решение состоит из двух частей — клиента и сервера, которые инкапсулируют трафик в обычные 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

    Internet
    WAN
    HTTP
    X25 сети
    Протоколы
    Telnet
    Cookies
    DNS faq
    IRC faq
    SOCKS
    Inet faq
    IP faq
    FTP faq
    GPRS faq
    Ports faq
    Протокол SMTP
    Протокол IMAP
    Mail faq
    The BAT faq
    Home LAN
    Office LAN
    Настройка шлюза
    Проблемы администратора
    Выбор кабеля
    Ресурсы локальной сети
    LAN faq
    WLAN faq
    Wi-Fi
    Windows 10 | Registry Windows 10 | Windows7: Общие настройки | Windows7: Реестр | Windows7: Реестр faq | Windows7: Настроки сети | Windows7: Безопасность | Windows7: Брандмауэр | Windows7: Режим совместимости | Windows7: Пароль администратора |  |  |  |  | Память | SDRAM | DDR2 | DDR3 | Quad Band Memory (QBM) | SRAM | FeRAM | Словарь терминов | Video | nVIDIA faq | ATI faq  | Интегрированное видео faq | TV tuners faq | Терминология | Форматы графических файлов | Работа с цифровым видео(faq) | Кодеки faq | DVD faq | DigitalVideo faq | Video faq (Архив) | CPU | HDD & Flash faq | Как уберечь винчестер | HDD faq | Cable faq | SCSI адаптеры & faq | SSD | Mainboard faq | Printer & Scaner | Благотворительность

    На главную | Cookie policy | Sitemap

     ©  2004