Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Cracking IKE Mission:Improbable (Part 1)

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:

11189_ad2f9e59-a362-4e02-bb96-32aa02d3624a

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):

11621_c215f2f1-9ff8-48e3-8825-56bd8c3fa873

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':

9417_59171597-5d53-4ac8-88f9-02d16f00dc01d

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

10077_7a1bc306-2489-41b0-98df-fca1f0795134

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

11501_bc503e78-62ac-4388-990b-3126fa5f2f4e

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:

12088_d8da6363-d3fd-441d-9fd6-8c5ed605b916

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

7905_0e19ccb2-5156-467c-a45b-e04ee72d7cb8

Example response to a correct group name from an unpatched ASA firewall:

7759_07a04c9d-c1b0-4aac-a94d-42c411428231

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:

12864_fce28359-f4e2-41ff-954f-ef3b4892ebe0

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:

10335_83d39586-f9da-424b-bf10-1907e95f238f

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

8458_2a54cec6-4aba-46ce-80ff-8c0b70c1d61f

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

Latest SpiderLabs Blogs

Why We Should Probably Stop Visually Verifying Checksums

Hello there! Thanks for stopping by. Let me get straight into it and start things off with what a checksum is to be inclusive of all audiences here, from Wikipedia [1]:

Read More

Agent Tesla's New Ride: The Rise of a Novel Loader

Malware loaders, critical for deploying malware, enable threat actors to deliver and execute malicious payloads, facilitating criminal activities like data theft and ransomware. Utilizing advanced...

Read More

Evaluating Your Security Posture: Security Assessment Basics

This is Part 4 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More