Connettore Universal Dynamic Virtual Channel per i Servizi Desktop remoto (UDVC)

I Terminal Services (o Servizi Desktop remoto) offrono molte funzionalità nascoste per chi vuole andare più a fondo. Uno di questi servizi è il Dynamic Virtual Channel che consente di comunicare su una connessione RDP aperta senza la necessità di aprire un nuovo socket, una nuova connessione o una porta sul firewall. Questi canali possono essere usati per nascondere dati ai dispositivi di rete attivi, per bypassare i firewall, per implementare driver di dispositivo attraverso la rete o semplicemente per aiutare i penetration tester a trasferire dati. Le possibilità sono infinite.

Il vero motivo per cui questo progetto è stato creato è XFLTReaT. Questo potrebbe essere usato per costruire una "VPN" su reti segmentate e infine consente di testare tramite jumpbox senza dover richiedere modifiche al firewall. In poche parole, rende la vita dei penetration tester più facile.

Come funziona?

Devi installare un plugin (.dll) sul computer client che usi per connetterti al server RDP. Sul server RDP devi usare l'altra metà del progetto, il file .exe, che crea il canale tra il plugin e l'eseguibile del server. Se vuoi maggiori dettagli, scorri più in basso.

Installazione

È solo per Windows. I Dynamic Virtual Channels sono stati introdotti in Window Server 2008 & Windows Vista SP1. Questi e qualsiasi cosa più recente dovrebbero essere a posto.

Puoi prendere l'intero progetto e compilarlo da solo oppure usare i binari compilati dalla sezione Releases. È importante che in tutti i casi venga usato il binario corretto; seleziona quello giusto per l'architettura corrispondente (se il client è a 32 bit ma il server è a 64 bit, prendi la dll a 32 bit e l'exe a 64 bit). Il file .dll deve essere posizionato sul computer client in una qualsiasi directory (per un uso a lungo termine puoi metterlo in %SYSROOT%\system32\ o %SYSROOT%\SysWoW64\) e installarlo con il seguente comando come utente elevato (ovvero Amministratore): regsvr32.exe UDVC-Plugin.dll

Se il tuo utente non è un amministratore, devi importare anche le impostazioni del registro per il tuo utente. Usa il file UDVC-Plugin.reg per questo.

Se desideri rimuoverlo: regsvr32.exe /u UDVC-Plugin.dll

Da ora in poi, ogni volta che ti connetti a un server RDP, questo plugin verrà caricato e si configurerà come specificato nel registro (vedi sotto).

Il file .exe deve essere messo sul server RDP ed eseguito come qualsiasi utente.

Modalità supportate

Entrambi i lati supportano tre modalità al momento:

Modalità server socket (0 - predefinita)

Quando questa modalità è abilitata, viene impostato un listener sulla porta e sull'interfaccia (indirizzo IP) definiti.

Modalità client socket (1)

In questa modalità viene effettuata una connessione verso un listener sull'indirizzo IP e sulla porta definiti.

Modalità Named Pipe (2)

Questa modalità imposta una named pipe con il nome specificato. Ad esempio, questa modalità può essere usata da altri strumenti per fare comunicazione IPC tramite RDP. Sfortunatamente, le named pipe vengono scritte su disco, quindi sono considerate lente rispetto alle modalità socket. Se ti interessa la larghezza di banda, usa le modalità socket.

Opzioni/Configurazione

Sia il client che il server binario si comportano allo stesso modo e possono essere configurati con le stesse opzioni.

• enabled: 0 disabilitato, 1 abilitato (solo plugin). Di default è abilitato e lo comunica in una finestra di messaggio ogni volta che avvii una connessione.
• mode: 0 per listen(), 1 per connect() e 2 per creare una named pipe
• ip: a quale IP connettersi o su quale IP fare il bind
• port: a quale porta connettersi o su quale porta fare il bind
• namedpipename: nome della named pipe
• priority (solo server binario) priorità LOW, MEDIUM, HIGH, REAL per la trasmissione dei dati. La priorità REAL potrebbe compromettere seriamente l'usabilità della sessione in caso di trasferimento dati intenso, poiché il protocollo dà priorità ai dati rispetto al controllo.

Il server binario legge le opzioni dalla riga di comando.

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)

Il client .dll legge tutte le opzioni dal registro; i valori si trovano sotto la seguente chiave: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\UDVC-Plugin

Ogni volta che il modulo è abilitato e prima che venga effettuata la connessione, viene mostrato un avviso di promemoria. Proprio così:

Questo avviso garantisce che l'utente sappia che il plugin è caricato e con quali impostazioni.

Utilizzo

I listener, le connessioni o le named pipe vengono creati solo quando l'eseguibile del server riesce a connettersi al plugin dll. Dipende dalla tua configurazione, ma di default quando la connessione Virtual Channel viene stabilita (il plugin è stato caricato correttamente, il server binario è stato eseguito) il listener è su localhost:31337 su entrambi gli endpoint. Quando ti connetti a queste porte e invii dati attraverso il socket, appariranno dall'altra parte.

Esempi di casi d'uso

Solo per mostrare alcuni casi d'uso in cui questo strumento può essere usato.

Port forwarding molto basilare. La macchina Segregated 1 ha un servizio HTTP su tcp/80. Quella rete non è instradata dalla rete 192.168.0.0/24; per accedervi bisogna usare la jump box dual homed. La modalità listen è configurata sul lato client su 0.0.0.0:31337 e il server binario è stato eseguito con le impostazioni della modalità connect per creare una connessione al server web. L'utente sul client RDP può usare il proprio browser per aprire http://127.0.0.1:31337 e accedere ai contenuti da http://10.13.37.2:80.

Uno scenario un po' più avanzato per trasferire file. Entrambi gli endpoint sono configurati per ascoltare su 0.0.0.0:31337. Prima la macchina Hacking si connette al client RDP e attende l'input. Poi la macchina Segregated 2 si connette alla Jump box e legge l'intero file nel socket.

Come extra, si possono usare anche le named pipe. In questo caso sia il client RDP che la Jump box creano una named pipe su entrambi i lati (hIPC-client e hIPC-server) e le altre macchine possono connettersi a queste pipe. Qualunque cosa venga scritta nelle pipe apparirà dall'altra estremità. Non è molto diverso dall'esempio della modalità listen qui sopra, tranne per il fatto che usa named pipe invece di socket TCP.

Problemi

Nel caso in cui il plugin non si carichi o l'eseguibile non venga eseguito perché mancano alcune DLL, ad esempio VCRUNTIME140.DLL, potresti voler installare il pacchetto Visual C++ Redistributable for Visual Studio 2015.