Универсальный коннектор динамического виртуального канала для служб удалённых рабочих столов (UDVC)

Терминальные службы (или службы удалённых рабочих столов) предлагают множество скрытых возможностей для тех, кто хочет копнуть глубже. Одной из таких служб является динамический виртуальный канал (Dynamic Virtual Channel), который позволяет обмениваться данными через открытое RDP-соединение без необходимости открывать новый сокет, соединение или порт на брандмауэре. Эти каналы можно использовать для сокрытия данных от активных сетевых устройств, для обхода брандмауэров, для реализации драйверов устройств через сеть или просто для помощи пентестерам в передаче данных. Возможности безграничны.

Настоящая причина создания этого проекта — XFLTReaT. Его можно использовать для построения «VPN» поверх сегрегированных сетей, а в конечном счёте он позволяет проводить тестирование через прыжковые хосты (jump boxes) без необходимости запрашивать изменения в брандмауэре. Если кратко, он делает жизнь пентестеров проще.

Как это работает?

Вам необходимо установить плагин (.dll) на клиентский компьютер, с которого вы подключаетесь к RDP-серверу. На RDP-сервере нужно использовать вторую половину проекта — .exe, который создаёт канал между плагином и исполняемым файлом сервера. Если вы хотите узнать больше подробностей, прокрутите страницу вниз.

Установка

Только для Windows. Динамические виртуальные каналы были представлены в Windows Server 2008 и Windows Vista SP1. Эти версии и всё, что новее них, подойдут.

Вы можете скачать весь проект и скомпилировать его самостоятельно или просто использовать готовые бинарники из раздела Releases. Важно всегда использовать правильный бинарник: выберите тот, который соответствует архитектуре (если ваш клиент 32-битный, а сервер 64-битный, возьмите 32-битную dll и 64-битный exe).

Файл .dll нужно поместить на клиентском компьютере в любой каталог (для долгосрочного использования можно положить его в %SYSROOT%\system32\ или %SYSROOT%\SysWoW64\) и установить следующей командой от имени пользователя с повышенными привилегиями (т.е. администратора): regsvr32.exe UDVC-Plugin.dll

Если ваша учётная запись не является администратором, вам также необходимо импортировать параметры реестра в раздел вашего пользователя. Для этого используйте файл UDVC-Plugin.reg.

Если вы хотите удалить его: regsvr32.exe /u UDVC-Plugin.dll

Каждый раз, когда вы подключаетесь к RDP-серверу, этот плагин будет загружаться и настраиваться в соответствии с указанными в реестре параметрами (см. ниже).

Файл .exe нужно разместить на RDP-сервере и запустить от имени любого пользователя.

Поддерживаемые режимы

Обе стороны в настоящее время поддерживают три режима:

Режим сокет-сервера (0 — по умолчанию)

При включении этого режима на указанном порту и интерфейсе (IP-адресе) будет создан прослушивающий сокет (listener).

Режим сокет-клиента (1)

В этом режиме будет установлено соединение с прослушивающим сокетом на указанном IP-адресе и порту.

Режим именованного канала (Named Pipe) (2)

Этот режим создаёт именованный канал (Named Pipe) с указанным именем. Например, этот режим может использоваться другими инструментами для межпроцессного взаимодействия (IPC) через RDP. К сожалению, именованные каналы записываются на диск, поэтому они считаются медленными по сравнению с сокетными режимами. Если для вас важна пропускная способность, используйте сокетные режимы.

Параметры/Конфигурация

Клиентский и серверный бинарники работают одинаково и могут быть настроены с помощью одних и тех же параметров.

