Introduction
Lors de tests d'intrusion ou d'opérations de red teaming, il arrive souvent que vous compromettiez un serveur exposé sur Internet et découvriez qu'il possède un accès à un réseau interne inaccessible directement depuis votre machine d'attaque. Pour attaquer ces systèmes internes, vous devez trouver un moyen d'acheminer votre trafic via le serveur compromis. Cette technique est appelée "pivotage" (pivoting).
Le pivotage consiste essentiellement à changer de point de vue. Vous ne testez plus uniquement depuis la position réseau de votre machine d'origine ; vous utilisez un hôte compromis comme nouveau point d'observation et d'accès.
L'une des techniques de pivotage les plus puissantes et les plus courantes consiste à utiliser le transfert de port dynamique SSH pour créer un proxy SOCKS, combiné à un outil appelé proxychains. Cette combinaison vous permet d'acheminer presque n'importe quel outil réseau externe (comme Nmap, Nikto ou Metasploit) de manière transparente via l'hôte compromis.
Dans ce laboratoire, nous simulerons un scénario où vous disposez d'un accès SSH à un hôte pivot exécuté dans un conteneur Docker. Un second conteneur, situé sur le même réseau Docker privé, héberge un service web interne masqué. Ce service n'étant pas exposé directement à la machine virtuelle LabEx, vous devez l'atteindre via l'hôte pivot SSH. Vous apprendrez à configurer un transfert de port dynamique SSH, à paramétrer proxychains et à l'utiliser pour accéder à ce service masqué.
Configurer le transfert de port dynamique SSH (-D)
Dans cette étape, vous allez établir une connexion SSH vers l'hôte pivot conteneurisé et créer un proxy SOCKS local.
Le transfert de port dynamique vous permet de spécifier un port local sur votre machine d'attaque. Le client SSH écoute sur ce port, et chaque fois qu'une application s'y connecte, la connexion est transmise via le canal SSH sécurisé vers le serveur SSH. Le serveur SSH agit alors comme un proxy, transférant le trafic vers sa destination finale.
Cette méthode est plus flexible que le transfert de port unique, car le proxy SOCKS peut acheminer de nombreuses requêtes de destination différentes via un seul tunnel.
Pour configurer cela, nous utilisons l'option -D dans notre commande SSH. Nous utiliserons également quelques autres options pour assurer le bon fonctionnement de la connexion en arrière-plan.
L'environnement a généré une clé privée pour vous dans ~/project/pivot_key et a exposé le service SSH de l'hôte pivot sur le port local 2222. Exécutez la commande suivante dans votre terminal pour créer un proxy SOCKS sur le port local 9050 :
ssh -f -D 9050 -q -C -N \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-i ~/project/pivot_key -p 2222 pivot@127.0.0.1
Analysons les options utilisées dans cette commande. L'option -D 9050 spécifie le transfert de port dynamique et définit le port d'écoute local sur 9050. L'option -q active le mode silencieux, supprimant les messages d'avertissement et de diagnostic. L'option -C demande la compression de toutes les données, ce qui peut accélérer la connexion. L'option -N indique à SSH de ne pas exécuter de commande distante, ce qui est utile lorsque vous ne faites que transférer des ports. L'option -f envoie le client SSH en arrière-plan après l'authentification, vous permettant de continuer à utiliser la même session de terminal. Les options -o StrictHostKeyChecking=no et -o UserKnownHostsFile=/dev/null évitent que les invites de confirmation de clé d'hôte lors de la première connexion n'interrompent le flux de travail du laboratoire. L'option -i indique à SSH quelle clé privée utiliser, et -p 2222 lui indique de se connecter au conteneur de l'hôte pivot plutôt qu'au service SSH par défaut de la machine virtuelle LabEx.
Après avoir exécuté la commande, vous pouvez vérifier que le port est ouvert et en écoute en utilisant la commande ss, qui affiche les statistiques des sockets.
ss -tuln | grep 9050
Vous devriez obtenir un résultat similaire à celui-ci, indiquant que votre machine écoute désormais sur le port 9050 :
tcp LISTEN 0 128 127.0.0.1:9050 0.0.0.0:*
tcp LISTEN 0 128 [::1]:9050 [::]:*
Configurer Proxychains (/etc/proxychains.conf)
Dans cette étape, vous allez examiner la configuration de proxychains.
Bien que vous ayez maintenant un proxy SOCKS fonctionnant sur le port 9050, la plupart des outils en ligne de commande (comme Nmap) ne savent pas nativement comment acheminer leur trafic via un proxy SOCKS. C'est là qu'intervient proxychains. Il s'agit d'un outil qui force toute connexion TCP effectuée par une application donnée à passer par un proxy.
En pratique, proxychains est ce qui permet d'étendre le tunnel d'un test manuel vers un flux de travail opérationnel réutilisable sur de nombreux outils.
Le fichier de configuration de proxychains se trouve dans /etc/proxychains4.conf. Pour ce laboratoire, l'entrée du proxy doit pointer vers un proxy SOCKS5 sur 127.0.0.1 port 9050, ce qui correspond au transfert de port dynamique SSH que nous venons de créer.
Visualisons la fin du fichier de configuration pour confirmer ce paramètre. Utilisez la commande tail pour afficher les 10 dernières lignes du fichier :
tail -n 10 /etc/proxychains4.conf
Vous devriez voir une sortie similaire à la suivante :
[ProxyList]
## add proxy here ...
## meanwile
## defaults set to "tor"
socks5 127.0.0.1 9050
La section [ProxyList] est l'endroit où les proxies sont définis. La ligne socks5 127.0.0.1 9050 indique à proxychains d'acheminer le trafic via le port local 9050. Comme notre commande SSH -D a créé un proxy sur ce port précis, aucune configuration supplémentaire n'est nécessaire après la mise à jour du type de protocole.
Si vous avez besoin d'utiliser un port différent ou un type de proxy différent, vous devrez modifier ce fichier à l'aide d'un éditeur de texte comme nano.
Tester le proxy SOCKS
Dans cette étape, vous allez vérifier si votre configuration de proxy fonctionne correctement en accédant au service web interne masqué.
Rappelez-vous qu'il existe un service web en cours d'exécution sur un conteneur interne masqué à l'adresse 172.30.0.20:80. Dans un scénario réel, cela représente un site intranet interne qui ne peut pas être accédé directement depuis l'Internet public.
Pour utiliser proxychains, il suffit de faire précéder la commande de proxychains4. Utilisons curl pour récupérer la page web.
Exécutez la commande suivante :
proxychains4 curl http://172.30.0.20
Lorsque vous exécutez cette commande, proxychains intercepte la requête réseau effectuée par curl et la tunnelise via le proxy SOCKS SSH sur le port 9050. L'hôte pivot effectue ensuite la requête vers 172.30.0.20:80 sur le réseau Docker interne et renvoie le résultat.
Vous devriez voir une sortie similaire à celle-ci :
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Secret Internal Data: You have successfully pivoted
Le message OK indique que la connexion au proxy a réussi, et la dernière ligne affiche les données secrètes provenant du serveur web interne.
Exécuter des outils externes via le pivot
Dans cette dernière étape, vous utiliserez un outil externe plus avancé, Nmap, pour scanner le réseau interne via votre pivot établi.
Lors de l'utilisation de proxychains avec Nmap, il existe des limitations techniques importantes à comprendre. Les proxies SOCKS ne prennent en charge que les connexions TCP complètes. Ils ne supportent pas l'ICMP (ping) ou les scans SYN semi-ouverts (que Nmap utilise par défaut lorsqu'il est exécuté avec sudo).
Par conséquent, lors de l'exécution de Nmap via proxychains, vous devez le forcer à utiliser un scan TCP Connect complet et désactiver la découverte par ping.
Exécutez la commande Nmap suivante pour scanner le service web interne sur le port 80 :
proxychains4 nmap -sT -Pn -p 80 172.30.0.20
Analysons les options Nmap utilisées ici. L'option -sT force un scan TCP Connect, ce qui est obligatoire car les proxies SOCKS ne peuvent pas gérer les paquets bruts ou les scans SYN. L'option -Pn désactive la découverte d'hôte (ping) ; comme les proxies SOCKS ne peuvent pas acheminer les requêtes d'écho ICMP, Nmap supposerait à tort que l'hôte est hors ligne si cette option était omise. Enfin, l'option -p 80 spécifie le port exact à scanner.
Vous verrez proxychains enregistrer les tentatives de connexion, suivies des résultats du scan Nmap :
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.14
Starting Nmap 7.91 ( https://nmap.org ) at 2024-01-01 12:00 UTC
[proxychains] Strict chain ... 127.0.0.1:9050 ... 172.30.0.20:80 ... OK
Nmap scan report for 172.30.0.20
Host is up (0.0020s latency).
PORT STATE SERVICE
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
Cela confirme que vous pouvez acheminer avec succès des outils de sécurité complexes via un hôte compromis pour interagir avec des segments de réseau internes.
Résumé
Félicitations ! Vous avez terminé avec succès le laboratoire sur le transfert de port dynamique avec Proxychains.
Dans ce laboratoire, vous avez appris à créer un proxy SOCKS local en utilisant le transfert de port dynamique SSH (-D). Vous avez également appris à comprendre et à inspecter la configuration de proxychains. De plus, vous avez acheminé avec succès des requêtes HTTP de base via le proxy pour accéder à des services internes masqués. Enfin, vous avez adapté des outils de scan avancés comme Nmap pour fonctionner via un proxy SOCKS en utilisant des scans TCP Connect (-sT) et en désactivant la découverte par ping (-Pn).
Ces techniques de pivotage sont des compétences essentielles pour naviguer dans des environnements réseau complexes lors de tests d'intrusion et d'évaluations de sécurité.
