A couple of weeks ago I posted Part 1 of CrackingIKE, detailing some useful techniques when cracking Aggressive Mode PSK hashes.In that post we saw that a hash is not always 'crackable' and additional stepsare required in order to find a correct group name or ID. In this post I willbe discussing a more recent vulnerability I discovered on the Cisco ASAplatform that allows you to do just that.

A Quick Recap

Going back to the previous post we saw that it was possibleto enumerate group names by analyzing subtle differences in the response fromthe ASA firewall, specifically the presence of a DPD (Dead Peer Detection)payload. So by sending requests to the device with a list of potential groupnames it's possible to find a valid group name if the ASA software isn'tpatched.

What's New?

So I decided to look for any additional signs that may leakinformation about the validity of the group name. I did this by analyzinggenuine IKE negotiations and sending a variety of different requests, lookingfor anything that may provide a clue. I eventually noticed that somedifferences remain even in the latest version of ASA software. Basically, acorrect group name elicits four (this can vary depending on the softwareversion) attempts to continue the handshake and an additional encrypted phase 2packet, while the device will only respond twice to an incorrect group name.This is probably better described in images.

Incorrect group name:

Correct group name:

Demonstration

The differences are quite obvious so to demonstrate I'vewritten a proof of concept python script that enumerates the group names usingthis technique, which can be found here. Although it'sincredibly slow because of the need to wait for the response packets each timea request is made. It requires a wordlist and a target as input, allows the hash type to be specified (MD5 or SHA1) and looks likethis:

The group name (or ID) can then be used to capture a genuine hash forcracking using a cracker of your choice, as described in Part 1:

Personally I prefer Hashcat:

How Do I Protect Against This?

Cisco have released software updates toaddress this issue, further details/updates can be found  here. Administrators with affected software versions should be aware that thisinformation could be potentially revealed, it is recommended that these updatesare applied if your devices are allowing PSK authentication. It is also recommendedthat default or easily guessable group names should not be used and strongPre-Shared Keys are a must. The keys should be rotated as often as ispractically possible and Aggressive Mode IKE negotiations should be disabledwhere possible, but of course this is not always a possibility with RemoteAccess setups. In an ideal world PSK negotiations should be replaced with certificates.

Now What?

Stay tuned for Part 3 which will cover thenext steps where Mission:Improbable becomes a reality…