Introduction
As discussed in parts 1 and 2 of this series, the most common VPN endpoints (responders) found supporting Aggressive Mode negotiation are Cisco devices. However, they are also almost always supported by a second factor authentication mechanism known as XAUTH. I originally wrote a shell script that leverages VPNC, one of the command line VPN clients discussed in this post, to brute force valid XAUTH credentials. Then I decided to write it all out from scratch in Python, but I lost interest for a few months and put it on the backburner. Anyway I've finished the tool now, which also incorporates some additional tricks, so get the IKEForce tool at the SpiderLabs GitHub and read on for more info.
XAUTH
First off let's cover XAUTH (Extended Authentication), which was created to further secure VPN endpoints protected with only PSK authentication. XAUTH sits at phase 1.5. So it's after the initial IKE handshake before the process shifts to phase 2 (ESP or AH), and it's the final authentication step using a separate username/password combination to provide 2-factor authentication.
XAUTH has 4 main types, which are specified by the following integers in the XAUTH request payload sent by the responder (endpoint):
- Generic (local user database)
- RADIUS-CHAP (the CHAP authentication defined in the RADIUS RFC)
- OTP (One Time Password)
- SKEY (An older one-time password scheme which was a precursor to OTP)
We will start by focusing on Generic authentication. If the responder uses XAUTH this will be declared with an XAUTH VID in the initial response or an authentication type of 65001-65010 specified in the transform set response. This can be seen by using ike-scan to parse the initial response containing the VID payloads.
XAUTH VID
So before we move onto gaining access to the internal network, we need some way of brute-force guessing valid XAUTH credentials. FIKEd is available to conduct man-in-the-middle attacks against IPSEC VPNs once you have the correct PSK, but there is currently nothing available for actively guessing the credentials.
Introducing IKEForce.py
IKEForce addresses this gap by allowing XAUTH usernames and passwords to be brute-forced. It also has a number of group name/ID enumeration techniques built in and supersedes the previous groupenum scripts, so it works in 2 modes: enum (-e) and brute (-b).
The enumeration mode uses the following techniques:
- Cisco DPD payload in response for correct group name
- Cisco multiple responses for correct group name
- "INVALID-ID-INFORMATION" in response to incorrect ID
- No response to incorrect ID
The two techniques for Cisco ASA devices were discussed in the previous articles in this series.
The "INVALID-ID-INFORMATION" technique works against SonicWall, Juniper and Openswan endpoints. There's also a generic enumeration technique, which calculates the correct ID on devices that only respond to a correct ID. This is valid for WatchGuard devices for instance. This type of enumeration issue is not a high risk by itself and savvy administrators should know that Aggressive Mode IKE with PSK is highly insecure. However, the above vendors were contacted prior to my releasing this tool so that they could decide whether they wanted to prevent this enumeration (with the exception of Juniper who already disclosed the issue years ago).
Prior to beginning any enumeration a valid transform set is required, unless the responder supports the default transform of 3DES/MD5/XAUTH/DH2. The tool does not cover enumerating supported transform sets as this can be achieved with ike-scan and I didn't want to reinvent the wheel. However, I would consider adding this feature in the future if it's something that's requested. Once you have a correct transform set the ID/group name enumeration is run as follows, with "-t" being the (optional) enumerated transform set:
Demo – Enum mode against a Cisco ASA (8.45)
As you can see the tool will identify the presence of the vulnerabilities in most cases, and then continue to run the relevant enumeration technique or exit. The multiple response Cisco group name enumeration discussed in the last post is now much faster as there's no need to wait for the responses. Instead, the tool attempts to continue the handshake and marks the group name as incorrect if the attempt is unsuccessful.
Once we have a valid ID/group name and have cracked the PSK hash, as discussed in the previous post, we almost always need the second factor XAUTH authentication credentials. So we then run IKEForce in brute mode, as outlined below (where "cisco1" is the cracked PSK and "dan" is the username):
Demo – Brute mode against a Cisco ASA (8.45)
The tool supports brute forcing a single username (-u) or a list of usernames, which can be specified with "–U". One of the advantages of writing out the handshake process from scratch is that it's less intensive for the responder because several credential attempts can be used within one phase 1 negotiation. Cisco seems to limit this to 3 before renegotiation is required, however others allow an entire wordlist to be unloaded. The tool doesn't account for account lockout in any way so if you are running this against a production environment--well, you know you should be careful. It does however have a speed option (-s) so you can manually set the speed of the guessing for both enum and brute mode (which is set to a conservative speed by default).
Wordlists
I've included some useful wordlists that have worked for me quite a few times in the past under the "ikeforce/wordlists/" directory. They include the following:
- groupnames.dic - Default group names and a brief Google search/scrape for group name's leaked by administrators trying to troubleshoot connections
- English dictionary with length 3-7
- Brute-force lists of short keyspaces (1-3 uppercase etc) with Markov optimizations, courtesy of Hashcat
- The above wordlists with mangling rules applied, appending things like "_VPN" or "–VPN"
Internal Network Access
Now that we have the required details (responder IP, group name/ID, cracked PSK, XAUTH username & XAUTH password), we can begin to setup a connection into the internal network using a VPN client. There are a large variety of clients available, both open source and proprietary in nature, but personally I avoid using Windows because it's too clunky, so I'm just going to describe two of the open source command line clients available to Linux users.
As always, we are focusing on Cisco devices for this section. For connecting to Cisco IPSEC VPN's, the easiest client to setup is VPNC and the second client we will discuss is Openswan, which has the added advantage of being usable for most other vendor's VPN implementations. I won't cover the install process here for the sake of brevity, but both should be available in your chosen Linux repository.
To configure VPNC the configuration files are usually under "/etc/vpnc/", there you can create a configuration file for your IPSEC connection. In this case I have named it "vpn.conf" to correspond with the group name of the connection. The contents in our scenario would be:
vpn.conf
To bring the tunnel up the following command can be used:
vpnc vpn
To disconnect:
vpnc-disconnect
Successful VPNC connection and TUN interface with internal IP address assigned
The equivalent setup for Openswan is managed by 2 files - "/etc/ipsec.conf" & "/etc/secrets.conf". Their contents in our case would be:
/etc/ipsec.conf
/etc/secrets.conf
The following command will bring the tunnel up on Debian based systems:
service ipsec start ipsec auto --up vpn
The tunnel can be stopped with:
service ipsec stop
Recap
So the whole process would go as follows:
- Scan for the IKE service
- Enumerate transform sets and confirm Aggressive Mode support
- Run IKEForce in enum mode to obtain a valid group name or ID
- Obtain a valid hash using IKE-Scan
- Crack the hash using OCLHashcat
- Run IKEForce in brute mode to obtain valid XAUTH credentials
- Authenticate using chosen client
- Pwn to your heart's content
Demo – whole process performed against a Cisco ASA (8.02)
IKEForce Limitations
One of the limitations of the tool currently is that it only supports generic authentication. I will be adding RADIUS authentication over the next few weeks/months. Other limitations that I see are listed below:
- Need to enumerate a valid transform set with ike-scan
- Only supports the standard encryption/dh types (DES, 3DES, AES, SHA1, MD5, DH1, DH2, DH5)
- Only uses IKEv1/Aggressive Mode/PSK
Conclusion
Thankfully many people seem to be removing this age-old vulnerability from their external network infrastructure now. They may have rolled their eyes at seeing Aggressive Mode/PSK as a finding in the past, but I know at least some of our clients have been persuaded to remediate the issue by seeing their cracked PSKs in a pen test report.
The whole process is a rather convoluted way of compromising an internal network in many cases, as it would often be easier to brute-force the SSL VPN if it's in use. Although automation of this attack is not conceptually groundbreaking, we now have a practical means of taking the attack further than simply demonstrating to clients that we have cracked the PSK. FIKEd is great and all, but it rarely gives us something demonstrable during a pen test. Gaining access to the internal network and demonstrating some internal compromises should go a long way in convincing any admin that continues to use an Aggressive Mode/PSK configuration to stop. And of course it would make for a pretty l33t report.
I haven't had the chance to use the tool much in the wild, so I'd love to hear from anyone who actually manages to go the whole way with the methods described in this series. For now though, the series is (belatedly) concluded.
References
IKEForce - https://github.com/SpiderLabs/ikeforce
Juniper enumeration - http://www.securityfocus.com/archive/1/408478
VPNC - http://svn.unix-ag.uni-kl.de/vpnc/
Openswan - https://www.openswan.org/
IKE-SCAN - http://www.nta-monitor.com/tools-resources/security-tools/ike-scan
FIKEd - http://www.roe.ch/FakeIKEd
