L'histoire de la recherche et du développement en 3 parties. Partie 1 - recherche.
Il existe de nombreux hêtres - encore plus d'avantages.
Énoncé du problème
Lors de la conduite de pentests et de campagnes RedTeam, il n'est pas toujours possible d'utiliser les moyens habituels des clients, tels que VPN, RDP, Citrix, etc. comme un correctif pour entrer dans le réseau interne. Quelque part, un VPN ordinaire fonctionne selon MFA et un jeton de fer est utilisé comme deuxième facteur, quelque part il est sévèrement surveillé et notre entrée VPN devient immédiatement visible, comme on dit - avec toutes les conséquences, mais quelque part il n'y a tout simplement pas de tels moyens.
Dans de tels cas, doivent constamment faire ce que l'on appelle les «tunnels inverses» - les connexions du réseau interne à une ressource externe ou au serveur que nous contrôlons. À l'intérieur d'un tel tunnel, nous pouvons déjà travailler avec les ressources internes des clients.
Il existe plusieurs variétés de tels tunnels inverses. Le plus célèbre d'entre eux, bien sûr, est Meterpreter. Les tunnels SSH avec redirection de port inverse sont également très demandés par les masses de pirates. Il existe de nombreux outils de tunneling inverse et beaucoup d'entre eux sont bien étudiés et décrits.
Bien entendu, les développeurs de solutions de protection ne sont pas en reste et détectent activement de telles actions.
Par exemple, les sessions MSF sont détectées avec succès par les IPS modernes de Cisco ou de Positive Tech, et le tunnel SSH inversé peut être détecté par presque tout pare-feu plus ou moins normal.
Par conséquent, afin de passer inaperçu dans une bonne campagne RedTeam, nous devons construire un tunnel inverse avec des moyens non standard et nous adapter le plus possible au mode réel du réseau.
Essayons de trouver ou d'inventer quelque chose de similaire.
Avant d'inventer quelque chose, vous devez comprendre quel résultat nous voulons atteindre, quelles fonctions notre développement doit remplir. Quelles seront les exigences pour le tunnel afin que nous puissions travailler en mode furtif maximum?
Il est clair que pour chaque cas, ces exigences peuvent différer considérablement, mais l'expérience nous permet de distinguer les principales:
- travailler sur OS Windows-7-10. Étant donné que la plupart des réseaux d'entreprise utilisent Windows;
- le client se connecte au serveur via SSL pour éviter une écoute stupide en utilisant ips;
- lors de la connexion, le client doit prendre en charge le fonctionnement via un serveur proxy avec autorisation, comme De nombreuses entreprises accèdent à Internet via un proxy. En fait, la machine cliente n'en sait peut-être même rien et le proxy est utilisé en mode transparent. Mais nous devons établir une telle fonctionnalité;
- la partie client doit être concise et portable;
Il est clair que pour travailler à l'intérieur du réseau du client sur la machine cliente, vous pouvez installer OpenVPN et créer un tunnel à part entière vers votre serveur (car les clients openvpn peuvent fonctionner via des proxys). Mais, d'une part, cela ne fonctionne pas toujours, car nous ne sommes peut-être pas des administrateurs locaux, et d'autre part, cela fera tellement de bruit qu'un SIEM ou un HIPS décents «nous frapperont» immédiatement. Idéalement, notre client devrait être une soi-disant commande en ligne, par exemple, de nombreux shells bash sont implémentés et exécutent la ligne de commande, par exemple, lors de l'exécution de commandes à partir d'une macro de mot. - notre tunnel doit être multithread et prendre en charge de nombreuses connexions en même temps;
- la connexion client-serveur doit avoir une sorte d'autorisation pour que le tunnel soit établi uniquement pour notre client, et non pour tous ceux qui viennent sur notre serveur à l'adresse et au port spécifiés. Idéalement, pour les «utilisateurs tiers», une page de destination avec des sceaux ou des sujets professionnels liés au domaine source devrait s'ouvrir.
Par exemple, si le client est une organisation médicale, alors pour l'administrateur de la sécurité de l'information qui a décidé de vérifier la ressource que l'employé de la clinique a utilisée, une page avec des produits pharmaceutiques, un wikipedia avec une description du diagnostic, ou un blog du Dr Komarovsky, etc. devrait s'ouvrir.
Analyse des outils existants
Avant d'inventer votre vélo, vous devez analyser les vélos existants et comprendre si nous en avons vraiment besoin et, probablement, non seulement nous avons pensé à la nécessité d'un tel vélo fonctionnel.
La recherche sur Internet (nous semblons être d'accord avec Google), ainsi que la recherche dans le github pour les mots clés "chaussettes inversées", n'ont pas donné beaucoup de résultats. Fondamentalement, tout se résume à la construction de tunnels ssh avec redirection de port inverse et tout ce qui y est connecté. En plus des tunnels SSH, plusieurs solutions peuvent être distinguées:
github.com/klsecservices/rpivotUne implémentation de longue date du tunnel inverse des gars de Kaspersky Lab. Par son nom, il est clair à quoi sert ce script. Mis en œuvre en Python 2.7, le tunnel fonctionne en mode texte clair (comme il est à la mode de dire maintenant - bonjour à ILV)
github.com/tonyseek/rsocksUne autre implémentation de python est également en texte clair, mais il y a plus d'options. Il est écrit sous forme de module et il existe une API pour intégrer la solution dans vos projets.
github.com/llkat/rsockstungithub.com/mis-team/rsockstunLe premier lien est la version initiale de l'implémentation de Sox inversé sur le Golang (non pris en charge par le développeur).
Le deuxième lien est déjà notre révision avec des puces supplémentaires, également sur le golang. Dans notre version, nous avons implémenté SSL, travaillé via un proxy avec l'autorisation NTLM, l'autorisation client, une page de destination avec un mot de passe incorrect (ou plutôt une redirection vers une page de destination), le mode multi-thread (c'est-à-dire que plusieurs personnes peuvent travailler avec le tunnel en même temps) , un système de ping client pour savoir s'il est vivant ou non.
github.com/jun7th/tsocksImplémentation Reverse Sox de nos «amis chinois» en python. Là pour le paresseux et "immortel" se trouve le binar prêt à l'emploi (exe), assemblé par les Chinois et prêt à l'emploi. Ici, seul le dieu chinois sait qu'il peut y avoir plus que la fonctionnalité principale de ce binaire, alors utilisez-le à vos risques et périls.
github.com/securesocketfunneling/ssfUn projet C ++ assez intéressant pour implémenter des chaussettes inversées et plus En plus du tunnel inverse, il peut faire une redirection de port, créer un shell de commande, etc.
Msf meterpreterIci, comme on dit, aucun commentaire. Tous les hackers plus ou moins éduqués connaissent très bien cette chose et comprennent avec quelle facilité elle peut être détectée par un équipement de protection.
Tous les outils ci-dessus fonctionnent sur une technologie similaire: sur une machine à l'intérieur du réseau, un module binaire exécutable pré-préparé est lancé, qui établit une connexion à un serveur externe. Le serveur démarre le serveur SOCKS4 / 5, qui accepte les connexions et les traduit au client.
L'inconvénient de tous les outils ci-dessus est que Python ou Golang est requis sur la machine cliente (avez-vous souvent vu Python installé sur des machines, par exemple, des chefs d'entreprise ou des employés de bureau?), Ou vous devez faire glisser un binaire pré-assemblé sur cette machine (en fait python et le script dans une bouteille) et exécutez ce binaire déjà là. Et le téléchargement d'exe avec son lancement ultérieur est également la signature d'un antivirus local ou HIPS.
En général, la conclusion se suggère - nous avons besoin d'une solution sur PowerShell. Maintenant, les tomates vont nous voler - disent-ils PowerShell - tout est battu, il est surveillé, bloqué, etc. etc. En fait - pas partout. Nous déclarons de manière responsable. Soit dit en passant, il existe de nombreuses façons de contourner les verrous (ici encore la phrase à la mode à propos de bonjour à l'ILV :)), à partir du renommage stupide de powershell.exe -> cmdd.exe et se terminant par powerdll, etc.
Commencez à inventer
Il est clair que nous allons d'abord google et ... nous ne trouverons rien sur ce sujet (si quelqu'un a trouvé, jetez des liens vers les commentaires). Il n'y a qu'une
implémentation de Socks5 sur PowerShell, mais c'est le Sox «direct» habituel, qui a un certain nombre d'inconvénients (nous en parlerons plus tard). Vous pouvez, bien sûr, le transformer en marche arrière avec un coup de poignet, mais ce ne sera qu'un Sox à filetage unique, ce qui n'est pas exactement ce dont nous avons besoin.
Donc, nous n'avons rien trouvé de prêt, il nous reste donc à inventer notre vélo. Nous prendrons
notre développement de chaussettes inversées sur le golang comme base de notre vélo, et nous mettrons en œuvre le client pour celui-ci sur PowerShell.
RSocksTunAlors, comment fonctionne rsockstun?
Au cœur du travail de RsocksTun (ci-après dénommé rs) se trouvent deux composants logiciels - Yamux et Socks5 server. Le serveur Socks5 est un socks5 local régulier, il s'exécute sur le client. Et le multiplexage des connexions (rappelez-vous du multithreading?) Est fourni à l'aide de yamux (
encore un autre multiplexeur ). Ce schéma vous permet d'exécuter plusieurs serveurs client socks5 et de leur distribuer des connexions externes, en les transférant via une seule connexion TCP (presque comme dans meterpreter) du client vers le serveur, réalisant ainsi le mode multi-thread, sans lequel nous ne pouvons tout simplement pas travailler pleinement en interne réseau.
L'essence de yamux est qu'il introduit un niveau réseau supplémentaire de flux, le réalisant comme un en-tête de 12 octets pour chaque paquet. (Ici, nous utilisons intentionnellement le mot «stream», pas un stream, afin de ne pas confondre le lecteur avec le thread de programme «thread» - ce concept que nous utiliserons également dans cet article). À l'intérieur de l'en-tête yamux contient le numéro de flux, les drapeaux pour définir / terminer le flux, le nombre d'octets transférés, la taille de la fenêtre de transfert.
En plus d'installer / compléter le flux, yamux implémente un mécanisme keepalive qui vous permet de surveiller la santé du canal de communication installé. Le mécanisme des messages keeplive est configuré lors de la création d'une session Yamux. En fait, à partir des paramètres, il n'y a que deux paramètres: activer / désactiver et la fréquence d'envoi des paquets en quelques secondes. Le serveur yamux peut envoyer des messages keepalive, donc le client yamux le peut. Lors de la réception d'un message keepalive, le correspondant distant est obligé d'y répondre en envoyant exactement le même identifiant de message (en fait un numéro) qu'il a reçu. En général, keepalive est le même ping, uniquement pour yamux.
L'ensemble de la technique de fonctionnement du multiplexeur est détaillé: types de paquets, drapeaux d'installation et de terminaison, mécanisme de transfert de données est décrit dans
la spécification yamux.
Conclusion de la première partie
Ainsi, dans la première partie de l'article, nous nous sommes familiarisés avec certains outils d'organisation des tunnels inverses, avons examiné leurs avantages et leurs inconvénients, étudié le mécanisme de fonctionnement du multiplexeur Yamux et décrit les exigences de base du module PowerShell nouvellement créé. Dans la partie suivante, nous développerons le module lui-même, pratiquement, à partir de zéro. À suivre. Ne changez pas :)