Хабрахабр

Пишем Reverse socks5 proxy на powershell.Часть 1

История об исследовании и разработке в 3-х частях. Часть 1 — исследовательская.
Буков много — пользы еще больше.

Постановка задачи

В ходе проведения пентестов и RedTeam кампаний не всегда удается воспользоваться штатными средствами Заказчиков, такими как VPN, RDP, Citrix и т.д. в качестве закрепления для захода во внутреннюю сеть. Где-то штатный VPN работает по MFA и в качестве второго фактора используется железный токен, где-то он жестоко мониторится и наш вход по VPN сразу же становится виден, как говорится — со всеми вытекающими, а где-то таких средств попросту нет.

Внутри такого туннеля мы уже можем работать с внутренними ресурсами Заказчиков. В подобных случаях постоянно приходится делать так называемые «обратные туннели» — соединения из внутренней сети к внешнему ресурсу или контролируемому нами серверу.

Самый известный из них, конечно же, Meterpreter. Существуют несколько разновидностей таких обратных туннелей. Средств осуществления обратного туннелирования достаточно много и многие из них хорошо изучены и описаны. Так же большим спросом в народных хакерских массах пользуются SSH-туннели с обратным пробросом портов.

Конечно же, со своей стороны разработчики защитных решений не стоят в стороне и активно детектируют подобные действия.

К примеру, MSF-сессии успешно детектируются современными IPS от Cisco или Positive Tech, а обратный SSH- туннель можно задетектить практически любым мало-мальским нормальным файерволлом.

Следовательно, для того чтобы остаться незамеченным в хорошей RedTeam кампании — нам необходимо строить обратный туннель нестандартными средствами и максимально близко подстраиваться под реальный режим работы сети.

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

Понятно, что для каждого случая такие требования могут сильно отличаться, но по опыту работы можно выделить основные:

  • работа на ОС Windows-7-10. Так как в большинстве корпоративных сетях используется именно винда;
  • клиент соединяется с сервером по SSL для исключения тупого прослушивания средствами ips;
  • при соединении клиент должен поддерживать работу через прокси-сервер с авторизацией, т.к. во многих компаниях выход в интернет происходит через прокси. На самом деле, клиентская машина может об этом даже ничего и не знать, а прокси используется в транспарентном режиме. Но такой функционал мы должны заложить;
  • клиентская часть должна быть лаконична и портабельна;
    Понятно, что для работы внутри сети Заказчика на клиентской машине можно установить OpenVPN и поднять полноценный туннель до своего сервера (благо что клиенты openvpn умеют работать через прокси). Но, во-первых, это не всегда получится, так как мы можем не быть там локальными админами, а во-вторых, это наделает так много шуму, что порядочный SIEM или HIPS тут же на нас «настучит куда надо». В идеале наш клиент должен быть так называемой inline командой, как например реализованы многие bash-шеллы, и запускаться через командную строку, например, при выполнении команд из word-макроса.
  • наш туннель должен быть многопоточным и поддерживать множество соединений одновременно;
  • соединение клиент-сервер должно иметь какую-либо авторизацию, чтобы туннель устанавливался только для нашего клиента, а не для всех, кто придет к нам на сервер по указанному адресу и порту. В идеале, для «сторонних пользователей» должна открываться лендинг-страница с котиками или профессионально тематикой, связанной с исходным доменом.
    Например, если Заказчиком выступает медицинская организация, то для администратора информационной безопасности, решившего проверить ресурс, на который обращался сотрудник клиники, должна открыться страница с фармацевтическими товарами, википедия с описанием диагноза или блог доктора Комаровского и т.д.

Анализ существующих инструментов

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

В основном, все сводится к построению ssh-туннелей с обратным пробросом портов и всего, что с этим связано. Гугление в интернете (гуглим мы вроде нормально), а также поиск по гитхабу по ключевым словам «reverse socks» не дал особо много результатов. Помимо SSH-туннелей можно выделить несколько решений:

По названию понятно, для чего предназначен этот скрипт. github.com/klsecservices/rpivot
Давняя реализация обратного туннеля от ребят из Лаборатории Касперского. 7, туннель работает в cleartext режиме (как модно сейчас говорить — привет РКН) Реализован на Python 2.

Написан в виде модуля и есть API для интеграции решения в свои проекты. github.com/tonyseek/rsocks
Еще одна реализация на питоне, так же в cleartext, но возможностей больше.

github.com/llkat/rsockstun
github.com/mis-team/rsockstun
Первая ссылка — изначальная версия реализации реверс сокса на голанге (не поддерживается разработчиком).

В нашей версии мы реализовали SSL, работу через прокси с NTLM-авторизацией, авторизацию на клиенте, лендинг-страницу при неверном пароле (вернее — редирект на лендинг-страницу), многопоточный режим (т.е. Вторая ссылка — уже наша доработка с дополнительными фишками, также на голанге. с туннелем могут работать несколько человек одновременно), систему пингов клиента на предмет того — живой он или нет.

