Universal Dynamic Virtual Channel Connector für Remotedesktopdienste (UDVC)

Terminaldienste (oder Remotedesktopdienste) bieten viele versteckte Funktionen für diejenigen, die tiefer graben möchten. Einer dieser Dienste ist der Dynamic Virtual Channel, der es ermöglicht, über eine offene RDP-Verbindung zu kommunizieren, ohne einen neuen Socket, eine Verbindung oder einen Port in einer Firewall öffnen zu müssen. Diese Kanäle können verwendet werden, um Daten vor aktiven Netzwerkgeräten zu verstecken, Firewalls zu umgehen, Gerätetreiber über Netzwerke zu implementieren oder einfach um Penetrationstestern das Übertragen von Daten zu erleichtern. Die Möglichkeiten sind endlos.

Der eigentliche Grund, warum dieses Projekt erstellt wurde, ist XFLTReaT. Dies könnte genutzt werden, um ein „VPN“ über segmentierte Netzwerke aufzubauen und ermöglicht schließlich das Testen über Jumpboxen, ohne Firewall-Änderungen beantragen zu müssen. Kurz gesagt, es erleichtert Penetrationstestern das Leben.

Wie funktioniert das?

Sie müssen ein Plugin (.dll) auf Ihrem Client-Computer installieren, den Sie für die Verbindung zum RDP-Server verwenden. Auf dem RDP-Server müssen Sie die andere Hälfte des Projekts, die .exe, verwenden, die den Kanal zwischen dem Plugin und der Server-Exe erstellt. Wenn Sie weitere Details erfahren möchten, scrollen Sie bitte nach unten.

Installation

Es ist nur für Windows. Dynamic Virtual Channels wurden in Windows Server 2008 & Windows Vista SP1 eingeführt. Diese und alles neuere sollte funktionieren.

Sie können das gesamte Projekt herunterladen und selbst kompilieren oder einfach die kompilierten Binärdateien aus dem Releases-Bereich verwenden. Es ist wichtig, dass in allen Fällen die korrekte Binärdatei verwendet wird. Bitte wählen Sie die richtige für die entsprechende Architektur (wenn Ihr Client 32-Bit ist, der Server jedoch 64-Bit, dann nehmen Sie die 32-Bit dll und die 64-Bit exe). Die .dll muss auf dem Client-Computer in einem beliebigen Verzeichnis abgelegt werden (für den Langzeitgebrauch können Sie sie in %SYSROOT%\system32\ oder %SYSROOT%\SysWoW64\ ablegen) und mit dem folgenden Befehl als erhöhter Benutzer (auch Administrator genannt) installiert werden: regsvr32.exe UDVC-Plugin.dll

Wenn Ihr Benutzer kein Administrator ist, müssen Sie die Registrierungseinstellungen auch für Ihren Benutzer importieren. Verwenden Sie dafür die Datei UDVC-Plugin.reg.

Wenn Sie es entfernen möchten: regsvr32.exe /u UDVC-Plugin.dll

Ab sofort wird bei jeder Verbindung zu einem RDP-Server dieses Plugin geladen und konfiguriert sich selbst, wie in der Registry festgelegt (siehe unten).

Die .exe muss auf dem RDP-Server abgelegt und als beliebiger Benutzer ausgeführt werden.

Unterstützte Modi

Beide Seiten unterstützen derzeit drei Modi:

Socket-Server-Modus (0 - Standard)

Wenn dieser Modus aktiviert ist, wird ein Listener auf dem definierten Port und der Schnittstelle (IP-Adresse) eingerichtet.

Socket-Client-Modus (1)

In diesem Modus wird eine Verbindung zu einem Listener auf der definierten IP-Adresse und dem Port hergestellt.

Named Pipe Modus (2)

Dieser Modus richtet eine Named Pipe mit dem angegebenen Namen ein. Beispielsweise kann dieser Modus von anderen Tools für die IPC-Kommunikation über RDP verwendet werden. Leider werden Named Pipes auf die Festplatte geschrieben, daher gelten sie im Vergleich zu den Socket-Modi als langsam. Wenn Ihnen die Bandbreite wichtig ist, verwenden Sie bitte die Socket-Modi.

Optionen/Konfiguration

Sowohl das Client- als auch das Server-Binary verhalten sich gleich und können mit denselben Optionen konfiguriert werden.

