Nous écrivons un proxy socks5 inverse en PowerShell. Partie 1.

Une histoire de recherche et de développement en 3 parties. Partie 1 — recherche.
Il y a beaucoup de livres — il y a encore plus d'avantages.

Définition du problème

Lors de la réalisation de tests de pénétration et de campagnes RedTeam, il n'est pas toujours possible d'utiliser les outils standards des clients, tels que VPN, RDP, Citrix, etc., comme point d'accès au réseau interne. Dans certains cas, le VPN standard fonctionne avec MFA et utilise un token matériel comme second facteur, dans d'autres, il est fortement surveillé et notre accès via VPN devient immédiatement visible, pour ainsi dire — avec toutes les conséquences qui en découlent, et dans certains cas, de tels moyens sont tout simplement absents.

Dans de tels cas, il est souvent nécessaire de créer ce que l'on appelle des « tunnels inversés » — des connexions du réseau interne vers un ressource externe ou un serveur que nous contrôlons. À l'intérieur de ce tunnel, nous pouvons déjà travailler avec les ressources internes des clients.

Il existe plusieurs types de tels tunnels inversés. Le plus connu d'entre eux est bien sûr Meterpreter. Les tunnels SSH avec redirection de port inverse sont également très demandés dans les masses de hackers. Il existe de nombreux moyens de réaliser le tunneling inverse, et beaucoup d'entre eux sont bien étudiés et documentés.
Bien entendu, les développeurs de solutions de sécurité ne restent pas les bras croisés et détectent activement de telles actions.
Par exemple, les sessions MSF sont efficacement détectées par les IPS modernes de Cisco ou Positive Tech, et un tunnel SSH inversé peut être détecté par pratiquement n'importe quel pare-feu normal.

Par conséquent, pour rester inaperçu dans une bonne campagne RedTeam — nous devons construire un tunnel inversé avec des moyens non conventionnels et nous adapter au mieux au mode de travail réel du réseau.

Essayons de trouver ou d'inventer quelque chose de similaire.

Avant d'inventer quoi que ce soit, il est nécessaire de comprendre quel résultat nous voulons atteindre, quelles fonctions notre développement doit remplir. Quelles seront les exigences du tunnel pour que nous puissions travailler dans un mode de maximum de discrétion ?

Il est évident que ces exigences peuvent varier considérablement d'un cas à l'autre, mais d'après l'expérience, on peut en dégager quelques-unes principales :

