⏩Port forwarding
Dans les réseaux réels, les administrateurs peuvent avoir bloqué certains de ces ports pour des raisons de sécurité ou avoir mis en place une segmentation autour du réseau, vous empêchant d'atteindre SMB., RDP, Ports WinRM ou RPC.
Pour contourner ces restrictions, nous pouvons utiliser des techniques de redirection de port, qui consistent à utiliser tout hôte compromis comme une boîte de saut pour pivoter vers d'autres hôtes.
On a déjà une machine intermediaire, pourquoi ne pas l'utiliser ?
Tout simplement car on a pas tout nos outils dessus
😃 SSH - REMOTE et LOCAL
Redirection de port via une fonctionnalité appelée SSH Tunneling.
Windows est désormais livré avec le client OpenSSH par défaut
Nous avons :
Attaquant : ne peut pas se connecter au port cible (a cause de restriction, parefeu par exemple)
Intermediaire : autorise a se se connecter au port cible
La cible
Configuration
Sur l'attaquant, commencez par créer un nouvel utilisateur avec des privilèges limités pour le SSH tunneling :
sudo useradd tunneluser -m -d /home/tunneluser -s /bin/bash
sudo passwd tunneluserModifiez ensuite le fichier /etc/ssh/sshd_config sur l'attaquant pour autoriser le port forwarding et limiter l'accès de l'utilisateur tunneluser :
sudo nano /etc/ssh/sshd_configAjoutez les lignes suivantes à la fin du fichier :
Match User tunneluser
AllowTcpForwarding yes
X11Forwarding no
ForceCommand /bin/bashEnregistrez le fichier et redémarrez le service SSH :
sudo systemctl restart sshAvec le remote port forwarding, la redirection est configurée depuis la machine distante vers la machine locale.
Cela signifie que le trafic réseau qui arrive sur un port spécifique de la machine distante est redirigé vers un port spécifique sur la machine locale via une connexion SSH.
La machine distante accède à un service sur votre machine locale via un tunnel SSH sécurisé
Exemple avec RDP - port : 3389
Sur l'intermédiaire connectez-vous au serveur SSH de l'attaquant (IP_attaquant) en utilisant le port forwarding :
ssh -R <port_intermediaire>:<IP_CIBLE>:3389 user_attack@IP_ATTACK -NAssurez-vous de remplacer <port_intermediaire> par le port sur lequel l'intermédiaire écoute les connexions entrantes pour rediriger le trafic RDP vers la machine cible (par exemple, 8080).
-N : Ne pas exécuter de commandes distantes après la connexion. Cela est utile lorsque vous ne souhaitez pas exécuter de commandes spécifiques après l'établissement du tunnel SSH.
Vérification du Port Forwarding sur l'Attaquant
Une fois le tunnel SSH établi, sur l'attaquant, vérifiez que le port forwarding fonctionne :
netstat -tuln | grep <port_intermediaire>Assurez-vous de remplacer <port_intermediaire> par le port que vous avez spécifié lors de la configuration du port forwarding distant (par exemple, 8080). Vous devriez voir une ligne indiquant que le port spécifié est à l'écoute sur l'adresse IP locale (127.0.0.1).
Connexion à la Machine Cible via RDP
Utilisez un client RDP tel que xfreerdp pour vous connecter à l'ordinateur cible via le port forwarding distant :
xfreerdp /v:127.0.0.1:<port_intermediaire> /u:admin /p:<mot_de_passe_admin>Remplacez <port_intermediaire> par le port que vous avez spécifié lors de la configuration du port forwarding distant (par exemple, 8080).
Cela devrait vous permettre de vous connecter à la machine cible via RDP en utilisant le port forwarding distant SSH que vous avez configuré.
la redirection est configurée depuis la machine locale vers une machine distante.
Cela signifie que le trafic réseau qui arrive sur un port spécifique de la machine locale est redirigé vers un port spécifique sur une machine distante via une connexion SSH.
vous permet d'accéder à un service sur une machine distante via un tunnel SSH sécurisé, en redirigeant le trafic vers un port sur votre machine locale.
Depuis l'attaquant :
<port_local>est le port sur votre machine locale (l'attaquant) que vous voulez utiliser pour accéder au service ou à l'application sur la machine distante (la cible).<port_cible>est le port sur la machine distante (la cible) sur lequel le service ou l'application est en cours d'exécution.L'option
-Nest utilisée pour ne pas exécuter de commandes distantes après la connexion. Cela est utile lorsque vous ne souhaitez pas exécuter de commandes spécifiques après l'établissement du tunnel SSH.
Connexion à la Machine Cible via RDP :
Une fois que le port forwarding est configuré, vous pouvez vous connecter à la machine cible via RDP depuis votre machine locale (l'attaquant) en utilisant un client RDP tel que xfreerdp :
Règle de pare-feu pour l'ouverture d'un port :
Pour ouvrir un port sur le pare-feu Windows, exécutez la commande suivante sur l'intermédiaire (Windows) :
Assurez-vous de remplacer <port_local> par le port que vous avez spécifié lors de la configuration du port forwarding local.
😁 SSH - Dynamic porforwarding et SOCKS proxy
😆 Portforwarding Dynamique
Contrairement au port forwarding local ou distant, qui redirigent le trafic d'un port spécifique vers une destination spécifique, le port forwarding dynamique crée un proxy SOCKS sur le port local de l'ordinateur client. Ce proxy SOCKS peut être utilisé pour rediriger le trafic de n'importe quelle application réseau à travers le tunnel SSH vers diverses destinations sur Internet.
Avec le port forwarding dynamique, vous n'avez pas besoin de spécifier une destination spécifique au moment de la configuration. Au lieu de cela, vous configurez simplement un proxy SOCKS sur votre machine locale, et tout le trafic envoyé à ce proxy est redirigé à travers le tunnel SSH vers la destination souhaitée.
😊 SOCKS (Socket Secure)
SOCKS est un protocole de communication réseau utilisé pour le transfert de données entre un client et un serveur à travers un proxy. Il est utilisé pour traverser les pare-feu et les routeurs qui peuvent bloquer le trafic direct.
Fonctionnement :
Client : L'application cliente se connecte au serveur proxy SOCKS.
Proxy SOCKS : Le serveur proxy relaye le trafic entre le client et la destination finale. Il agit comme intermédiaire pour masquer l'adresse IP du client.
Destination : La destination finale reçoit le trafic comme si c'était directement du serveur proxy.
👿 Proxy Chains
Les proxy chains (chaînes de proxys) impliquent l'utilisation de plusieurs proxys en série pour masquer davantage l'origine du trafic et ajouter des couches de protection.
Fonctionnement :
Configuration : Les adresses des serveurs proxy sont listées dans un fichier de configuration.
Relais en chaîne : Le trafic du client passe successivement par chaque proxy dans la chaîne avant d'atteindre la destination finale.
Sécurité : Chaque proxy ne connaît que l'adresse IP de l'hôte précédent et de l'hôte suivant dans la chaîne, rendant difficile pour un observateur de tracer l'origine du trafic.
🗝️ Explication Pratique
Imaginons un attaquant qui a compromis une machine dans un réseau interne et souhaite accéder à d'autres machines sans éveiller les soupçons :
Portforwarding Dynamique : L'attaquant utilise la commande suivante pour établir un tunnel SSH vers la machine compromise et activer un proxy SOCKS local sur le port 1080.
SOCKS Proxy : Le navigateur de l'attaquant est configuré pour utiliser le proxy SOCKS à
localhost:1080.Proxy Chains : L'attaquant utilise
proxychainspour relayer son trafic à travers plusieurs proxys avant d'atteindre la machine cible, compliquant ainsi la détection et la traçabilité.
✏️ Démonstration
Étape 1 : Établir une redirection de port dynamique inverse depuis la machine de l'attaquant
Depuis la machine de l'attaquant, nous allons utiliser le client SSH pour établir une redirection de port dynamique inverse avec la commande suivante :
-f: en arrière-plan une fois que la connexion est établie.-N: pas exécuter de commandes distantes une fois la connexion établie. Cela signifie que SSH sera utilisé uniquement pour établir le tunnel et restera actif sans exécuter de commandes supplémentaires.Port 9050par défaut
Étape 2 : Configurer proxychains sur la machine de l'attaquant
Sur la machine de l'attaquant, modifiez le fichier de configuration de proxychains (/etc/proxychains.conf) pour utiliser le proxy SOCKS sur le port 9050 (ou celui défini lors de l'étape précédente) :
Étape 3 : Utiliser proxychains pour établir des connexions vers la machine cible
Maintenant que nous avons mis en place un tunnel de port dynamique (qui redirige le trafic via SSH) et configuré proxychains (qui gère une série de proxys), nous pouvons utiliser nos outils de manière sécurisée. Ces outils enverront leur trafic à travers le proxy SOCKS, qui, à son tour, passera par plusieurs proxys pour masquer l'origine du trafic et rendre sa détection plus difficile.
Par exemple, si nous voulons maintenant exécuter une commande via le proxy pour accéder à la machine cible (IP_cible), nous pouvons utiliser la commande suivante :
ou
Notez que certains logiciels comme nmap peuvent ne pas fonctionner correctement avec SOCKS dans certaines circonstances et peuvent afficher des résultats modifiés, votre kilométrage peut donc varier.
🗳️ SOCAT
Pour commencer, vous devez avoir Socat installé sur les trois machines : la machine cible, la machine intermédiaire et la machine de l'attaquant.
Redirection de trafic RDP
Sur Intermediaire :
TCP-LISTEN:8080indique à Socat d'écouter les connexions entrantes sur le port 13389.forkpermet à Socat de gérer les connexions entrantes de manière séparée pour chaque client.TCP:Cible:3389spécifie que Socat redirige le trafic vers l'adresse IP de la Cible sur le port 3389, qui est le port RDP par défaut.
Connexion à la Machine Cible via RDP :
Sur Attaquant :
Vérification sur l'Attaquant
Une fois le tunnel SSH établi, sur l'attaquant, vérifiez que le port forwarding fonctionne 👍
Redirection de trafic d'un port spécifique
Dans ce cas précis, l'objectif est de rediriger le trafic du port 8080 de l'attaquant vers le port 80 de l'intermédiaire, puis du port 80 de l'intermédiaire vers le port 80 de la cible. Cela permet à l'attaquant d'accéder à un service ou une application hébergé sur la machine cible, même si elle est initialement inaccessible depuis l'attaquant en raison de restrictions réseau.
De l'attaquant vers l'intermédiaire
Depuis la machine de l'attaquant, vous pouvez utiliser la commande suivante pour rediriger le trafic du port 8080 vers la machine intermédiaire :
TCP-LISTEN:8080: Écoute sur le port 8080 de la machine de l'attaquant.fork: Crée une nouvelle instance de Socat pour chaque connexion entrante.TCP:IP_intermediaire:80: Redirige le trafic vers le port 80 de la machine intermédiaire.
De l'intermédiaire vers la cible
Depuis la machine intermédiaire, vous pouvez utiliser la commande suivante pour rediriger le trafic du port 8080 vers la machine cible :
TCP-LISTEN:8080: Écoute sur le port 8080 de la machine intermédiaire.fork: Crée une nouvelle instance de Socat pour chaque connexion entrante.TCP:IP_cible:80: Redirige le trafic vers le port 80 de la machine cible.
Vérification de la redirection de port
Depuis la machine de l'attaquant, vous pouvez maintenant accéder à la machine cible en utilisant l'adresse IP de la machine intermédiaire. Par exemple, si vous avez redirigé le port 8080, vous pouvez ouvrir un navigateur web et accéder à http://IP_intermediaire:8080. Le trafic sera redirigé vers le port 80 de la machine cible.
🛠️ Ports Intéressants
Administration à Distance
Port 22 (SSH)
Port 3389 (RDP)
Port 5900 (VNC)
Accès aux Services Web
Port 80 (HTTP)
Port 443 (HTTPS)
Partage de Fichiers
Port 445 (SMB)
Accès aux Bases de Données
Port 1433 (SQL Server)
Port 3306 (MySQL)
Lors de mouvements latéraux et de l'utilisation de port forwarding, les attaquants ouvrent certains ports sur leur propre machine pour écouter les connexions entrantes. Voici une liste des ports couramment utilisés et les raisons pour lesquelles ils sont choisis :
1. Port 8080 (HTTP Alternative)
Utilisation : Pour rediriger le trafic web alternatif.
Pourquoi :
Souvent utilisé comme alternative au port 80 pour les services web.
Moins susceptible d'être bloqué par les pare-feux.
2. Port 8443 (HTTPS Alternative)
Utilisation : Pour rediriger le trafic HTTPS alternatif.
Pourquoi :
Utilisé comme alternative au port 443 pour les services HTTPS.
Fournit un canal sécurisé pour les connexions web chiffrées.
3. Port 9000
Utilisation : Utilisé pour diverses applications.
Pourquoi :
Souvent utilisé pour les applications personnalisées et les services spécifiques.
Peu susceptible d'être surveillé ou bloqué par défaut.
4. Port 10000
Utilisation : Pour rediriger des services administratifs.
Pourquoi :
Utilisé par des applications administratives comme Webmin.
Pratique pour accéder à des interfaces web d'administration.
5. Port 2222
Utilisation : Alternative pour SSH.
Pourquoi :
Utilisé comme port alternatif pour SSH lorsque le port 22 est surveillé ou restreint.
Fournit un accès SSH sans attirer trop d'attention.
🔦 Exploit Rejetto HFS 2.3
❌ Problème ?
Le serveur cible (IP-CIBLE) exécute une version vulnérable de Rejetto HFS.
Les règles de pare-feu restreignent l'accès au port vulnérable, de sorte qu'il ne peut être vu que depuis l'hôte intermédiaire (IP-INTERMEDIAIRE).
Les connexions sortantes depuis le serveur cible ne sont autorisées que vers les machines du réseau local, ce qui rend impossible la réception d'un shell inversé directement sur la machine de l'attaquant (IP-ATTAQUANT).
L'exploit Rejetto HFS nécessite que l'attaquant héberge un serveur HTTP pour déclencher la charge utile finale, mais comme aucune connexion sortante n'est autorisée vers la machine de l'attaquant, nous devons trouver un moyen d'héberger un serveur web sur l'une des autres machines du même réseau, ce qui n'est pas pratique.
⛔ Solution !
Pour contourner ces problèmes, nous pouvons utiliser le tunnel de port.
Tout d'abord, nous devons transférer le port 80 du serveur cible vers la machine de l'attaquant via l'hôte intermédiaire à l'aide d'un transfert de port distant. Nous utiliserons le port 8888 sur la machine de l'attaquant pour écouter les connexions entrantes.
Ensuite, nous devons transférer les ports SRVPORT et LPORT de la machine de l'attaquant vers l'hôte intermédiaire à l'aide d'un transfert de port local.
Enfin, nous pouvons configurer l'exploit Metasploit pour utiliser ces ports transférés et déclencher la charge utile finale.
Voici les commandes à utiliser :
Sur la machine de l'attaquant :
Créer un tunnel SSH inversé entre la machine d'attaque et la machine intermédiaire.
Sur l'hôte intermédiaire :
créer deux tunnels SSH locaux entre la machine intermédiaire et la machine d'attaque.
En créant deux tunnels séparés pour le serveur web malveillant et la connexion inverse du shell, les flux de trafic sont séparés et peuvent être gérés de manière indépendante. Cela peut aider à éviter les conflits de trafic et à améliorer les performances globales.
Note : Remplacez SRVPORT et LPORT par les ports que vous avez choisis.
Sur la machine de l'attaquant :
Note : Remplacez LPORT et SRVPORT par les ports que vous avez choisis.
Résumé :
La faille dans ce scénario est que le serveur cible exécute une version vulnérable de Rejetto HFS.
Cette vulnérabilité permet à un attaquant d'exécuter du code arbitraire sur le système cible en envoyant une requête HTTP spécialement conçue.
Les restrictions de pare-feu et de connexion sortante rendent l'exploitation de la faille plus difficile, car elles empêchent l'attaquant d'accéder directement au port vulnérable et d'héberger un serveur web malveillant sur sa propre machine.
Last updated