• enabled: 0 — отключено, 1 — включено (только для плагина). По умолчанию этот параметр включён, и при каждом инициировании подключения будет показываться окно с сообщением (messagebox).
• mode: 0 — для listen(), 1 — для connect() и 2 — для создания именованного канала.
• ip: IP-адрес, к которому подключаться или который следует привязать.
• port: порт, к которому подключаться или который следует привязать.
• namedpipename: имя именованного канала.
• priority (только для серверного бинарника): приоритеты LOW, MEDIUM, HIGH, REAL для передачи данных. Приоритет REAL может серьёзно повлиять на доступность сеанса при интенсивной передаче данных, поскольку протокол отдаёт приоритет данным, а не управлению.

Серверный бинарник считывает параметры из командной строки.

PS C:\Users\UDVC\> .\UDVC-Server.exe -h
Universal Dynamic Virtual Channel server application

Usage: C:\Users\UDVC\UDVC-Server.exe [-s | -c [-p port [-h ip]] | -m [-n name]] [-0 | -1 | -2 | -3]
Socket server mode -s (default) OR
Socket client mode -c:
        -p port   port to bind the listener (default: 31337)
        -i ip     ip to bind the listener (default: 127.0.0.1)

Named pipe mode -m:
        -n name   name of the named pipe (by default: "\\.\pipe\UDVC_{RDP SESSION NUMBER}")

Data transfer priority parameters:
        -0        real time             (WTS_CHANNEL_OPTION_DYNAMIC_PRI_REAL)
        -1        high priority         (WTS_CHANNEL_OPTION_DYNAMIC_PRI_HIGH) - default
        -2        medium priority       (WTS_CHANNEL_OPTION_DYNAMIC_PRI_MED)
        -3        low priority          (WTS_CHANNEL_OPTION_DYNAMIC_PRI_LOW)

Клиентский .dll считывает все параметры из реестра; значения можно найти в следующем разделе: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\UDVC-Plugin

Каждый раз, когда модуль включён, перед установкой соединения отображается предупреждение-напоминание. Вот так:

Это предупреждение гарантирует, что пользователь знает о том, что плагин загружен и с какими настройками.

Использование

Прослушивающие сокеты, соединения и именованные каналы создаются только после того, как серверный исполняемый файл смог подключиться к плагину dll. Это зависит от вашей конфигурации, но по умолчанию, когда соединение виртуального канала установлено (плагин загружен корректно, серверный бинарник запущен), обе конечные точки прослушивают localhost:31337. Когда вы подключаетесь к этим портам и отправляете данные через сокет, они появляются на другой стороне.

Примеры использования

Просто несколько примеров, где можно использовать этот инструмент.

Очень простой проброс портов. На машине «Segregated 1» работает HTTP-сервис на tcp/80. Эта сеть не маршрутизируется из сети 192.168.0.0/24, поэтому для доступа необходимо использовать двусетевой прыжковый хост (jump box). На клиентской стороне настроен режим прослушивания на 0.0.0.0:31337, а серверный бинарник запущен с настройками режима подключения для создания соединения с веб-сервером. Пользователь на RDP-клиенте может открыть в браузере http://127.0.0.1:31337, чтобы получить доступ к содержимому с http://10.13.37.2:80.

Чуть более продвинутый сценарий для передачи файлов. Обе конечные точки настроены на прослушивание 0.0.0.0:31337. Сначала машина «Hacking box» подключается к RDP-клиенту и ожидает ввода. Затем машина «Segregated 2» подключается к прыжковому хосту «Jump box» и считывает весь файл в сокет.

В качестве дополнительной возможности можно использовать и именованные каналы. В этом случае RDP-клиент и прыжковый хост «Jump box» создают именованный канал на обеих сторонах (hIPC-client и hIPC-server), и другие машины могут подключаться к этим каналам. Всё, что записывается в каналы, появляется на другом конце. Это не сильно отличается от примера с режимом прослушивания выше, за исключением того, что вместо TCP-сокетов используются именованные каналы.

Проблемы

Если плагин не загружается или исполняемый файл не запускается из-за отсутствия некоторых DLL, например VCRUNTIME140.DLL, возможно, стоит установить пакет Visual C++ Redistributable for Visual Studio 2015.