earthquake/universaldvcConnecteur universel de canal virtuel dynamique pour les services Bureau à distance
Les services Terminal Server (ou services Bureau à distance) offrent de nombreuses fonctionnalités cachées pour ceux qui veulent creuser plus profondément. Un de ces services est le Dynamic Virtual Channel (canal virtuel dynamique) qui nous permet de communiquer via une connexion RDP ouverte sans avoir besoin d'ouvrir un nouveau socket, une nouvelle connexion ou un port sur un pare-feu. Ces canaux peuvent être utilisés pour masquer des données des équipements réseau actifs, contourner les pare-feu, implémenter des pilotes de périphériques sur les réseaux ou simplement aider les testeurs d'intrusion à transférer des données. Les possibilités sont infinies.
La vraie raison pour laquelle ce projet a été créé est XFLTReaT. Cela pourrait être utilisé pour monter un « VPN » sur des réseaux cloisonnés et permet enfin de tester à travers des jumpboxes sans demander de modifications du pare-feu. En bref, cela facilite la vie des testeurs d'intrusion.
Vous devez installer un plugin (.dll) sur votre ordinateur client que vous utilisez pour vous connecter au serveur RDP. Sur le serveur RDP, vous devez utiliser l'autre moitié du projet, le .exe, qui crée le canal entre le plugin et l'exécutable serveur. Si vous voulez plus de détails, veuillez faire défiler la page.
C'est uniquement pour Windows. Les canaux virtuels dynamiques ont été introduits dans Windows Server 2008 & Windows Vista SP1. Ces versions et tout ce qui est plus récent devraient fonctionner.
Vous pouvez récupérer l'ensemble du projet et le compiler vous-même, ou simplement utiliser les binaires compilés depuis la section Releases. Il est important d'utiliser le bon binaire dans tous les cas, veuillez sélectionner celui qui correspond à l'architecture appropriée (si votre client est en 32 bits mais que le serveur est en 64 bits, prenez la dll 32 bits et l'exe 64 bits).
Le fichier .dll doit être placé sur l'ordinateur client dans n'importe quel répertoire (pour une utilisation à long terme, vous pouvez le placer dans %SYSROOT%\system32\ ou %SYSROOT%\SysWoW64\) et l'installer avec la commande suivante en tant qu'utilisateur élevé (c'est-à-dire administrateur) :
regsvr32.exe UDVC-Plugin.dll
Si votre utilisateur n'est pas administrateur, vous devez également importer les paramètres de registre sous votre utilisateur. Veuillez utiliser le fichier UDVC-Plugin.reg pour cela.
Si vous souhaitez le supprimer :
regsvr32.exe /u UDVC-Plugin.dll
Désormais, à chaque connexion à un serveur RDP, ce plugin sera chargé et se configurera comme spécifié dans le registre (voir ci-dessous).
Le fichier .exe doit être placé sur le serveur RDP et exécuté par n'importe quel utilisateur.
Les deux côtés prennent en charge trois modes pour le moment :
Lorsque ce mode est activé, un listener (écouteur) est mis en place sur le port et l'interface (adresse IP) définis.
Dans ce mode, une connexion est établie vers un listener sur l'adresse IP et le port définis.
Ce mode configure un tube nommé (Named Pipe) avec le nom spécifié. Par exemple, ce mode peut être utilisé par d'autres outils pour effectuer une communication IPC via RDP. Malheureusement, les tubes nommés sont écrits sur le disque, ils sont donc considérés comme lents par rapport aux modes socket. Si vous vous souciez de la bande passante, utilisez les modes socket.
Le binaire client et le binaire serveur se comportent de la même manière et peuvent être configurés avec les mêmes options.
Le binaire serveur lit les options à partir de la ligne de commande.
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)
Le fichier .dll lit toutes les options à partir du registre ; les valeurs se trouvent sous la clé suivante :
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\UDVC-Plugin
Chaque fois que le module est activé et avant que la connexion ne soit établie, un avertissement de rappel s'affiche. Comme ceci :
Cet avertissement garantit que l'utilisateur sait que le plugin est chargé et avec quels paramètres.
Les listeners, connexions ou tubes nommés ne sont créés que lorsque l'exécutable serveur a réussi à se connecter à la dll du plugin. Cela dépend de votre configuration, mais par défaut, lorsque la connexion du canal virtuel est établie (le plugin a été chargé correctement, le binaire serveur a été exécuté), il écoute sur localhost:31337 sur les deux extrémités. Lorsque vous vous connectez à ces ports et envoyez des données via le socket, elles apparaissent de l'autre côté.
Juste pour montrer quelques cas d'utilisation de cet outil.
Redirection de port très basique. La machine Segregated 1 héberge un service HTTP sur tcp/80. Ce réseau n'est pas routé depuis le réseau 192.168.0.0/24 ; la jump box à double carte réseau (dual homed) doit être utilisée pour y accéder. Le mode écoute est configuré côté client sur 0.0.0.0:31337 et le binaire serveur a été exécuté avec les paramètres du mode connexion pour créer une connexion vers le serveur web. L'utilisateur sur le client RDP peut utiliser son navigateur pour ouvrir http://127.0.0.1:31337 afin d'accéder au contenu de http://10.13.37.2:80.
Un scénario un peu plus avancé pour transférer des fichiers. Les deux extrémités sont configurées pour écouter sur 0.0.0.0:31337. D'abord, la machine Hacking se connecte au client RDP et attend l'entrée. Ensuite, la machine Segregated 2 se connecte à la Jump box et lit tout le fichier dans le socket.
En complément, les tubes nommés (Named Pipes) peuvent également être utilisés. Dans ce cas, le client RDP et la Jump box créent tous deux un tube nommé de chaque côté (hIPC-client et hIPC-server) et les autres machines peuvent se connecter à ces tubes. Tout ce qui est écrit sur les tubes apparaît à l'autre extrémité. Ce n'est pas vraiment différent de l'exemple du mode écoute ci-dessus, sauf qu'il utilise des tubes nommés au lieu de sockets TCP.
Si le plugin ne se charge pas ou si l'exécutable ne se lance pas parce qu'il manque certaines DLL, par exemple la VCRUNTIME140.DLL, vous pouvez installer le package Visual C++ Redistributable pour Visual Studio 2015.