4.6 Разработка алгоритмов установления соединения с компьютером, защищенным межсетевым экраном, персональным сетевым экраном и несколькими сетевыми экранами

4.6.1 Http-тунелирование

Протокол HTTP (HyperText Transfer Protocol) [27], является общим протоколом, работающем на прикладном уровне модели ISO/OSI. Протокол является клиент-серверным с моделью взаимодействия «запрос-ответ». HTTP используется для передачи информации в различных форматах на различных языках и с различным набором символов. Синтаксис HTTP-сообщения основан на стандарте MIME. HTTP является протоколом без сохранения состояния. Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния.

В настоящее время HTTP обладает рядом преимуществ, которые открывают значительные перспективы для использования его в качестве маскирующего протокола:

1. HTTP наиболее распространенный протокол Internet.

2. Использование HTTP разрешено правилами доступа большинства корпоративных сетей.

3. HTTP потенциально позволяет создать канал с большой пропускной способностью.

4. HTTP является протоколом высокого уровня и его анализ представляет собой сложную задачу.

В настоящее время существует большое свободных и коммерческих программных продуктов, а также программных библиотек, реализующих маскирование данных в протоколе HTTP. Данное программное обеспечение использует различные способы маскирования, такие как передача данных в качестве параметров запроса, внедрение данных в необрабатываемую часть запросов HTTP и т.д.

Reverse WWW Shell

Первая практическая работа в данной области «Placing Backdoors Through Firewalls» выполнена Ван Хаузером [28] и относится к 1998 году. van Hauser является членом злоумышленникской группы THC (The Hackers Choice) [29] и занимается вопросами создания маскированных каналов для управления троянскими программами. В качестве иллюстрации к данной работе Ван Хаузер разработал инструмент Reverse WWW Shell.

Reverse WWW Shell представляет собой клиент-серверное приложение. Схема работы Reverse WWW Shell показана на рисунке 4.14.

Р исунок 4. 14 - Схема работы Reverse WWW Shell

Протокол работы программы представлен на рисунке 4.15.

Рисунок 4. 15 - Протокол работы Reverse WWW Shell

Сервер Reverse WWW Shell устанавливается на контролируемом хосте, например, рабочей станции во внутренней сети. Клиент выполняется на любом доступном хосте Internet и контролируется злоумышленником. Сервер периодически, через заданное время отправляет запрос клиенту на получение команд («вытягивает» команды). Запрос представляет собой HTTP POST или HTTP GET (в зависимости от настроек сервера) к скрипту /cgi-bin/orderform, содержащий закодированную строку инициализации. Клиент получает данный запрос и выводит приглашение пользователю на ввод команды. После ввода команды клиент отправляет ее в виде закодированной строки в теле ответа HTTP/OK.

Сервер исполняет команду и следующим запросом «проталкивает» результат обратно.

На рисунке 4.16 приведена TCP протокол сеанса Reverse WWW Shell между сервером 192.168.164.112 и клиентом 192.168.164.220. В листинге приведен протокол HTTP сеанса Reverse WWW Shell. В данном случае 192.168.164.112 сообщает о своем старте строкой «M5mAljVr...», клиент отправляет команду ls «g5mAlfbknz».

Рисунок 4.16 - Регистрационная информация сеанса Reverse WWW Shell

192.168.164.112 > 192.168.164.220

POST /cgi-bin/orderform HTTP/1.0

Host: 192.168.164.220

User-Agent: Mozilla/4.0

