Une histoire de recherche et développement en 3 parties. La première partie est exploratoire.
Il existe de nombreux hêtres - encore plus d'avantages.
Formulation du problème
Lors des pentests et des campagnes RedTeam, il n’est pas toujours possible d’utiliser les outils standards du Client, tels que VPN, RDP, Citrix, etc. comme point d'ancrage pour entrer dans le réseau interne. Dans certains endroits, un VPN standard fonctionne en utilisant MFA et un jeton matériel est utilisé comme deuxième facteur, dans d'autres, il est brutalement surveillé et notre connexion VPN devient immédiatement visible, comme on dit, avec tout ce que cela implique, mais dans d'autres, il y a tout simplement pas de tels moyens.
Dans de tels cas, nous devons constamment établir ce que l'on appelle des « tunnels inverses » - des connexions du réseau interne vers une ressource externe ou un 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 ces tunnels de retour. Le plus célèbre d’entre eux est bien sûr Meterpreter. Les tunnels SSH avec redirection de port inversée sont également très demandés par les masses de hackers. Il existe de nombreux moyens de mise en œuvre du tunneling inverse et nombre d'entre eux sont bien étudiés et décrits.
Bien entendu, de leur côté, les développeurs de solutions de sécurité ne restent pas à l’écart 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 Positive Tech, et un tunnel SSH inversé peut être détecté par presque n'importe quel pare-feu normal.
Ainsi, pour passer inaperçu dans une bonne campagne RedTeam, il faut construire un tunnel inverse avec des moyens non standards et s'adapter au plus près au mode de fonctionnement réel du réseau.
Essayons de trouver ou d'inventer quelque chose de similaire.
Avant d'inventer quoi que ce soit, nous devons 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 en mode furtif maximum ?
Il est clair que pour chaque cas, ces exigences peuvent différer considérablement, mais sur la base de l'expérience professionnelle, les principales peuvent être identifiées :
- fonctionne sur le système d'exploitation 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 les écoutes stupides en utilisant ips ;
- Lors de la connexion, le client doit prendre en charge le travail via un serveur proxy avec autorisation, car Dans de nombreuses entreprises, l'accès à Internet se fait via un proxy. En fait, la machine cliente peut même n'en savoir rien et le proxy est utilisé en mode transparent. Mais nous devons fournir une telle fonctionnalité ;
- la partie client doit être concise et portable ;
Il est clair que pour travailler au sein du réseau du client, vous pouvez installer OpenVPN sur la machine client et créer un tunnel à part entière vers votre serveur (heureusement, les clients openvpn peuvent fonctionner via un proxy). Mais, premièrement, cela ne fonctionnera pas toujours, car nous ne sommes peut-être pas des administrateurs locaux là-bas, et deuxièmement, cela fera tellement de bruit qu'un SIEM ou HIPS décent nous « dénoncera » immédiatement. Idéalement, notre client devrait être ce qu'on appelle une commande en ligne, car par exemple de nombreux shells bash sont implémentés et lancés via la ligne de commande, par exemple lors de l'exécution de commandes à partir d'une macro Word. - notre tunnel doit être multi-thread et prendre en charge plusieurs connexions simultanément ;
- la connexion client-serveur doit avoir une sorte d'autorisation afin 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, une page de destination avec des chats ou des sujets professionnels liés au domaine d'origine devrait s'ouvrir aux « utilisateurs tiers ».
Par exemple, si le client est une organisation médicale, alors pour un administrateur de la sécurité de l'information qui décide de vérifier la ressource à laquelle un employé de la clinique a accédé, une page contenant des produits pharmaceutiques, Wikipédia avec une description du diagnostic ou le blog du Dr Komarovsky, etc. ... devrait s'ouvrir.
Analyse des outils existants
Avant de réinventer votre propre vélo, vous devez faire une analyse des vélos existants et comprendre si nous en avons vraiment besoin et, probablement, nous ne sommes pas les seuls à avoir réfléchi à la nécessité d'un vélo aussi fonctionnel.
La recherche sur Internet (nous semblons googler normalement), ainsi que la recherche sur Github en utilisant 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 inversée et à tout ce qui y est lié. En plus des tunnels SSH, il existe plusieurs solutions :
Une implémentation de longue date d'un tunnel inversé par les gars de Kaspersky Lab. Le nom indique clairement à quoi ce script est destiné. Implémenté en Python 2.7, le tunnel fonctionne en mode texte clair (comme il est de bon ton de le dire maintenant - bonjour RKN)
Une autre implémentation en Python, également en texte clair, mais avec plus de possibilités. Il est écrit sous forme de module et dispose d'une API pour intégrer la solution dans vos projets.
Le premier lien est la version originale de l'implémentation reverse sox dans Golang (non prise en charge par le développeur).
Le deuxième lien est notre révision avec des fonctionnalités supplémentaires, également en Golang. Dans notre version, nous avons implémenté SSL, travaillé via un proxy avec autorisation NTLM, autorisation sur le client, une page de destination en cas de mot de passe incorrect (ou plutôt une redirection vers la page de destination), un mode multithread (c'est-à-dire plusieurs personnes peut travailler avec le tunnel en même temps), un système de ping du client pour déterminer s'il est vivant ou non.
Implémentation du reverse sox de nos « amis chinois » en Python. Là, pour les paresseux et les « immortels », il existe un binaire (exe) prêt à l'emploi, assemblé par les Chinois et prêt à l'emploi. Ici, seul le 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.
Un projet assez intéressant en C++ pour implémenter reverse sox et plus encore. En plus du tunnel inverse, il peut effectuer une redirection de port, créer un shell de commande, etc.
Compteur MSF
Ici, comme on dit, pas de commentaires. Tous les hackers, même plus ou moins instruits, connaissent très bien cette chose et comprennent avec quelle facilité elle peut être détectée par les outils de sécurité.
Tous les outils décrits ci-dessus fonctionnent selon une technologie similaire : un module binaire exécutable préparé à l'avance est lancé sur une machine à l'intérieur du réseau, qui établit une connexion avec un serveur externe. Le serveur exécute un serveur SOCKS4/5 qui accepte les connexions et les relaie vers le client.
L'inconvénient de tous les outils ci-dessus est que soit Python, soit Golang doivent être installés sur la machine client (avez-vous souvent vu Python installé sur les machines, par exemple, d'un chef d'entreprise ou d'employés de bureau ?), ou un logiciel pré-assemblé. le binaire (en fait python) doit être glissé sur cette machine et le script dans une bouteille) et exécuter ce binaire déjà là. Et télécharger un exe puis le lancer est aussi une signature pour un antivirus local ou HIPS.
En général, la conclusion s'impose : nous avons besoin d'une solution PowerShell. Maintenant, les tomates vont voler vers nous - ils disent que PowerShell est déjà tout éculé, il est surveillé, bloqué, etc. et ainsi de suite. En fait, pas partout. Nous déclarons de manière responsable. À propos, il existe de nombreuses façons de contourner le blocage (là encore, il y a une phrase à la mode sur bonjour RKN 🙂), en commençant par le changement de nom stupide de powershell.exe -> cmdd.exe et en terminant par powerdll, etc.
Commençons à inventer
C’est clair qu’on va d’abord chercher sur Google et… on ne trouvera rien sur ce sujet (si quelqu’un l’a trouvé, mets les liens dans les commentaires). Il n'y a que Chaussettes5 sur PowerShell, mais il s'agit d'un sox "direct" ordinaire, qui présente un certain nombre d'inconvénients (nous en reparlerons plus tard). Vous pouvez, bien sûr, d'un léger mouvement de la main, le transformer en inverse, mais ce ne sera que du sox à un seul fil, ce qui n'est pas tout à fait ce dont nous avons besoin.
Nous n’avons donc rien trouvé de tout fait, il va donc falloir réinventer la roue. Nous prendrons comme base pour notre vélo reverse sox dans Golang, et nous implémentons un client pour cela dans PowerShell.
RSocksTun
Alors, comment fonctionne le rsockstun ?
Le fonctionnement de RsocksTun (ci-après dénommé rs) est basé sur deux composants logiciels : le serveur Yamux et Socks5. Le serveur Chaussettes5 est un chaussettes5 local classique, il s'exécute sur le client. Et le multiplexage des connexions (vous vous souvenez du multithreading ?) est assuré à l'aide de yamux (). Ce schéma vous permet de lancer plusieurs serveurs clients chaussettes5 et de leur distribuer des connexions externes, en les transmettant via une seule connexion TCP (presque comme dans Meterpreter) du client au serveur, implémentant ainsi un mode multithread, sans lequel nous ne serons tout simplement pas capable de travailler pleinement dans les réseaux internes.
L'essence du fonctionnement de yamux est qu'il introduit une couche réseau supplémentaire de flux, en l'implémentant sous la forme d'un en-tête de 12 octets pour chaque paquet. (Ici, nous utilisons délibérément le mot « flux » plutôt que thread, afin de ne pas confondre le lecteur avec un flux de programme « thread » - nous utiliserons également ce concept dans cet article). L'en-tête yamux contient le numéro du flux, les indicateurs d'installation/termination du flux, le nombre d'octets transférés et la taille de la fenêtre de transfert.
En plus d'installer/terminer un flux, yamux implémente un mécanisme keepalive qui vous permet de surveiller les performances du canal de communication établi. Le fonctionnement du mécanisme de message keeplive est configuré lors de la création d'une session Yamux. En fait, parmi les paramètres, il n'y a que deux paramètres : activer/désactiver et la fréquence d'envoi des paquets en secondes. Les messages Keepalive peuvent être envoyés par un serveur Yamux ou un client Yamux. Lors de la réception d'un message keepalive, la partie distante doit y répondre en envoyant exactement le même identifiant de message (en fait un numéro) que celui qu'elle 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 : types de paquets, drapeaux d'établissement et de terminaison de connexion, ainsi que le mécanisme de transfert de données sont décrits en détail dans à Yamux.
Conclusion de la première partie
Ainsi, dans la première partie de l'article, nous nous sommes familiarisés avec quelques 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 pour le module PowerShell nouvellement créé. Dans la prochaine partie, nous développerons le module lui-même, pratiquement à partir de zéro. À suivre. Ne changez pas :)
Source: habr.com