Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mode

Our vulnerability scanner (Qualys) has come back with this vulnerability against our Cisco 837 DSL router VPN that connects to a Cisco Concentrator. Is my Pre-shared key too short - 8 characters?

Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mode port 500/udp

THREAT:

IKE is used during Phase 1 and Phase 2 of establishing an IPSec connection. Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. Every participant in IKE must possess a key which may be either pre-shared (PSK) or a public key. There are inherent risks to configurations that use pre-shared keys which are exaggerated when Aggressive Mode is used.

IMPACT:

Using Aggressive Mode with pre-shared keys is the least secure option. In this particular scenario, it is possible for an attacker to gather all necessary information in order to mount an off-line dictionary (brute force) attack on the pre-shared keys. For more information about this type of attack, visit http://www.ima.umn.edu/~pliam/xauth/.

SOLUTION:

IKE Aggressive mode with pre-shared keys should be avoided where possible. Otherwise a strong pre-shared key should be chosen.

Note that this attack method has been known and discussed within the IETF IPSec Working Group. The risk was considered as acceptable. For more information on this, visit http://www.vpnc.org/ietf-ipsec/99.ipsec/thrd2.html#01451.

20 REPLIES
Hall of Fame Super Silver

Re: Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mo

Andy

The vulnerability is based on the use of Aggressive Mode and pre-shared keys and that may be a given in your situation.

The risk can be mitigated by the use of a "strong" key. I believe that keys of 8 characters can be classified as strong if they meet some criteria such as:

- is not a name or a dictionary word.

- contain a mixture of letters and numbers.

- contain a mixture of upper case and lower case letters.

Does your key meet most of these criteria?

HTH

Rick

New Member

Re: Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mo

it meets both your criteria and is 8 characters long.

Hall of Fame Super Silver

Re: Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mo

Andy

In that case I would claim to management that the risk was sufficiently mitigated.

HTH

Rick

New Member

Re: Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mo

Yeah, could false positive?

New Member

I have the same issue and I

I have the same issue and I fixed it by disable the aggresive mode inbound with the command crypto ikev1 am-disable on any cisco ASA platform will work..

New Member

Hello Rick,we are having same

Hello Rick,

we are having same issue.

Encrypted Management Interfaces Accessible On Cisco Device
Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mode.

we are using ezvpn between Cisco 1900 Router (client) and ASA firewall.

Here pre-shared key is of 8 character long mixed of alpha numeric.

Please suggest the way to overcome from this vulnerability.

 

 

Hall of Fame Super Silver

There are two aspects of this

There are two aspects of this problem which might be part of the effort to mitigate the vulnerability. IKE can use Main mode or Aggressive mode. If you get your devices to use Main mode rather than Aggressive mode you mitigate the issue. I am not clear whether ezvpn allows you to specify the mode.

 

The second aspect which may help mitigate the vulnerability is the length and strength of your key. 8 characters mixing alpha and numeric is a fairly strong key. If you are concerned and want to better mitigate the vulnerability then increase the length of the key and/or improve the strength of the key (Upper and lower case alpha, special symbols in addition to numeric).

 

HTH

 

Rick

New Member

Both sides of the tunnel are

Both sides of the tunnel are using Main mode.

Hall of Fame Super Silver

The vulnerability that is the

The vulnerability that is the focus of this thread involves use of Aggressive mode. If your VPN tunnels are using Main mode then it would seem that you are not impacted by this vulnerability.

 

HTH

 

Rick

New Member

Then why am I getting flagged

Then why am I getting flagged by qualys? I mean we pay tons of money for this thing and it still detects things that are not relevant.

Hall of Fame Super Silver

I am certainly not able to

I am certainly not able to say anything authoritative about what Qualys does and how they do it, so I will only offer this observation. It is easy to look for devices that are listening on UDP 500 or 4500 and deduce that the device is processing ISAKMP. And it is easy to say that if a device is processing ISAKMP that the vulnerability with Aggressive mode might come into play. It is not so easy to determine the mode being used (especially since there is negotiation involved and to know what the outcome will be you would need to have knowledge about the remote peer) and it is pretty clear that Qualys has decided that it is not worth the effort for their product to attempt to determine the mode being used.

 

HTH

 

Rick

New Member

CLI:  show vpn-sessiondb

CLI:  show vpn-sessiondb detail l2l

Hall of Fame Super Silver

This would be the CLI

This would be the CLI equivalent of the approach that I suggested using ASDM. Either approach should allow you to determine the mode that was negotiated. Note that for either approach to work the tunnel must be currently up. Since the vulnerability scanner is probably checking based on what is configured rather than on what is actually active, it might be difficult to determine the mode used for a tunnel that is used infrequently.

HTH

Rick 

New Member

Pre-shared Key Off-line Bruteforcing Using IKE Aggressive Mode

Did you pass the scan; I am getting the same vulnerability when scanning my ASA.

How did you got it solved?

My keys also accomplish the requirement.

New Member

Looking for an update on this

Looking for an update on this as I have the same issue.

Hall of Fame Super Silver

The description of the

The description of the vulnerability specifies IKE aggressive mode. So my first question would be whether you are using IKE in aggressive mode or in main mode? In my experience most router based site to site VPN use main mode (though aggressive mode is an option) while many Remote Access VPN use aggressive mode. So which mode are you using?

 

The second part of my response goes back to what I said in my earlier response. What kind of key are you using? How long is it and how strong is it? When you think about it any time we authenticate using shared keys there is some degree of vulnerability to brute force attack. The longer the key and the stronger the key the more you have mitigated the risk.

 

HTH

 

Rick

New Member

These are Site to Site VPNs

These are Site to Site VPNs using ASA 5505's terminating to ASA 5525-X series firewalls. The key like 8-10 characters and we DO NOT change them on a regular basis, that would be a nightmare.

 

How and where do you find out in an ASA if its aggressive or main mode?

Hall of Fame Super Silver

There are several ways that

There are several ways that you can check on the mode used (main or aggressive). Probably the easiest is to use ASDM. Choose the options to Monitor-> VPN -> VPN statistics -> Sessions and then specify l2l which will display the various Lan to Lan VPNs. Click on one of them and then click Details. In the output will be an indication of the mode used. 

 

HTH

 

Rick

New Member

I have the same issue and I

I have the same issue and I fixed it by disable the aggresive mode inbound with the command crypto ikev1 am-disable on any cisco ASA platform will work..

Hall of Fame Super Silver

That is good to know. Thank

That is good to know. Thank you for posting it to this discussion.

HTH

Rick

6732
Views
0
Helpful
20
Replies