500/udp - Pentesting IPsec/IKE VPN

Reading time: 17 minutes

Informação Básica

IPsec é amplamente reconhecido como a tecnologia principal para proteger comunicações entre redes (LAN-to-LAN) e de usuários remotos para o gateway da rede (remote access), servindo como base para soluções VPN empresariais.

O estabelecimento de uma security association (SA) entre dois pontos é gerenciado por IKE, que opera sob o guarda-chuva do ISAKMP, um protocolo projetado para autenticação e troca de chaves. Esse processo ocorre em várias fases:

• Phase 1: Um canal seguro é criado entre dois endpoints. Isso é alcançado através do uso de Pre-Shared Key (PSK) ou certificados, empregando ou main mode, que envolve três pares de mensagens, ou aggressive mode.
• Phase 1.5: Embora não seja obrigatória, esta fase, conhecida como Extended Authentication Phase, verifica a identidade do usuário que tenta se conectar, exigindo nome de usuário e senha.
• Phase 2: Esta fase é dedicada a negociar os parâmetros para proteger os dados com ESP e AH. Ela permite o uso de algoritmos diferentes dos da Phase 1 para garantir Perfect Forward Secrecy (PFS), aumentando a segurança.

Porta padrão: 500/udp

Também comumente exposto: 4500/udp (NAT Traversal)

Descobrir o serviço 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)

Encontrando uma transformação válida

A configuração do IPSec pode ser preparada apenas para aceitar uma ou poucas transformações. Uma transformação é uma combinação de valores. Cada transformação contém vários atributos como DES ou 3DES como o algoritmo de criptografia, SHA ou MD5 como o algoritmo de integridade, uma pre-shared key como o tipo de autenticação, Diffie-Hellman 1 ou 2 como o algoritmo de distribuição de chaves e 28800 seconds como o tempo de vida.

Então, a primeira coisa que você deve fazer é encontrar uma transformação válida, para que o servidor converse com você. Para isso, você pode usar a ferramenta ike-scan. Por padrão, ike-scan funciona em main mode, e envia um pacote para o gateway com um ISAKMP header e uma única proposta com oito transformações dentro dela.

Dependendo da resposta você pode obter algumas informações sobre o 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 você pode ver na resposta anterior, há um campo chamado AUTH com o valor PSK. Isso significa que a vpn está configurada usando uma preshared key (e isso é realmente bom para um pentester).
O valor da última linha também é muito importante:

• 0 returned handshake; 0 returned notify: Isso significa que o alvo não é um IPsec gateway.
• 1 returned handshake; 0 returned notify: Isso significa que o alvo está configurado para IPsec e está disposto a realizar IKE negotiation, e um ou mais dos transforms que você propôs são aceitáveis (um valid transform será mostrado na saída).
• 0 returned handshake; 1 returned notify: VPN gateways respond with a notify message when nenhum dos transforms é aceitável (embora alguns gateways não o façam, caso em que uma análise adicional e uma proposta revisada devem ser tentadas).

Então, neste caso já temos uma valid transformation, mas se você estiver no 3º caso, então você precisa brute-force um pouco para encontrar uma valid transformation:

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

