История об исследовании и разработке в 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-макроса. - наш туннель должен быть многопоточным и поддерживать множество соединений одновременно;
- соединение клиент-сервер должно иметь какую-либо авторизацию, чтобы туннель устанавливался только для нашего клиента, а не для всех, кто придет к нам на сервер по указанному адресу и порту. В идеале, для «сторонних пользователей» должна открываться лендинг-страница с котиками или профессионально тематикой, связанной с исходным доменом.
Например, если Заказчиком выступает медицинская организация, то для администратора информационной безопасности, решившего проверить ресурс, на который обращался сотрудник клиники, должна открыться страница с фармацевтическими товарами, википедия с описанием диагноза или блог доктора Комаровского и т.д.
Анализ существующих инструментов
Прежде чем изобретать свой велосипед — необходимо сделать анализ существующих велосипедов и понять, действительно ли оно нам надо и, вероятно, не только мы задумались о необходимости такого функционального велосипеда.
Гугление в интернете (гуглим мы вроде нормально), а также поиск по гитхабу по ключевым словам «reverse socks» не дал особо много результатов. В основном, все сводится к построению ssh-туннелей с обратным пробросом портов и всего, что с этим связано. Помимо SSH-туннелей можно выделить несколько решений:
Давняя реализация обратного туннеля от ребят из Лаборатории Касперского. По названию понятно, для чего предназначен этот скрипт. Реализован на Python 2.7, туннель работает в cleartext режиме (как модно сейчас говорить — привет РКН)
Еще одна реализация на питоне, так же в cleartext, но возможностей больше. Написан в виде модуля и есть API для интеграции решения в свои проекты.
Первая ссылка — изначальная версия реализации реверс сокса на голанге (не поддерживается разработчиком).
Вторая ссылка — уже наша доработка с дополнительными фишками, также на голанге. В нашей версии мы реализовали SSL, работу через прокси с NTLM-авторизацией, авторизацию на клиенте, лендинг-страницу при неверном пароле (вернее — редирект на лендинг-страницу), многопоточный режим (т.е. с туннелем могут работать несколько человек одновременно), систему пингов клиента на предмет того — живой он или нет.
Реализация обратного сокса от наших «китайских друзей» на питоне. Там же для ленивых и «бессмертных» лежит уже готовый бинарь (exe), собранный китайцами и готовый к использованию. Тут один только китайский бог знает, что в этом бинаре может быть еще, кроме основного функционала, так что используйте на свой страх и риск.
Довольно-таки интересный проект на С++ для реализации обратного сокса и не только. Помимо обратного туннеля, он может делать проброс портов, создание командного шелла и т.д.
MSF meterpreter
Тут как говорится, без комментариев. Все мало-мальски образованные хакеры прекрасно знакомы с этой штукой и понимают, насколько легко ее обнаруживают средства защиты.
Все вышеописанные инструменты работают по схожей технологии: на машине внутри сети запускается заранее подготовленный исполняемый бинарный модуль, который устанавливает соединение с внешним сервером. На сервере запускается SOCKS4/5 сервер, принимающий подключения и транслирующий их на клиента.
Недостатком всех вышеперечисленных инструментов является то, что либо на клиентской машине необходим установленный Python или Golang (часто ли вы встречали установленный Python на машинах, к примеру, директора компании или офисных работников?), либо на эту машину необходимо тащить заранее собранный бинарь (фактически python и скрипт в одном флаконе) и запускать этот бинарь уже там. А загрузка exe с последующим его запуском — это еще та сигнатура для местного антивируса или HIPS.
В общем, вывод напрашивается сам собой — нам нужно решение на powershell. Сейчас в нас полетят помидоры — мол powershell — это уже все избито, он мониторится, блокируется и т.д. и т.п. На самом деле — далеко не везде. Ответственно заявляем. Кстати, существует уйма способов обойти блокировки (тут опять модная фраза про привет РКН 🙂 ), начиная от тупого переименования powershell.exe -> cmdd.exe и заканчивая powerdll и т.п.
Начинаем изобретать
Понятное дело, что сперва мы посмотрим в гугл и… не найдем ровным счетом ничего по этой теме (если кто-то нашел — кидайте ссылки в комменты). Есть только Socks5 на powershell, но это обычный «прямой» сокс, имеющий ряд своих недостатков (о них поговорим позднее). Можно, конечно, легким движением руки превратить его в обратный, но это будет только однопоточный сокс, что для нас не совсем то, что надо.
Итак, мы не нашли ничего готового, поэтому нам придется все-таки изобрести свой велосипед. За основу нашего велосипеда мы возьмем обратного сокса на голанге, а клиента к нему реализуем на powershell.
RSocksTun
Итак, как же работает rsockstun?
В основе работы RsocksTun (далее по тексту — rs) лежат два программных компонента — Yamux и Socks5 сервер. Socks5 сервер — это обычный локальный socks5, он запускается на клиенте. А мультиплексирование соединений к нему (помните про многопоточность?) обеспечивается с помощью yamux (). Такая схема позволяет запускать несколько клиентских socks5 серверов и распределять внешние подключения к ним, пробрасывая их через одно единственное TCP-соединение (почти как в meterpreter) от клиента к серверу, реализуя тем самым многопоточный режим, без которого нам просто не получится полноценно работать во внутренней сети.
Суть работы yamux’а заключается в том, что он вводит дополнительный сетевой уровень стримов, реализуя его в виде 12-байтного заголовка для каждого пакета. (Здесь мы намеренно используем слово «стрим», а не поток, чтобы не путать читателя с программным потоком «thread» — это понятие мы так же будем использовать в данной статье). Внутри yamux заголовка содержатся номер стрима, флаги для установки/завершения стрима, количество передаваемых байт, размер окна передачи.
Помимо установки/завершения стрима в yamux реализован механизм keepalive’ов, позволяющий отслеживать работоспособность установленного канала связи. Работа механизма keeplive-сообщений настраивается при создании Yamux-сессии. Собственно, из настроек там только — два параметра: enable/disable и периодичность отсылки пакетов в секундах. Keepalive-сообщения может отсылать yamux-сервер, так yamux-клиент. При получении keepalive-сообщения удаленная сторона обязана ответить на него посылкой точно такого же идентификатора сообщения (фактически — числа), который она приняла. В общем, keepalive — это тот же пинг, только для yamux.
Подробно вся техника работы мультиплексора: типы пакетов, флаги установки и завершения соединений механизм передачи данных описана в к yamux.
Заключение к первой части
Итак, в первой части статьи мы познакомились с некоторым инструментарием по организации обратных туннелей, посмотрели на их преимущества и недостатки, изучили механизм работы Yamux мультиплексора и описали основные требования к вновь создаваемому powershell-модулю. В следующей части мы займемся разработкой самого модуля, практически, с нуля. Продолжение следует. Не переключайтесь 🙂
Источник: habr.com