• enabled: 0 deaktiviert, 1 aktiviert (nur Plugin). Standardmäßig ist es aktiviert und zeigt bei jedem Verbindungsaufbau eine Meldung in einer MessageBox an.
• mode: 0 für listen(), 1 für connect() und 2 zum Erstellen einer Named Pipe
• ip: Welche IP für die Verbindung oder Bindung verwendet werden soll
• port: Welcher Port für die Verbindung oder Bindung verwendet werden soll
• namedpipename: Name der Named Pipe
• priority (nur Server-Binary) LOW, MEDIUM, HIGH, REAL Prioritäten für die Datenübertragung. Die Priorität REAL kann die Erreichbarkeit der Sitzung bei intensiver Datenübertragung stark beeinträchtigen, da das Protokoll Daten gegenüber der Steuerung priorisiert.

Das Server-Binary liest die Optionen von der Befehlszeile.

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

Nutzung: C:\Users\UDVC\UDVC-Server.exe [-s | -c [-p port [-h ip]] | -m [-n name]] [-0 | -1 | -2 | -3]
Socket-Server-Modus -s (Standard) ODER
Socket-Client-Modus -c:
        -p port   Port zum Binden des Listeners (Standard: 31337)
        -i ip     IP zum Binden des Listeners (Standard: 127.0.0.1)

Named Pipe Modus -m:
        -n name   Name der Named Pipe (standardmäßig: "\\.\pipe\UDVC_{RDP SESSION NUMBER}")

Datenübertragungsprioritätsparameter:
        -0        Echtzeit              (WTS_CHANNEL_OPTION_DYNAMIC_PRI_REAL)
        -1        Hohe Priorität        (WTS_CHANNEL_OPTION_DYNAMIC_PRI_HIGH) - Standard
        -2        Mittlere Priorität    (WTS_CHANNEL_OPTION_DYNAMIC_PRI_MED)
        -3        Niedrige Priorität    (WTS_CHANNEL_OPTION_DYNAMIC_PRI_LOW)

Die Client-.dll liest alle Optionen aus der Registry; die Werte finden sich unter folgendem Schlüssel: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\UDVC-Plugin

Jedes Mal, wenn das Modul aktiviert ist, wird vor dem Verbindungsaufbau eine Erinnerungswarnung angezeigt. So wie hier:

Diese Warnung stellt sicher, dass der Benutzer weiß, dass das Plugin geladen ist und mit welchen Einstellungen.

Nutzung

Die Listener, Verbindungen oder Named Pipes werden nur erstellt, wenn die Server-Exe eine Verbindung zum Plugin-DLL herstellen konnte. Es hängt von Ihrer Konfiguration ab, aber standardmäßig hört es nach Herstellung der Virtual Channel-Verbindung (das Plugin wurde ordnungsgemäß geladen, das Server-Binary wurde ausgeführt) auf localhost:31337 an beiden Endpunkten. Wenn Sie sich mit diesen Ports verbinden und Daten durch den Socket senden, erscheinen diese auf der anderen Seite.

Beispielhafte Anwendungsfälle

Nur um einige Anwendungsfälle zu zeigen, in denen dieses Tool verwendet werden kann.

Sehr einfaches Port-Forwarding. Die Maschine in Segment 1 hat einen HTTP-Dienst auf tcp/80. Dieses Netzwerk ist nicht vom 192.168.0.0/24-Netzwerk aus geroutet, daher muss die Dual-Homed-Jumpbox verwendet werden, um darauf zuzugreifen. Der Hör-Modus ist auf der Client-Seite auf 0.0.0.0:31337 konfiguriert und das Server-Binary wurde mit den Connect-Modus-Einstellungen ausgeführt, um eine Verbindung zum Webserver herzustellen. Der Benutzer auf dem RDP-Client kann seinen Browser verwenden, um http://127.0.0.1:31337 zu öffnen und auf den Inhalt von http://10.13.37.2:80 zuzugreifen.

Ein etwas fortgeschritteneres Szenario zum Übertragen von Dateien. Beide Endpunkte sind so konfiguriert, dass sie auf 0.0.0.0:31337 hören. Zuerst verbindet sich die Hacking-Box mit dem RDP-Client und wartet auf die Eingabe. Dann verbindet sich die Maschine in Segment 2 mit der Jumpbox und liest die gesamte Datei in den Socket.

Als Extra können auch Named Pipes verwendet werden. In diesem Fall erstellen sowohl der RDP-Client als auch die Jumpbox eine Named Pipe auf beiden Seiten (hIPC-client und hIPC-server) und die anderen Maschinen können sich mit diesen Pipes verbinden. Was auch immer in die Pipes geschrieben wird, erscheint am anderen Ende. Dies unterscheidet sich nicht wirklich vom obigen Beispiel mit dem Hör-Modus, außer dass Named Pipes anstelle von TCP-Sockets verwendet werden.

Probleme

Falls das Plugin nicht geladen wird oder die ausführbare Datei nicht läuft, weil beispielsweise die VCRUNTIME140.DLL fehlt, möchten Sie möglicherweise das Visual C++ Redistributable for Visual Studio 2015 Paket installieren.