Cracking IKE Mission:Improbable (Part 2)
A couple of weeks ago I posted Part 1 of Cracking IKE, detailing some useful techniques when cracking Aggressive Mode PSK hashes. In that post we saw that a hash is not always 'crackable' and additional steps are required in order to find a correct group name or ID. In this post I will be discussing a more recent vulnerability I discovered on the Cisco ASA platform that allows you to do just that.
A Quick Recap
Going back to the previous post we saw that it was possible to enumerate group names by analyzing subtle differences in the response from the ASA firewall, specifically the presence of a DPD (Dead Peer Detection)payload. So by sending requests to the device with a list of potential group names it's possible to find a valid group name if the ASA software isn't patched.
What's New?
So I decided to look for any additional signs that may leak information about the validity of the group name. I did this by analyzing genuine IKE negotiations and sending a variety of different requests, looking for anything that may provide a clue. I eventually noticed that some differences remain even in the latest version of ASA software. Basically, a correct group name elicits four (this can vary depending on the software version) 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've written a proof of concept python script that enumerates the group names using this technique, which can be found here. Although it's incredibly slow because of the need to wait for the response packets each time a request is made. It requires a wordlist and a target as input, allows the hash type to be specified (MD5 or SHA1) and looks like this:
The group name (or ID) can then be used to capture a genuine hash for cracking 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 to address this issue, further details/updates can be found here. Administrators with affected software versions should be aware that this information could be potentially revealed, it is recommended that these updates are applied if your devices are allowing PSK authentication. It is also recommended that default or easily guessable group names should not be used and strong Pre-Shared Keys are a must. The keys should be rotated as often as is practically possible and Aggressive Mode IKE negotiations should be disabled where possible, but of course this is not always a possibility with Remote Access setups. In an ideal world PSK negotiations should be replaced with certificates.
Now What?
Stay tuned for Part 3 which will cover the next steps where Mission: Improbable becomes a reality…