500/udp - Pentesting IPsec/IKE VPN

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Informazioni di base

IPsec è ampiamente riconosciuto come la tecnologia principale per proteggere le comunicazioni tra reti (LAN-to-LAN) e dagli utenti remoti verso il gateway di rete (accesso remoto), fungendo da spina dorsale per le soluzioni VPN aziendali.

La creazione di una security association (SA) tra due punti è gestita da IKE, che opera sotto l’egida di ISAKMP, un protocollo progettato per l’autenticazione e lo scambio di chiavi. Questo processo si svolge in diverse fasi:

  • Fase 1: Viene creato un canale sicuro tra due endpoint. Questo si ottiene tramite l’uso di una Pre-Shared Key (PSK) o certificati, impiegando oppure main mode, che comporta tre coppie di messaggi, o aggressive mode.
  • Fase 1.5: Anche se non obbligatoria, questa fase, nota come Fase di Autenticazione Estesa (Extended Authentication Phase), verifica l’identità dell’utente che tenta di connettersi richiedendo username e password.
  • Fase 2: Questa fase è dedicata alla negoziazione dei parametri per la protezione dei dati con ESP e AH. Permette l’uso di algoritmi diversi rispetto a quelli della Fase 1 per garantire Perfect Forward Secrecy (PFS), aumentando la sicurezza.

Porta predefinita: 500/udp

Comunemente esposto anche: 4500/udp (NAT Traversal)

Scopri il servizio 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)

Trovare una trasformazione valida

La configurazione IPSec può essere preparata per accettare solo una o poche trasformazioni. Una trasformazione è una combinazione di valori. Ogni trasformazione contiene una serie di attributi come DES o 3DES come algoritmo di cifratura, SHA o MD5 come algoritmo di integrità, una chiave pre-condivisa come tipo di autenticazione, Diffie-Hellman 1 o 2 come algoritmo di distribuzione delle chiavi e 28800 secondi come durata.

Quindi, la prima cosa che devi fare è trovare una trasformazione valida, in modo che il server comunichi con te. Per farlo puoi usare lo strumento ike-scan. Per default, Ike-scan funziona in main mode, e invia un pacchetto al gateway con un header ISAKMP e una singola proposta contenente otto trasformazioni.

A seconda della risposta puoi ottenere alcune informazioni sull’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

Come puoi vedere nella risposta precedente, c’è un campo chiamato AUTH con il valore PSK. Questo significa che la vpn è configurata usando una preshared key (e questo è davvero buono per un pentester).
Il valore dell’ultima riga è anche molto importante:

  • 0 returned handshake; 0 returned notify: Questo significa che il target è not an IPsec gateway.
  • 1 returned handshake; 0 returned notify: Questo significa che il target è configurato per IPsec ed è disposto a eseguire IKE negotiation, e una o più delle transforms che hai proposto sono accettabili (a valid transform will be shown in the output).
  • 0 returned handshake; 1 returned notify: I VPN gateways rispondono con un notify message quando none of the transforms are acceptable (anche se alcuni gateway non lo fanno, in tal caso si dovrebbe effettuare un’ulteriore analisi e provare una proposta rivista).

Poi, in questo caso abbiamo già una valid transformation ma se ti trovi nel 3° caso, allora devi brute-force un po’ per trovare una valid transformation:

Per prima cosa devi creare tutte le possibili 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

Quindi effettuare un brute-force su ciascuno usando ike-scan (questo può richiedere alcuni minuti):

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 il brute-force non ha funzionato, forse il server risponde senza handshakes anche a valid transforms. In tal caso, puoi provare lo stesso brute-force ma 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

Si spera che venga restituita una trasformazione valida.
Puoi provare lo stesso attack usando iker.py.
Puoi anche provare a brute force trasformazioni con ikeforce:

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

In DH Group: 14 = 2048-bit MODP e 15 = 3072-bit
2 = HMAC-SHA = SHA1 (in questo caso). Il formato --trans è $Enc,$Hash,$Auth,$DH

Cisco indica di evitare l’uso dei DH groups 1 e 2 perché non sono abbastanza forti. Gli esperti ritengono che paesi con molte risorse possano facilmente rompere la crittografia dei dati che usano questi gruppi deboli. Questo avviene utilizzando un metodo speciale che li prepara a decifrare i codici rapidamente. Anche se costa molto mettere in piedi questo metodo, permette a questi paesi potenti di leggere i dati crittografati in tempo reale se viene usato un gruppo non sicuro (come 1.024-bit o inferiore).

Server fingerprinting

Poi, puoi usare ike-scan per provare a scoprire il vendor del dispositivo. Lo strumento invia una proposta iniziale e interrompe il replay. Successivamente, analizzerà la differenza di tempo tra i messaggi ricevuti dal server e il pattern di risposta corrispondente; il pentester può fingerprintare con successo il vendor del gateway VPN. Inoltre, alcuni server VPN useranno il payload opzionale Vendor ID (VID) con IKE.

