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.
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.
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.
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).
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.confTrustwave Holdings, Inc.
All rights reserved.