- PVSM.RU - https://www.pvsm.ru -
История об исследовании и разработке в 3-х частях. Часть 1 — исследовательская.
Буков много — пользы еще больше.
В ходе проведения пентестов и RedTeam кампаний не всегда удается воспользоваться штатными средствами Заказчиков, такими как VPN, RDP, Citrix и т.д. в качестве закрепления для захода во внутреннюю сеть. Где-то штатный VPN работает по MFA и в качестве второго фактора используется железный токен, где-то он жестоко мониторится и наш вход по VPN сразу же становится виден, как говорится — со всеми вытекающими, а где-то таких средств попросту нет.
В подобных случаях постоянно приходится делать так называемые «обратные туннели» — соединения из внутренней сети к внешнему ресурсу или контролируемому нами серверу. Внутри такого туннеля мы уже можем работать с внутренними ресурсами Заказчиков.
Существуют несколько разновидностей таких обратных туннелей. Самый известный из них, конечно же, Meterpreter. Так же большим спросом в народных хакерских массах пользуются SSH-туннели с обратным пробросом портов. Средств осуществления обратного туннелирования достаточно много и многие из них хорошо изучены и описаны.
Конечно же, со своей стороны разработчики защитных решений не стоят в стороне и активно детектируют подобные действия.
К примеру, MSF-сессии успешно детектируются современными IPS от Cisco или Positive Tech, а обратный SSH- туннель можно задетектить практически любым мало-мальским нормальным файерволлом.
Следовательно, для того чтобы остаться незамеченным в хорошей RedTeam кампании — нам необходимо строить обратный туннель нестандартными средствами и максимально близко подстраиваться под реальный режим работы сети.
Давайте попробуем найти или изобрести нечто подобное.
Прежде чем что-то изобретать надо понять, какого результата мы хотим достичь, какие функции должна выполнять наша разработка. Какие же будут требования к туннелю, чтобы мы могли работать в режиме максимальной скрытности?
Понятно, что для каждого случая такие требования могут сильно отличаться, но по опыту работы можно выделить основные:
Прежде чем изобретать свой велосипед — необходимо сделать анализ существующих велосипедов и понять, действительно ли оно нам надо и, вероятно, не только мы задумались о необходимости такого функционального велосипеда.
Гугление в интернете (гуглим мы вроде нормально), а также поиск по гитхабу по ключевым словам «reverse socks» не дал особо много результатов. В основном, все сводится к построению ssh-туннелей с обратным пробросом портов и всего, что с этим связано. Помимо SSH-туннелей можно выделить несколько решений:
github.com/klsecservices/rpivot [1]
Давняя реализация обратного туннеля от ребят из Лаборатории Касперского. По названию понятно, для чего предназначен этот скрипт. Реализован на Python 2.7, туннель работает в cleartext режиме (как модно сейчас говорить — привет РКН)
github.com/tonyseek/rsocks [2]
Еще одна реализация на питоне, так же в cleartext, но возможностей больше. Написан в виде модуля и есть API для интеграции решения в свои проекты.
github.com/llkat/rsockstun [3]
github.com/mis-team/rsockstun [4]
Первая ссылка — изначальная версия реализации реверс сокса на голанге (не поддерживается разработчиком).
Вторая ссылка — уже наша доработка с дополнительными фишками, также на голанге. В нашей версии мы реализовали SSL, работу через прокси с NTLM-авторизацией, авторизацию на клиенте, лендинг-страницу при неверном пароле (вернее — редирект на лендинг-страницу), многопоточный режим (т.е. с туннелем могут работать несколько человек одновременно), систему пингов клиента на предмет того — живой он или нет.
github.com/jun7th/tsocks [5]
Реализация обратного сокса от наших «китайских друзей» на питоне. Там же для ленивых и «бессмертных» лежит уже готовый бинарь (exe), собранный китайцами и готовый к использованию. Тут один только китайский бог знает, что в этом бинаре может быть еще, кроме основного функционала, так что используйте на свой страх и риск.
github.com/securesocketfunneling/ssf [6]
Довольно-таки интересный проект на С++ для реализации обратного сокса и не только. Помимо обратного туннеля, он может делать проброс портов, создание командного шелла и т.д.
MSF meterpreter
Тут как говорится, без комментариев. Все мало-мальски образованные хакеры прекрасно знакомы с этой штукой и понимают, насколько легко ее обнаруживают средства защиты.
Все вышеописанные инструменты работают по схожей технологии: на машине внутри сети запускается заранее подготовленный исполняемый бинарный модуль, который устанавливает соединение с внешним сервером. На сервере запускается SOCKS4/5 сервер, принимающий подключения и транслирующий их на клиента.
Недостатком всех вышеперечисленных инструментов является то, что либо на клиентской машине необходим установленный Python или Golang (часто ли вы встречали установленный Python на машинах, к примеру, директора компании или офисных работников?), либо на эту машину необходимо тащить заранее собранный бинарь (фактически python и скрипт в одном флаконе) и запускать этот бинарь уже там. А загрузка exe с последующим его запуском — это еще та сигнатура для местного антивируса или HIPS.
В общем, вывод напрашивается сам собой — нам нужно решение на powershell. Сейчас в нас полетят помидоры — мол powershell — это уже все избито, он мониторится, блокируется и т.д. и т.п. На самом деле — далеко не везде. Ответственно заявляем. Кстати, существует уйма способов обойти блокировки (тут опять модная фраза про привет РКН :) ), начиная от тупого переименования powershell.exe -> cmdd.exe и заканчивая powerdll и т.п.
Понятное дело, что сперва мы посмотрим в гугл и… не найдем ровным счетом ничего по этой теме (если кто-то нашел — кидайте ссылки в комменты). Есть только реализация [7] Socks5 на powershell, но это обычный «прямой» сокс, имеющий ряд своих недостатков (о них поговорим позднее). Можно, конечно, легким движением руки превратить его в обратный, но это будет только однопоточный сокс, что для нас не совсем то, что надо.
Итак, мы не нашли ничего готового, поэтому нам придется все-таки изобрести свой велосипед. За основу нашего велосипеда мы возьмем нашу разработку [4] обратного сокса на голанге, а клиента к нему реализуем на powershell.
RSocksTun
Итак, как же работает rsockstun?
В основе работы RsocksTun (далее по тексту — rs) лежат два программных компонента — Yamux и Socks5 сервер. Socks5 сервер — это обычный локальный socks5, он запускается на клиенте. А мультиплексирование соединений к нему (помните про многопоточность?) обеспечивается с помощью yamux (yet another multiplexer [8]). Такая схема позволяет запускать несколько клиентских socks5 серверов и распределять внешние подключения к ним, пробрасывая их через одно единственное TCP-соединение (почти как в meterpreter) от клиента к серверу, реализуя тем самым многопоточный режим, без которого нам просто не получится полноценно работать во внутренней сети.
Суть работы yamux’а заключается в том, что он вводит дополнительный сетевой уровень стримов, реализуя его в виде 12-байтного заголовка для каждого пакета. (Здесь мы намеренно используем слово «стрим», а не поток, чтобы не путать читателя с программным потоком «thread» — это понятие мы так же будем использовать в данной статье). Внутри yamux заголовка содержатся номер стрима, флаги для установки/завершения стрима, количество передаваемых байт, размер окна передачи.
Помимо установки/завершения стрима в yamux реализован механизм keepalive’ов, позволяющий отслеживать работоспособность установленного канала связи. Работа механизма keeplive-сообщений настраивается при создании Yamux-сессии. Собственно, из настроек там только — два параметра: enable/disable и периодичность отсылки пакетов в секундах. Keepalive-сообщения может отсылать yamux-сервер, так yamux-клиент. При получении keepalive-сообщения удаленная сторона обязана ответить на него посылкой точно такого же идентификатора сообщения (фактически — числа), который она приняла. В общем, keepalive — это тот же пинг, только для yamux.
Подробно вся техника работы мультиплексора: типы пакетов, флаги установки и завершения соединений механизм передачи данных описана в спецификации [9] к yamux.
Итак, в первой части статьи мы познакомились с некоторым инструментарием по организации обратных туннелей, посмотрели на их преимущества и недостатки, изучили механизм работы Yamux мультиплексора и описали основные требования к вновь создаваемому powershell-модулю. В следующей части мы займемся разработкой самого модуля, практически, с нуля. Продолжение следует. Не переключайтесь :)
Автор: karelovao
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/319207
Ссылки в тексте:
[1] github.com/klsecservices/rpivot: https://github.com/klsecservices/rpivot
[2] github.com/tonyseek/rsocks: https://github.com/tonyseek/rsocks
[3] github.com/llkat/rsockstun: https://github.com/llkat/rsockstun
[4] github.com/mis-team/rsockstun: https://github.com/mis-team/rsockstun
[5] github.com/jun7th/tsocks: https://github.com/jun7th/tsocks
[6] github.com/securesocketfunneling/ssf: https://github.com/securesocketfunneling/ssf
[7] реализация: https://github.com/p3nt4/Invoke-SocksProxy
[8] yet another multiplexer: https://github.com/hashicorp/yamux/
[9] спецификации: https://github.com/hashicorp/yamux/blob/master/spec.md
[10] Источник: https://habr.com/ru/post/453870/?utm_source=habrahabr&utm_medium=rss&utm_campaign=453870
Нажмите здесь для печати.