E então brute-force cada um usando ike-scan (isso pode levar vários 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

Se o brute-force não funcionou, talvez o servidor esteja respondendo sem handshakes mesmo para valid transforms. Então você pode tentar o mesmo brute-force 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

Idealmente, uma transformação válida será devolvida.
Você pode tentar o mesmo attack usando iker.py.
Você também pode tentar brute force transformações com ikeforce:

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

Em DH Group: 14 = 2048-bit MODP and 15 = 3072-bit
2 = HMAC-SHA = SHA1 (neste caso). O formato --trans é $Enc,$Hash,$Auth,$DH

A Cisco indica evitar o uso dos DH groups 1 e 2 porque não são suficientemente fortes. Especialistas acreditam que países com muitos recursos podem facilmente quebrar a criptografia de dados que usam esses grupos fracos. Isso é feito usando um método especial que os prepara para quebrar os códigos rapidamente. Embora custe muito dinheiro configurar esse método, ele permite que esses países poderosos leiam os dados criptografados em tempo real se estiverem usando um grupo fraco (como 1,024-bit ou menor).

Identificação do servidor

Então, você pode usar ike-scan para tentar descobrir o fabricante do dispositivo. A ferramenta envia uma proposta inicial e interrompe o replay. Em seguida, ele irá analisar a diferença de tempo entre as mensagens recebidas do servidor e o padrão de resposta correspondente, permitindo que o pentester identifique com sucesso o fabricante do gateway VPN. Além disso, alguns servidores VPN utilizarão o opcional Vendor ID (VID) payload com IKE.

Especifique a transformação válida se necessário (usando --trans)

Se o IKE descobrir qual é o fabricante, ele irá imprimi-lo:

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

Isso também pode ser alcançado com o nmap script ike-version

IKEv2-specific: WatchGuard Vendor ID version fingerprinting

Alguns daemons IKEv2 incluem payloads Vendor ID não padrão na resposta IKE_SA_INIT. O WatchGuard Fireware OS codifica a versão/build do appliance diretamente dentro do VID, permitindo fingerprinting pré-auth com um único pacote.

• Transporte: UDP/500 (e UDP/4500 para NAT-T)
• Pacote: a resposta IKE_SA_INIT contém um ou mais payloads Vendor ID
• WatchGuard format: 32-byte hash seguido por base64 que decodifica para, por exemplo, 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=

Extração rápida em um shell quando você tem o base64 tail:

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

Notas

• Isto não faz parte de nenhum RFC do IKEv2. Trate isto como uma peculiaridade do vendor para mapeamento rápido de versões do Fireware OS expostas/vulneráveis.
• Você só precisa provocar uma resposta IKE_SA_INIT; nenhuma autenticação é necessária.

Encontrando o ID correto (nome do grupo)

Para poder capturar o hash você precisa de uma transformação válida que suporte Aggressive mode e do ID correto (nome do grupo). Provavelmente você não saberá o nome de grupo válido, então terá que brute-forceá-lo.
Para isso, recomendo 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>

Se nenhum hash for retornado, então provavelmente este método de brute forcing funcionará. Se algum hash for retornado, isso significa que um fake hash será enviado de volta para um fake ID, portanto este método não será confiável para brute-force do ID. Por exemplo, um fake hash pode ser retornado (isso acontece em versões modernas):

Mas, como eu disse, se nenhum hash for retornado, você deve tentar brute-force nomes de grupo comuns usando ike-scan.

Este script vai tentar brute-force possíveis IDs e retornará os IDs onde um handshake válido é retornado (isso será um nome de grupo válido).

Se você descobriu uma transformação específica, adicione-a no comando ike-scan. E se descobriu várias transformações, sinta-se à vontade para adicionar um novo loop para testá-las todas (você deve testá-las até que uma funcione corretamente).

Você pode usar o dictionary of ikeforce ou the one in seclists de nomes de grupo comuns para 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

Ou use este dict (é uma combinação dos outros 2 dicts sem repetições):

Bruteforcing ID com Iker

iker.py também usa ike-scan para bruteforce possíveis nomes de grupo. Segue seu próprio método para encontrar um ID válido com base na saída do ike-scan.

Bruteforcing ID com ikeforce

ikeforce.py é uma ferramenta que também pode ser usada para brute force IDs. Esta ferramenta irá tentar explorar diferentes vulnerabilidades que poderiam ser usadas para distinguir entre um ID válido e um não válido (pode ter falsos positivos e falsos negativos, por isso prefiro usar o método do ike-scan se possível).

Por padrão ikeforce enviará no início alguns ids aleatórios para verificar o comportamento do servidor e determinar a tática a usar.

• O primeiro método é brute-force os nomes de grupo procurando pela informação Dead Peer Detection DPD de sistemas Cisco (esta informação é somente retornada pelo servidor se o nome do grupo estiver correto).
• O segundo método disponível é checar o número de respostas enviadas a cada tentativa, porque às vezes mais pacotes são enviados quando o id correto é usado.
• O terceiro método consiste em buscar por "INVALID-ID-INFORMATION" na resposta a um ID incorreto.
• Finalmente, se o servidor não responder nada às checagens, ikeforce tentará brute force o servidor e verificar se, quando o id correto é enviado, o servidor responde com algum pacote.
  Obviamente, o objetivo de brute forcing do id é obter o PSK quando você tem um id válido. Então, com o id e o PSK você terá que bruteforce o XAUTH (se estiver habilitado).

Se você descobriu uma transformação específica, adicione-a no comando ikeforce. E se você descobriu várias transformações, sinta-se à vontade para adicionar um novo loop para testá-las todas (você deve testá-las todas até que uma funcione corretamente).

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

(Do livro Network Security Assessment: Know Your Network): Também é possível obter nomes de usuário válidos por meio de sniffing da conexão entre o cliente VPN e o servidor, pois o primeiro pacote em aggressive mode contendo o client ID é enviado em claro

Capturing & cracking the hash

Finalmente, se você encontrou uma valid transformation e o group name e se o aggressive mode estiver permitido, então você pode muito facilmente capturar o 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

O hash será salvo dentro de hash.txt.

Você pode usar psk-crack, john (usando ikescan2john.py) e hashcat para crack o hash:

psk-crack -d <Wordlist_path> psk.txt

XAuth

Aggressive mode IKE combinado com uma Pre-Shared Key (PSK) é comumente usado para fins de autenticação de grupo. Esse método é complementado por XAuth (Extended Authentication), que introduz uma camada adicional de autenticação de usuário. Essa autenticação normalmente utiliza serviços como Microsoft Active Directory, RADIUS, ou sistemas equivalentes.

Na transição para IKEv2, observa-se uma mudança notável em que EAP (Extensible Authentication Protocol) é usado em vez de XAuth para autenticar usuários. Essa alteração ressalta uma evolução nas práticas de autenticação dentro dos protocolos de comunicação segura.

MitM na rede local para capturar credenciais

Você pode capturar os dados do login usando fiked e verificar se existe algum nome de usuário padrão (Você precisa redirecionar o tráfego IKE para fiked para sniffing, o que pode ser feito com a ajuda de ARP spoofing, more info). Fiked atuará como um endpoint VPN e irá capturar as credenciais XAuth:

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

Além disso, usando IPSec tente realizar um ataque MitM e bloquear todo o tráfego para a porta 500; se o túnel IPSec não puder ser estabelecido, talvez o tráfego seja enviado em claro.

Brute-forcing XAUTH username e password with ikeforce

Para realizar brute-force no XAUTH (quando você conhece um nome de grupo válido id e o psk) você pode usar um username ou uma lista de usernames e uma lista de passwords:

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

Dessa forma, ikeforce tentará se conectar usando cada combinação de username:password.

Se você encontrou um ou vários transforms válidos, apenas os use como nos passos anteriores.

Autenticação com uma VPN IPSEC

No Kali, VPNC é utilizado para estabelecer túneis IPsec. Os perfis devem estar localizados no diretório /etc/vpnc/. Você pode iniciar esses perfis usando o comando vpnc.

Os comandos e configurações a seguir ilustram o processo de configurar uma conexão VPN com 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

Nesta configuração:

• Substitua [VPN_GATEWAY_IP] pelo endereço IP real do gateway VPN.
• Substitua [VPN_CONNECTION_ID] pelo identificador da conexão VPN.
• Substitua [VPN_GROUP_SECRET] pelo group secret da VPN.
• Substitua [VPN_USERNAME] e [VPN_PASSWORD] pelas credenciais de autenticação da VPN.
• [PID] simboliza o ID do processo que será atribuído quando vpnc iniciar.

Certifique-se de que valores reais e seguros sejam usados para substituir os placeholders ao configurar a VPN.

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

Appliances VPN modernos frequentemente expõem IKEv2 em UDP/500 (e UDP/4500 para NAT-T). Uma superfície de ataque comum pré-autenticação é o parsing dos payloads de Identification (IDi) e Certificate durante o IKE_SA_AUTH.

Fluxo de exploração em alto nível quando existe um parser IKEv2 vulnerável:

• Envie um IKE_SA_INIT válido para negociar transforms e completar Diffie–Hellman.
• Em seguida envie IKE_SA_AUTH contendo um IDi que acione o bug (por ex., uma Identification superdimensionada copiada para um buffer de stack de tamanho fixo antes da validação do certificado).
• A corrupção de memória resultante pode proporcionar controle de saved-register e return-address.
• Com NX habilitado mas outras mitigations ausentes (sem PIE/canaries), construa uma ROP chain para chamar mprotect em uma página de stack e então pivotar a execução para shellcode injetado ou para um interpreter residente (p.ex., /usr/bin/python3) se /bin/sh não estiver disponível.

Exemplo de transforms padrão observados em alguns 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

Dicas práticas

• Alveje tanto UDP/500 quanto UDP/4500; servidores NAT-T podem responder apenas em 4500.
• Aumente o receive buffer e timeouts para scanners baseados em UDP para evitar perda de pacotes.
• Se o serviço expõe Vendor IDs customizados (veja seção acima), use-os para rapidamente fingerprintar versões vulneráveis antes de tentar qualquer tráfego de exploit.

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)