02.11.2016 @ 14:20 Туннелирование. Проникаем в корпоративную сеть через шлюз dnscat, regeorg, ssh-tunnel, sshuttle Предположим, что мы получили доступ к корпоративному веб-серверу, который имеет два сетевых интерфейса: один в Интернет, а второй в локальную корпоративную сеть. Что дальше? Веб-сервер разрешает входящие подключения только на 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. Поэтому следует уделять повышенное внимание к узлам, имеющим выход в сеть Интернет. antgorka 19787 Network security Читать дальше >>