Несанкционированная передача данных с использованием HTTP туннелирования

Идо Дубравский, перевод Владимир Куксенок

Большая часть трафика приходит в Интернет после исследования, и сетевые администраторы предпринимают шаги по ограничению трафика своих сетей, но есть один порт, который никто не хочет закрывать - обычно это порт 80. Пользователи (и администраторы) постоянно просматривают веб сайты, независимо от того, нужно это для работы или нет. Жизненная основа присутствия компании в Интернет, так или иначе, требует наличие веб ресурса, а это требует наличия веб сервера, размещенного у хостинг провайдера или в сети компании. С каждым новым червем, ошибкой или уязвимостью обнаруженной в IIS или Apache, сетевые администраторы и администраторы безопасности пытаются заблокировать эти сервисы на маршрутизаторе или брандмауэре. Для идентификации атак многие используют IDS и IPS.

В этой статье мы рассмотрим способы обхода ограничений доступа маршрутизатора или брандмауэра компании. Эта информация предназначена в помощь тем, кто законно тестирует безопасность сети (независимо от того, являются ли они внутренними экспертами или внешними консультантами). Данная статья ни в коем случае не потворствует использованию этой информации для неправомерного доступа к сети или системе. И, наконец, в этой статье будут упомянуты способы защиты от этой атаки.

Что такое туннелирование HTTP?

Туннелирование не представляет собой ничего нового. IPSec это, возможно, самый широко известный способ туннелирования, наиболее близким продолжением которого является SSH туннелирование. Однако, если атакующий не имеет достаточно высоких шансов на успех, маловероятно, что он выберет IPSec или SSH в качестве возможного порта проникновения. Не каждая компания предоставляет удаленный доступ через IPSec или SSH, но если она делает это, сервер вероятно уже укреплен. В дополнение, скорее всего в качестве концентратора используется заказное устройство типа Cisco VPN 3000 и возможно UNIX/Linux система.

Из-за повсеместного распространения вед серверов они являются превосходной целью для атакующего. Кроме того, при условии, что они находятся за брандмауэром, веб сервера представляют из себя единственный, но важный вход в целевую сеть. Это тот случай, где применяется туннелирование. Так как возросло понимание необходимости защиты, компании установили дополнительные системы защиты между веб сервером и Интернет, так же как и непосредственно на самом веб сервере. Средства обнаружения вторжений (IDS) и Средства предотвращения вторжений (IPS) используются для идентификации и уведомления администраторов об обнаружении атаки против системы или сети. Но даже у них есть свои недостатки, и HTTP туннелирование может использоваться для обхода этих средств.

HTTP туннелирование использует клиентское приложение, чтобы инкапсулировать трафик в пределах HTTP заголовка. Затем трафик идет на сервер на другом конце канала связи, который обрабатывает пакет, "раздевает" заголовки HTTP пакета и переадресовывает пакет его заключительному адресату. И UDP и TCP трафик может использоваться для инкапсулирования. Это возможно из-за самой природы туннелирования, подобной IPSec туннелю, где реальным пакетом является полезная нагрузка исходного пакета.

В настоящее время есть только два приложения для туннелирования HTTP. Одно из них распространяется с открытым исходным кодом, другое коммерческий продукт. Первое приложение, доступное на сайте http://www.nocrew.org/software/httptunnel.html, это GNU HTTPtunnel. Второе - HTTP Tunnel корпорации HTTP-Tunnel. Оба они разработаны для обеспечения соединения к различным портам, осуществляя связь через 80 TCP порт. Оставшеяся часть статьи посвящена свободно распространяемому GNU HTTPtunnel и его использованию для тестирования брандмауэров и других фильтров трафика.

Пример туннелирования HTTP

Туннелирование HTTP может использоваться для доступа к портам, которые обычно недоступны из сети. Взгляните на Рисунок 1 ниже. Хост атакующего показан слева, а целевые системы справа. Маршрутизатор имеет следующие правила:

Рисунок 1: Пример установки HTTP Tunnel

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

Не смотря на то, что все очень упрощено, этого вполне достаточно для демонстрационных целей. Атакующий взламывает веб сервер с установленным IIS. Не важно какой именно эксплойт он использует, важно то, что он способен эксплойтировать сервер и получить доступ к системе через командную строку. Как только он получает этот доступ, он загружает скомпилированную версию сервера HTTP Tunnel, hts. Синтаксис запуска сервера HTTP Tunnel следующий:

hts.exe -F (SRC PORT) (TARGET):(DST PORT)

(SRC PORT) это порт, который будет переадресован, (TARGET) это IP адрес целевого хоста, а (DST PORT) это целевой порт, который будет принимать переадресовываемый трафик. Когда клиент посылает трафик на (SRC PORT) сервер автоматически переадресовывает его на (DST PORT) хоста (TARGET). (TARGET) может быть IP адресом системы, на которой запущен hts сервер. После установки hts сервера атакующий запускает клиент на свой системе и направляет его трафик на (SRC PORT) системы с установленным hts сервером. Синтаксис запуска клиента HTTP Tunnel такой же, как и для сервера:

htc -F <SRC PORT> <TARGET>:<DST PORT>

Клиент принимает трафик с и переадресовывает его на хоста .

Посмотрите на следующий пример атаки на систему с Рисунка 1. На Рисунке 2, ниже, атакующий устанавливает hts на WWW хост (шаг 1) и запускает htc на своей системе (шаг 2). Процесс hts слушает порт 80 WWW хоста и может переадресовывать трафик. В этом примере атакующий использует hts, чтобы переадресовывать трафик на telnet порт (TCP/23) DNS/SMTP сервера, на котором запущен Solaris 2.6.

Когда атакующий соединяется с портом 1025 на свой системе (шаг 3), процесс htc инкапсулирует трафик в HTTP заголовки и переадресовывает его на веб сервер (шаг 4). Этот сервер принимает трафик, "раздевает" HTTP заголовок и переправляет трафик на 23 порт DNS/SMTP сервера (шаг 5). Таким образом, в то время как порт telnet на DNS/SMTP сервера напрямую недоступен вне корпоративного маршрутизатора, атакующий имеет доступ к этому порту, и может попробовать перебором узнать логин и пароль для доступа к системе.
Рисунок 2: Начальное использование HTTP Tunnel

Другая возможность состоит в том, чтобы установить удаленный конец hts туннеля на finger port (TCP/79) SMTP/DNS хоста и получить список всех пользователей системы. Это позволит получить первое представление о возможных именах учетных записей. Однажды доступ к системе будет получен, либо перебором, либо с помощью эксплойта, например, через переполнение буфера в sadmind и атакующий получит доступ к системе, находящейся за маршрутизатором, к которой в обычных обстоятельствах доступа нет. Получив доступ к командной строке SMTP/DNS хоста, находящегося за маршрутизатором, атакующий может установить дополнительные утилиты для дальнейшего проникновения в сеть. Например, атакующий может следить за соединениями к SMTP/DNS хосту и получать информацию о потенциальных сервисах, запущенных на системах, которые находятся за брандмауэром. Это было бы более скрытным методом разведки, чем прямое сканирование IP адресов в пределах DMZ. Если атакующий идентифицирует хост, на котором запущен SSH сервер (находится за брандмауэром), он может использовать SMTP/DNS хост, чтобы попытаться подключиться к новой цели и использовать любую предполагаемую или взломанную информацию об учетных записях для получения доступа, как это показано на Рисунке 3 ниже.

Рисунок 3: Дальнейшее проникновение в сеть

Туннелирование HTTP в испытании на проникновение

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