Specifica la trasformazione valida se necessario (usando –trans)

Se IKE scopre quale è il vendor, lo stamperà:

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

This può essere ottenuto anche con lo script nmap ike-version

IKEv2-specific: WatchGuard Vendor ID version fingerprinting

Alcuni daemon IKEv2 includono payload Vendor ID non standard nella risposta IKE_SA_INIT. WatchGuard Fireware OS codifica la versione/build dell’appliance direttamente all’interno del VID, permettendo fingerprinting pre-auth con un singolo pacchetto.

  • Transport: UDP/500 (e UDP/4500 per NAT-T)
  • Packet: la risposta IKE_SA_INIT contiene uno o più payload Vendor ID
  • WatchGuard format: hash di 32 byte seguito da base64 che decodifica in es. VN=12.11.3 BN=719894

Esempio di raw bytes da un payload VID WatchGuard (gli ultimi 12 byte sono 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=

Estrazione rapida in una shell quando hai il tail base64:

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

Note

  • Questo non fa parte di nessun RFC di IKEv2. Trattalo come una peculiarità del vendor per un rapido scoping delle versioni di Fireware OS esposte/vulnerabili.
  • È sufficiente ottenere una risposta IKE_SA_INIT; non è richiesta alcuna autenticazione.

Trovare l’ID corretto (nome del gruppo)

Per poter catturare l’hash è necessaria una trasformazione valida che supporti Aggressive mode e l’ID corretto (nome del gruppo). Probabilmente non conoscerai il nome del gruppo valido, quindi dovrai brute-forcearlo.
Per farlo, ti consiglierei 2 metodi:

Bruteforcing ID with ike-scan

Per prima cosa prova a fare una richiesta con un ID fittizio cercando di raccogliere l’hash (“-P”):

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

Se non viene restituito alcun hash, allora probabilmente questo metodo di brute forcing funzionerà. Se viene restituito qualche hash, questo significa che verrà inviato indietro un fake hash per un fake ID, quindi questo metodo non sarà affidabile per effettuare il brute-force sull’ID. Per esempio, potrebbe essere restituito un fake hash (questo succede nelle versioni moderne):

Ma come ho detto, se non viene restituito alcun hash, allora dovresti provare a effettuare il brute-force sui nomi di gruppo comuni usando ike-scan.

Questo script proverà a effettuare il brute-force sui possibili ID e restituirà gli ID per i quali viene restituita una handshake valida (questo corrisponderà a un nome di gruppo valido).

Se hai scoperto una trasformazione specifica, aggiungila nel comando ike-scan. E se hai scoperto diverse trasformazioni, sentiti libero di aggiungere un nuovo ciclo per provarle tutte (dovresti provarle tutte finché una non funziona correttamente).

Puoi usare il dictionary of ikeforce o the one in seclists dei nomi di gruppo comuni per effettuarne il 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):

Bruteforcing ID with Iker

iker.py also uses ike-scan to bruteforce possible group names. Segue il proprio metodo per trovare un ID valido basandosi sull’output di ike-scan.

Bruteforcing ID with ikeforce

ikeforce.py is a tool that can be used to brute force IDs also. Questo strumento cercherà di sfruttare diverse vulnerabilità che potrebbero essere usate per distinguere tra un ID valido e uno non valido (potrebbe avere falsi positivi e falsi negativi, per questo preferisco usare il metodo ike-scan quando possibile).

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

  • Il primo metodo è brute-force dei nomi di gruppo cercando le informazioni Dead Peer Detection DPD dei sistemi Cisco (questa info viene inviata dal server solo se il nome del gruppo è corretto).
  • Il secondo metodo disponibile è controllare il numero di risposte inviate per ogni tentativo perché a volte vengono inviati più pacchetti quando viene usato l’id corretto.
  • Il terzo metodo consiste nel cercare “INVALID-ID-INFORMATION” in risposta a un ID errato.
  • Infine, se il server non risponde a questi controlli, ikeforce cercherà di brute force il server e verificherà se, quando viene inviato l’id corretto, il server risponde con qualche pacchetto.\

Ovviamente, lo scopo del brute forcing dell’id è ottenere la PSK quando hai un id valido. Poi, con l’id e la PSK dovrai effettuare il bruteforce di XAUTH (se è abilitata).

Se hai scoperto una trasformazione specifica aggiungila nel comando ikeforce. E se hai scoperto diverse trasformazioni sentiti libero di aggiungere un nuovo loop per provarle tutte (dovresti provarle tutte finché una non funziona correttamente).

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): È anche possibile ottenere nomi utente validi sniffing la connessione tra il client VPN e il server, poiché il primo pacchetto aggressive mode contenente il client ID viene inviato in chiaro

Aggressive Mode identity leakage

Aggressive Mode deve inviare l’ID precocemente affinché il gateway possa scegliere la PSK corretta quando esistono più gruppi/utenti. Questo significa che l’identità è esposta pre-auth, a differenza di Main Mode dove è crittografata nei pacchetti successivi. Puoi estrarla rapidamente:

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