Accept: text/html, text/plain, image/jpeg, image/*;

Accept-Language: en

Content-Type: application/x-www-form-urlencoded

M5mAljVrZdgYOdgIO8BqCfVYTjFpLdgENdb1He7krjVAEfgPn6WcOfW1taFUSz0agoR9b5Sasq3fgoV95TCdtttz

192.168.164.220 > 192.168.164.112

HTTP/1.1 200 OK

Connection: close

Content-Type: text/plain

g5mAlfbknz

Данная реверсивная схема позволяет клиенту постоянно отправлять команды серверу без установления с ним входящего соединения, что в большинстве случаев запрещено политикой безопасности.

GNU HTTP Tunnel

GNU HTTP Tunnel является инструментом маскирования данных в протоколе HTTP. HTTP Tunnel поддерживает клиент-серверное взаимодействие, в данном случае клиент - это хост, который инициирует соединение, например, хочет получить или отправить информацию, а сервер - хост, к которому производится обращение, например, запрос HTML страницы и т.д. Данный инструмент разработан Lars Brinkhoff и распространяется под лицензией GNU General Public License.

Н а рисунке 4.17 приведена типичная схема функционирования GNU HTTP Tunnel.

Рисунок 4.17 - Схема работы GNU HTTP Tunnel

Клиент HTTP Tunnel устанавливается на контролируемую ПЭВМ. Прикладная программа, например, Web-браузер, FTP-клиент и т.д., настраивается на работу через HTTP Tunnel клиент как через прикладной прокси или изменяется таблица маршрутизации на клиентской ПЭВМ.

Сервер HTTP туннель устанавливается на маскирующий сервер - любой публичный хоcт Internet. HTTP Tunnel сервер настраивается на переадресацию демаскированного трафика на сервер услуг.

Протокол функционирования GNU HTTP Tunnel представлен на рисунке 4.18.

Рисунок 4.18 - Протокол функционирования GNU HTTP Tunnel

Клиентская прикладная программа переадресует [ПРИКЛАДНЫЕ ДАННЫЕ#01] клиенту HTTP Tunnel. HTTP Tunnel маскирует прикладные данные и помещает их в протокол HTTP с оберткой из запроса POST /index.html?crap=XXXXX HTTP/1.1, где XXXXX - уникальный идентификатор сессии.

Данный запрос передается на сервер HTTP Tunnel. Сервер извлекает [ПРИКЛАДНЫЕ ДАННЫЕ#01] и передает серверу. Поскольку обработка прикладных данных может занимать значительное время, то соединение между HTTP Tunnel Client и HTTP Tunnel Server разрывается и клиент посылает еще один запрос POST /index.html?crap=XXXXX HTTP/1.1 для получения результата. В данном случае ответы также «вытягиваются» клиентом.

Сервер HTTP Tunnel отвечает HTTP ответом HTTP/1.0 ОК в теле, которого находятся прикладные данные. Клиент HTTP Tunnel демаскирует данные и передает их клиентской прикладной программе. На листинге показан фрагмент протокола взаимодействия между клиентом HTTP Tunnel 192.168.164.221, сервером HTTP Tunnel 192.168.164.220 и прикладным сервером 194.67.57.26 (web-сервер www.mail.ru).

45 64.189094 192.168.164.221 192.168.164.220 TCP 1050 > http [SYN] Seq=0 Ack=0 Win=64240 Len=0 MSS=1460

46 64.189200 192.168.164.220 192.168.164.221 TCP http > 1050 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1351

47 64.190144 192.168.164.221 192.168.164.220 TCP 1050 > http [ACK] Seq=1 Ack=1 Win=64848 Len=0

48 64.282078 192.168.164.221 192.168.164.220 TCP [TCP segment of a reassembled PDU]

...

89 65.165023 192.168.164.220 194.67.57.26 TCP 1224 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1351

90 65.165252 194.67.57.26 192.168.164.220 TCP http > 1224 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460

91 65.165310 192.168.164.220 194.67.57.26 TCP 1224 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0

93 65.183854 192.168.164.220 194.67.57.26 HTTP GET http://www.mail.ru/ HTTP/1.0

94 65.184180 194.67.57.26 192.168.164.220 TCP http > 1224 [ACK] Seq=1 Ack=273 Win=6432 Len=0

В листинге приведен декодированный протокол HTTP:

192.168.164.221 > 192.168.164.220

POST /index.html?crap=1153916332 HTTP/1.1

Host: 192.168.164.220:80

Content-Length: 102400

Connection: close

...*...GET http://www.mail.ru/ HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*

Accept-Language: ru

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Host: www.mail.ru

Proxy-Connection: Keep-Alive

EF

192.168.164.220 > 194.67.57.26

GET http://www.mail.ru/ HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*

Accept-Language: ru

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Host: www.mail.ru

Proxy-Connection: Keep-Alive

HTTP/1.0 200 OK

Date: Wed, 26 Jul 2006 12:17:49 GMT

Server: Apache/1.3.31 (Unix) mod_deflate/1.0.21 rus/PL30.20

Set-Cookie: Mpopl=1221748781; expires=Wed, 26 Jul 2006 12:32:49 GMT; path=/; domain=.mail.ru

. . .

Proxy-Connection: close

192.168.164.221 > 192.168.164.220

GET /index.html?crap=1153916333 HTTP/1.1

Host: 192.168.164.220:80

Connection: close

HTTP/1.1 200 OK

Content-Length: 102400

Connection: close

Pragma: no-cache

Cache-Control: no-cache, no-store, must-revalidate

Expires: 0

Content-Type: text/html

...HTTP/1.0 200 OK

Date: Wed, 26 Jul 2006 12:17:49 GMT

Server: Apache/1.3.31 (Unix) mod_deflate/1.0.21 rus/PL30.20

Set-Cookie: Mpopl=1221748781; expires=Wed, 26 Jul 2006 12:32:49 GMT; path=/; domain=.mail.ru

. . .

Proxy-Connection: close

Из листинга видно, что страница www.mail.ru переданная от 194.67.57.26 к 192.168.164.220 передается далее к 192.168.164.221.

GNU HTTP Tunnel существует в реализациях для Linux и Windows 32.

Gray-World Firepass

Система Firepass разработана Alex Dyatlov из злоумышленникской группы Gray-World. Firepass - это клиент серверная система, которая обеспечивает маскирование произвольных TCP и UDP пакетов в протоколе HTTP. В данной системе клиент является прикладной сетевой программой, которая выполняет маскирование данных произвольных протоколов на основе TCP и UDP в прокол HTTP. Клиент устанавливается на компьютере внутри локальной сети, откуда производится передача данных. Сервер представляет собой cgi-скрипт, установленный на любом доступном web-сервере. Скрипт принимает запросы протокола HTTP с замаскированными данными, извлекает данные и отправляет адресату. Система предусматривает работу через несколько промежуточных серверов. Схема работы Firepass представлена на рисунке 4.19.

Рисунок 4.19 - Схема работы Firepass

Протокол работы Firepass показан на рисунке 4.20.

Рисунок 4.20 - Протокол работы Firepass

Firepass реализован в виде двух приложений на языке Perl: fpserver.cgi - CGI скрипт выполняющий функции сервера и fpсlient.pl - Perl скрипт выполняющий функции клиента.