All too often during pen tests I still find VPN endpoints configured to allow insecure Aggressive Mode handshakes. Fortunately, gaining access to the internal network as a result of this vulnerability remains a fairly complex task. Hopefully this series of posts will clarify this process and demonstrate the risk this type of misconfiguration can pose to a network...
Background
First a little background on IKE (Internet Key Exchange) and the underlying issue. IKE is used to negotiate an agreed Security Association(SA) between two or more clients to establish an IPSEC VPN tunnel. IKE consists of two phases, phase 1 establishes a secure communication channel and phase 2uses this channel to encrypt and transport the data. Here we are focusing on the first phase, which uses two basic methods of key exchange; Main Mode and Aggressive Mode. In particular we are looking at Aggressive Mode using Pre-Shared Key (PSK) authentication. Main Mode uses a 6 way handshake while Aggressive Mode uses only 3, in doing so the VPN device or 'responder' sends the hashed PSK to the 'initiator' unencrypted. The original IKE (version 1) RFC shows the Aggressive Mode exchange as follows:
Where:
HDR = ISAKMP header
SA = Security Association
KE = Key Exchange
Ni = Initiator Nonce
Nr = Responder Nonce
IDii = Initiator ID Payload
IDir = Responder ID Payload
HASH_I = Initiator Hash
HASH_R = Responder Hash
ike-scan from NTA Monitor is the go-to tool when testing IPSEC implementations and the following command syntax initiates an Aggressive Mode exchange with the VPN endpoint (-M = Multiline, -A = Aggressive Mode):
Some devices will respond to this (usually if the default group has a policy configured), but most will require a group name or ID, which is sent within the 'Initiator ID Payload' referenced above. Group names are used to separate VPN policies on the firewall and you may recognize them from your Cisco VPN client if you have ever used one, under 'Group Authentication' >'Name':
In ike-scan the group name is specified with–-id:
Adding the '-P' flag will return the relevant response payloads including the responder hash (HASH_R):
Why Can't I Crack The Hash?
For the purposes of this review we are lookin gat Cisco VPN endpoints in particular. A vulnerability in older devices meant that they would only respond to a correct ID, so if HASH_R was received it was possible to begin offline cracking of the PSK. However, this is no longer necessarily true and a common misconception is that this hash can be cracked. The response behavior was modified to respond to all requests with HASH_R to prevent enumeration of the group name, so while you will get a hash in the response, unless the ID is correct it will not be possible to crack the hash.
This is true for several reasons, firstly because the device requires the ID to match the group to the PSK, as each group can/should use separate keys. Secondly, the whole ID payload (minus the Header) is folded into the hashing process.
How Can I Crack The Hash?
On the plus side, there is another group name enumeration vulnerability that exists for Cisco devices, allowing you to enumerate the correct group name from the authentication response. This is due to a small difference in responses during the initial exchange, more specifically the presence of a 'Dead Peer Detection' (DPD) payload. DPD is used as a means of detecting un reachable IKE peers, a sort of heartbeat monitoring. Basically, if you receive a DPD response during the initial exchange on an un-patched device it would indicate the group name is correct. While the response to an incorrect group name does not contain the DPD payload. Patched versions respond to all requests with the DPD payload.
Example response to an incorrect group name from a patched ASA firewall:
Example response to an incorrect group name from an unpatched ASA firewall:
Example response to a correct group name from an unpatched ASA firewall:
Doing this manually was not really working for me, so when I had some spare time wrote a quick shell script to brute force the group name and here's how it works:
The script first checks to see if Aggressive Mode is enabled, then confirms the endpoint is a Cisco device. Next it simply checks for a DPD response payload for a non-existent group name to confirm if the device is vulnerable. Then it simply loops through a wordlist provided as an argument. I've added a 4 millisecond wait in there to prevent the possibility of causing a DoS on devices with high load. If it's being run against Cisco routers as opposed to firewalls then this should be increased as it has caused a DoS condition intesting. The script can be downloaded from here for anyone that's interested.
There are a few options available for cracking when you have a valid hash, including psk-crack and Cain. The good news is it's now also supported in John The Ripper with the correct patch applied, allowing multi-core cracking. This can be accomplished with the following commands:
The even better news is that it's also supported in OCL Hash cat, using the following commands:
Conclusion
Obviously this is not the first time these types of issues have been addressed and most people know that IKE with PSK is not considered the most secure setup, but unfortunately this remains the default configuration for some devices and it's quite common to find. There was a Metasploit module that was created to do the same task as the above script, but it never made it into the stable release. I am only sharing the method I use for this process.
Of course there is the possibility that DPD has been disabled, which would give a false negative when identifying this vulnerability. However, this is not the default configuration and is not a common configuration.
It's also important to note that this doesn't automatically provide you with the keys to the network, there is usually a second authentication factor to consider which will be covered in another post.
References:
No response Cisco Bug ID CSCeg00323
DPD response Cisco Bug ID CSCtj96108