• fonctionnement sur Windows 7-10. Étant donné que Windows est utilisé dans la plupart des réseaux d'entreprise.
• Le client se connecte au serveur via SSL pour éviter l'écoute passive par des moyens IPS.
• Lors de la connexion, le client doit être capable de travailler à travers un serveur proxy avec authentification, car dans de nombreuses entreprises, l'accès à Internet se fait via un proxy. En réalité, la machine cliente peut même ne rien savoir, le proxy étant utilisé en mode transparent. Mais cette fonctionnalité doit être intégrée.
• La partie cliente doit être concise et portable.
  Il est clair que pour fonctionner au sein du réseau du Client, on peut installer OpenVPN sur la machine cliente et établir un tunnel complet vers son serveur (d'autant plus que les clients OpenVPN savent travailler à travers des proxy). Cependant, d'une part, cela ne sera pas toujours possible car nous ne sommes pas nécessairement des administrateurs locaux, et d'autre part, cela créera tellement de bruit qu'un système SIEM ou HIPS de qualité nous signalera immédiatement. Idéalement, notre client devrait être ce qu'on appelle une commande en ligne, comme c'est le cas pour beaucoup de shells bash, et s'exécuter via la ligne de commande, par exemple en exécutant des commandes à partir d'un macro Word.
• Notre tunnel doit être multithreadé et supporter plusieurs connexions simultanément.
• La connexion client-serveur doit avoir une forme d'authentification, afin que le tunnel ne soit établi que pour notre client et non pour tous ceux qui viendraient sur notre serveur à l'adresse et au port spécifiés. Idéalement, pour les « utilisateurs externes », une page de destination avec des animaux mignons ou un contenu professionnel en rapport avec le domaine d'origine devrait s'ouvrir.
  Par exemple, si le Client est une organisation médicale, lorsque l'administrateur de la sécurité des informations cherche à vérifier la ressource à laquelle un employé de la clinique a accédé, une page avec des produits pharmaceutiques, un article Wikipedia décrivant le diagnostic ou un blog du docteur Komarovsky devrait s'ouvrir, etc.

Analyse des outils existants

Avant d'inventer notre propre vélo, il est nécessaire d'analyser les vélos existants et de comprendre si cela nous est vraiment nécessaire, et il est probable que nous ne soyons pas les seuls à envisager la nécessité d'un tel vélo fonctionnel.

Une recherche sur Internet (nous recherchons apparemment normalement), ainsi qu'une recherche sur GitHub avec les mots-clés « reverse socks » n'a pas donné beaucoup de résultats. En gros, tout se résume à la création de tunnels SSH avec redirection de ports inversée et tout ce qui y est lié. En plus des tunnels SSH, plusieurs solutions peuvent être mises en avant :

github.com/klsecservices/rpivot
Une ancienne implementation du tunnel inversé par l'équipe de Kaspersky Lab. Le nom indique clairement l'objectif de ce script. Réalisé en Python 2.7, le tunnel fonctionne en mode cleartext (comme on aime à dire aujourd'hui — salut à la RKN)

github.com/tonyseek/rsocks
Une autre implementation en Python, également en cleartext, mais avec plus de fonctionnalités. Écrit sous forme de module et il existe une API pour intégrer la solution dans vos projets.

github.com/llkat/rsockstun
github.com/mis-team/rsockstun
Le premier lien est la version originale de l'implémentation de reverse socks en Golang (non maintenue par le développeur).
Le deuxième lien est notre amélioration avec des fonctionnalités supplémentaires, également en Golang. Dans notre version, nous avons intégré SSL, un fonctionnement via proxy avec authentification NTLM, une authentification côté client, une page de destination en cas de mot de passe incorrect (plutôt un redirection vers la page de destination), un mode multi-threadé (c'est-à-dire que plusieurs personnes peuvent utiliser le tunnel en même temps), un système de ping du client pour vérifier s'il est vivant ou non.

github.com/jun7th/tsocks
Une implémentation de reverse socks de nos « amis chinois » en Python. Pour les paresseux et les « immortels », un binaire prêt à l'emploi (exe), assemblé par les Chinois et prêt à l'utilisation, est également disponible. Ici, seul un dieu chinois sait ce que ce binaire peut contenir d'autre en plus de la fonctionnalité principale, alors utilisez-le à vos risques et périls.

github.com/securesocketfunneling/ssf
Un projet plutôt intéressant en C++ pour l'implémentation de reverse socks et plus encore. En plus du tunnel inversé, il peut faire du transfert de ports, créer un shell commandé, etc.

MSF meterpreter
Ici, comme on dit, sans commentaire. Tous les hackers un peu cultivés connaissent parfaitement cet outil et comprennent à quel point il est facile à détecter par les systèmes de sécurité.

Tous les outils décrits ci-dessus fonctionnent sur une technologie similaire : un module binaire exécutable préparé à l'avance est lancé sur la machine au sein du réseau, établissant une connexion avec un serveur externe. Un serveur SOCKS4/5 est ensuite lancé sur le serveur, acceptant les connexions et les transmettant au client.

Le principal inconvénient de tous ces outils est que soit Python ou Golang doit être installé sur la machine cliente (à quelle fréquence avez-vous rencontré Python installé sur les machines, par exemple, d'un directeur ou d'un employé de bureau ?), soit il faut transporter un binaire déjà compilé sur cette machine (en fait, python et le script dans un seul fichier) et exécuter ce binaire là-bas. Télécharger un exe puis le lancer constitue également une signature pour l'antivirus local ou le HIPS.

En gros, la conclusion s'impose d'elle-même : nous avons besoin d'une solution en PowerShell. À ce moment-là, on va nous jeter des tomates — parce que PowerShell est déjà usé, surveillé, bloqué, etc. En réalité, ce n'est pas le cas partout. Nous affirmons cela avec responsabilité. D'ailleurs, il existe une multitude de moyens pour contourner les blocages (ici encore une phrase à la mode sur le salut au RKN 🙂 ), allant de la simple renommage de powershell.exe en cmdd.exe jusqu'à powerdll, etc.

Commençons à inventer

Évidemment, nous allons d'abord consulter Google et… ne trouver absolument rien sur ce sujet (si quelqu'un a trouvé quelque chose, envoyez les liens dans les commentaires). Il n'y a que implémentation Socks5 en PowerShell, mais c'est un SOCKS « direct » classique, avec un certain nombre de ses inconvénients (nous en parlerons plus tard). Bien sûr, on peut le transformer en inverse d'un simple geste, mais cela ne donnera qu'un SOCKS à un seul thread, ce qui n'est pas tout à fait ce qu'il nous faut.

Donc, nous n'avons rien trouvé de prêt à l'emploi, nous allons devoir inventer notre propre vélo. Pour la base de notre vélo, nous allons prendre notre développement d'un SOCKS inverse en Golang, et nous réaliserons le client pour cela en PowerShell.

RSocksTun
Alors, comment fonctionne rsockstun ?

Au cœur du fonctionnement de RsocksTun (désormais dans le texte — rs) se trouvent deux composants logiciels : Yamux et le serveur Socks5. Le serveur Socks5 est un SOCKS5 local classique, il est lancé sur le client. Le multiplexage des connexions vers celui-ci (rappelez-vous la multithreading ?) est assuré grâce à yamux (yet another multiplexer). Ce schéma permet de lancer plusieurs serveurs socks5 clients et de distribuer les connexions externes à ceux-ci, en les acheminant à travers une seule connexion TCP (presque comme dans meterpreter) du client au serveur, réalisant ainsi un mode multithread, sans lequel nous ne pourrions tout simplement pas fonctionner pleinement dans le réseau interne.

Le principe de fonctionnement de yamux réside dans le fait qu'il introduit un niveau de réseau supplémentaire de flux, le réalisant sous la forme d'un en-tête de 12 octets pour chaque paquet. (Ici, nous utilisons intentionnellement le mot « flux », et non « stream », pour ne pas confondre le lecteur avec le concept de « thread » — ce terme sera également utilisé dans cet article). L'en-tête yamux contient le numéro de flux, des indicateurs pour établir/terminer le flux, la quantité d'octets transmis, et la taille de la fenêtre de transmission.

En plus de l'établissement/termination du flux, yamux a mis en œuvre un mécanisme keepalive, permettant de suivre l'état du canal de communication établi. Le fonctionnement du mécanisme de messages keepalive est configuré lors de la création de la session Yamux. En fait, il n'y a que deux paramètres dans les réglages : activer/désactiver et la fréquence d'envoi des paquets en secondes. Les messages keepalive peuvent être envoyés soit par le serveur yamux, soit par le client yamux. Lors de la réception d'un message keepalive, la partie distante est tenue d'y répondre avec l'envoi d'un identifiant de message exactement identique (en fait, un nombre) à celui qu'elle a reçu. En gros, un keepalive — c'est comme un ping, mais pour yamux.

Tous les détails du fonctionnement du multiplexeur : types de paquets, indicateurs d'établissement et de terminaison des connexions, mécanisme de transmission des données sont décrits dans la spécification le yamux.

Conclusion de la première partie

Ainsi, dans la première partie de l'article, nous avons découvert quelques outils pour organiser des tunnels inversés, examiné leurs avantages et inconvénients, étudié le mécanisme de fonctionnement du multiplexeur Yamux et décrit les exigences principales pour le nouveau module powershell à créer. Dans la prochaine partie, nous nous attacherons à développer le module lui-même, pratiquement, depuis le début. La suite suit. Restez connectés 🙂

Source : habr.com