Там же для ленивых и «бессмертных» лежит уже готовый бинарь (exe), собранный китайцами и готовый к использованию. github.com/jun7th/tsocks
Реализация обратного сокса от наших «китайских друзей» на питоне. Тут один только китайский бог знает, что в этом бинаре может быть еще, кроме основного функционала, так что используйте на свой страх и риск.

Помимо обратного туннеля, он может делать проброс портов, создание командного шелла и т.д. github.com/securesocketfunneling/ssf
Довольно-таки интересный проект на С++ для реализации обратного сокса и не только.

Все мало-мальски образованные хакеры прекрасно знакомы с этой штукой и понимают, насколько легко ее обнаруживают средства защиты. MSF meterpreter
Тут как говорится, без комментариев.

На сервере запускается SOCKS4/5 сервер, принимающий подключения и транслирующий их на клиента. Все вышеописанные инструменты работают по схожей технологии: на машине внутри сети запускается заранее подготовленный исполняемый бинарный модуль, который устанавливает соединение с внешним сервером.

А загрузка exe с последующим его запуском — это еще та сигнатура для местного антивируса или HIPS. Недостатком всех вышеперечисленных инструментов является то, что либо на клиентской машине необходим установленный Python или Golang (часто ли вы встречали установленный Python на машинах, к примеру, директора компании или офисных работников?), либо на эту машину необходимо тащить заранее собранный бинарь (фактически python и скрипт в одном флаконе) и запускать этот бинарь уже там.

Сейчас в нас полетят помидоры — мол powershell — это уже все избито, он мониторится, блокируется и т.д. В общем, вывод напрашивается сам собой — нам нужно решение на powershell. На самом деле — далеко не везде. и т.п. Кстати, существует уйма способов обойти блокировки (тут опять модная фраза про привет РКН 🙂 ), начиная от тупого переименования powershell.exe -> cmdd.exe и заканчивая powerdll и т.п. Ответственно заявляем.

Начинаем изобретать

Понятное дело, что сперва мы посмотрим в гугл и… не найдем ровным счетом ничего по этой теме (если кто-то нашел — кидайте ссылки в комменты). Есть только реализация Socks5 на powershell, но это обычный «прямой» сокс, имеющий ряд своих недостатков (о них поговорим позднее). Можно, конечно, легким движением руки превратить его в обратный, но это будет только однопоточный сокс, что для нас не совсем то, что надо.

За основу нашего велосипеда мы возьмем нашу разработку обратного сокса на голанге, а клиента к нему реализуем на powershell. Итак, мы не нашли ничего готового, поэтому нам придется все-таки изобрести свой велосипед.

RSocksTun

Итак, как же работает rsockstun?

Socks5 сервер — это обычный локальный socks5, он запускается на клиенте. В основе работы RsocksTun (далее по тексту — rs) лежат два программных компонента — Yamux и Socks5 сервер. Такая схема позволяет запускать несколько клиентских socks5 серверов и распределять внешние подключения к ним, пробрасывая их через одно единственное TCP-соединение (почти как в meterpreter) от клиента к серверу, реализуя тем самым многопоточный режим, без которого нам просто не получится полноценно работать во внутренней сети. А мультиплексирование соединений к нему (помните про многопоточность?) обеспечивается с помощью yamux (yet another multiplexer).

(Здесь мы намеренно используем слово «стрим», а не поток, чтобы не путать читателя с программным потоком «thread» — это понятие мы так же будем использовать в данной статье). Суть работы yamux’а заключается в том, что он вводит дополнительный сетевой уровень стримов, реализуя его в виде 12-байтного заголовка для каждого пакета. Внутри yamux заголовка содержатся номер стрима, флаги для установки/завершения стрима, количество передаваемых байт, размер окна передачи.

Работа механизма keeplive-сообщений настраивается при создании Yamux-сессии. Помимо установки/завершения стрима в yamux реализован механизм keepalive’ов, позволяющий отслеживать работоспособность установленного канала связи. Keepalive-сообщения может отсылать yamux-сервер, так yamux-клиент. Собственно, из настроек там только — два параметра: enable/disable и периодичность отсылки пакетов в секундах. В общем, keepalive — это тот же пинг, только для yamux. При получении keepalive-сообщения удаленная сторона обязана ответить на него посылкой точно такого же идентификатора сообщения (фактически — числа), который она приняла.

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

Заключение к первой части

Итак, в первой части статьи мы познакомились с некоторым инструментарием по организации обратных туннелей, посмотрели на их преимущества и недостатки, изучили механизм работы Yamux мультиплексора и описали основные требования к вновь создаваемому powershell-модулю. В следующей части мы займемся разработкой самого модуля, практически, с нуля. Продолжение следует. Не переключайтесь 🙂

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть