Alltoo often during pen tests I still find VPN endpoints configured to allow insecureAggressive Mode handshakes. Fortunately, gaining access to the internal networkas a result of this vulnerability remains a fairly complex task. Hopefully this series ofposts will clarify this process and demonstrate the risk this type of misconfigurationcan pose to a network...

Background

First a little background on IKE (Internet Key Exchange) andthe underlying issue. IKE is used to negotiate an agreed Security Association(SA) between two or more clients to establish an IPSEC VPN tunnel. IKE consistsof two phases, phase 1 establishes a secure communication channel and phase 2uses this channel to encrypt and transport the data. Here we are focusing onthe first phase, which uses two basic methods of key exchange; Main Mode andAggressive Mode. In particular we are looking at Aggressive Mode usingPre-Shared Key (PSK) authentication. Main Mode uses a 6 way handshake whileAggressive Mode uses only 3, in doing so the VPN device or 'responder' sendsthe hashed PSK to the 'initiator' unencrypted. The original IKE (version 1) RFCshows 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-scanfrom NTA Monitor is the go-to tool when testing IPSEC implementations and thefollowing command syntax initiates an Aggressive Mode exchange with the VPNendpoint (-M = Multiline, -A = Aggressive Mode):

Some devices will respond to this (usually if the defaultgroup has a policy configured), but most will require a group name or ID, which issent within the 'Initiator ID Payload' referenced above. Group names are usedto separate VPN policies on the firewall and you may recognize them from yourCisco VPN client if you have ever used one, under 'Group Authentication' >'Name':

d

In ike-scan the group name is specified with–-id:

Adding the '-P' flag will return the relevant responsepayloads including the responder hash (HASH_R):

 Why Can't I Crack TheHash?

For the purposes of this review we are lookingat Cisco VPN endpoints in particular. A vulnerability in older devices meantthat they would only respond to a correct ID, so if HASH_R was received it waspossible to begin offline cracking of the PSK. However, this is no longer necessarilytrue and a common misconception is that this hash can be cracked. The responsebehavior was modified to respond to all requests with HASH_R to prevent enumerationof the group name, so while you will get a hash in the response, unless theID is correct it will not be possible to crack the hash.

This is true for several reasons, firstly because the devicerequires the ID to match the group to the PSK, as each group can/should useseparate keys. Secondly, the whole ID payload (minus the Header) is folded intothe hashing process.

How Can I Crack TheHash?

On the plus side, there is another group name enumerationvulnerability that exists for Cisco devices, allowing you to enumerate thecorrect group name from the authentication response. This is due to a smalldifference in responses during the initial exchange, more specifically the presenceof a 'Dead Peer Detection' (DPD) payload. DPD is used as a means of detectingunreachable IKE peers, a sort of heartbeat monitoring.  Basically, if you receive a DPD response duringthe initial exchange on an un-patched device it would indicate the group nameis correct.  While the response to anincorrect group name does not contain the DPD payload. Patched versions respondto all requests with the DPD payload.

Example response to an incorrect group name from a patchedASA firewall:

Example response to an incorrect group name from anunpatched ASA firewall:

Example response to a correct group name from anunpatched ASA firewall:

Doingthis manually was not really working for me, so when I had some spare time wrotea quick shell script to brute force the group name and here's how it works:

The script first checks to see if Aggressive Mode isenabled, then confirms the endpoint is a Cisco device. Next it simply checksfor a DPD response payload for a non-existent group name to confirm if thedevice is vulnerable. Then it simply loops through a wordlist provided as anargument. I've added a 4 millisecond wait in there to prevent the possibilityof causing a DoS on devices with high load. If it's being run against Ciscorouters 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 havea valid hash, including psk-crack and Cain. The good news is it's now alsosupported in John The Ripper with the correct patch applied, allowingmulti-core cracking. This can be accomplished with the following commands:

The even better news is that it's also supported in OCLHashcat,using the following commands:

Conclusion

Obviouslythis is not the first time these types of issues have been addressed and mostpeople 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. Therewas 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 Iuse for this process.

Ofcourse there is the possibility that DPD has been disabled, which would give afalse negative when identifying this vulnerability. However, this is not thedefault configuration and is not a common configuration.

It'salso important to note that this doesn't automatically provide you with thekeys to the network, there is usually a second authentication factor toconsider which will be covered in another post.

References:

No response Cisco Bug ID CSCeg00323

DPD response Cisco Bug ID CSCtj96108