Se Aggressive Mode è abilitato, cattura un handshake PSK crackabile e craccalo offline (hashcat mode 5400):

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

Recovered PSKs are often riutilizzati as credentials for other services (SSH, VPN client auth), so test them against exposed services.

Capturing & cracking the hash

Infine, se hai trovato una trasformazione valida e il nome del gruppo e se la aggressive mode è consentita, allora puoi ottenere molto facilmente l’hash crackabile:

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

L’hash sarà salvato in hash.txt.

Puoi usare psk-crack, john (usando ikescan2john.py) e hashcat per effettuare il crack dell’hash:

psk-crack -d <Wordlist_path> psk.txt

XAuth

Aggressive mode IKE combinato con una Pre-Shared Key (PSK) è comunemente impiegato per scopi di autenticazione di gruppo. Questo metodo è integrato da XAuth (Extended Authentication), che introduce un ulteriore livello di autenticazione utente. Tale autenticazione tipicamente sfrutta servizi come Microsoft Active Directory, RADIUS, o sistemi analoghi.

Nel passaggio a IKEv2 si osserva un cambiamento notevole: EAP (Extensible Authentication Protocol) viene utilizzato al posto di XAuth per autenticare gli utenti. Questo cambiamento sottolinea un’evoluzione nelle pratiche di autenticazione all’interno dei protocolli di comunicazione sicura.

MitM in rete locale per catturare credenziali

Quindi puoi catturare i dati di login usando fiked e verificare se esiste qualche username predefinito (È necessario reindirizzare il traffico IKE verso fiked per lo sniffing, cosa che può essere fatta con l’aiuto di ARP spoofing, more info). Fiked agirà come endpoint VPN e catturerà le credenziali XAuth:

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

Inoltre, usando IPSec prova a effettuare un MitM e bloccare tutto il traffico verso port 500; se il tunnel IPSec non può essere stabilito, potrebbe succedere che il traffico venga inviato in chiaro.

Brute-forcing XAUTH username ad password with ikeforce

Per brute-forcing la XAUTH (quando conosci un valido group name id e la psk) puoi usare un username o una lista di username e una lista di password:

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

In questo modo, ikeforce proverà a connettersi usando ogni combinazione di username:password.

Se hai trovato una o più trasformazioni valide, usale come nei passaggi precedenti.

Autenticazione con un IPSEC VPN

In Kali, VPNC è utilizzato per stabilire tunnel IPsec. I profiles devono trovarsi nella directory /etc/vpnc/. Puoi avviare questi profili usando il comando vpnc.

I seguenti comandi e configurazioni illustrano il processo di configurazione di una connessione 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

In questa configurazione:

  • Sostituire [VPN_GATEWAY_IP] con l’indirizzo IP effettivo del gateway VPN.
  • Sostituire [VPN_CONNECTION_ID] con l’identificatore della connessione VPN.
  • Sostituire [VPN_GROUP_SECRET] con il segreto di gruppo della VPN.
  • Sostituire [VPN_USERNAME] e [VPN_PASSWORD] con le credenziali di autenticazione VPN.
  • [PID] rappresenta il process ID che verrà assegnato quando vpnc si avvia.

Assicurarsi di usare valori reali e sicuri per sostituire i segnaposto durante la configurazione della VPN.

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

Gli appliance VPN moderni spesso espongono IKEv2 su UDP/500 (e UDP/4500 per NAT-T). Una superficie di attacco comune pre-auth è il parsing dei payload Identification (IDi) e Certificate durante IKE_SA_AUTH.

Flusso di sfruttamento ad alto livello quando è presente un parser IKEv2 vulnerabile:

  • Inviare un IKE_SA_INIT valido per negoziare i transforms e completare Diffie–Hellman.
  • Proseguire con IKE_SA_AUTH contenente un IDi che innesca il bug (es. una Identification sovradimensionata copiata in un buffer di dimensione fissa sullo stack prima della validazione del certificato).
  • La corruzione di memoria risultante può portare al controllo di saved-register e return-address.
  • Con NX abilitato ma altre mitigazioni mancanti (no PIE/canaries), costruire una catena ROP per chiamare mprotect su una pagina di stack e poi pivotare l’esecuzione verso shellcode iniettato o verso un interprete residente (es. /usr/bin/python3) se /bin/sh non è disponibile.

Esempi di default transforms osservati su alcuni appliance 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

Consigli pratici

  • Mirare sia UDP/500 che UDP/4500; i server NAT-T possono rispondere solo su 4500.
  • Aumentare il receive buffer e i timeout per gli scanner basati su UDP per evitare perdita di pacchetti.
  • Se il servizio espone Vendor IDs personalizzati (vedi sezione sopra), usarli per fingerprintare rapidamente le versioni vulnerabili prima di inviare traffico di exploit.

Reference Material

Shodan

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

References

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks