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

Unanswered Question
Sep 17th, 2007

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Burts Mon, 09/17/2007 - 07:07

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

Richard Burts Mon, 09/17/2007 - 07:52

Andy

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

HTH

Rick

sistematico Fri, 08/05/2016 - 12:28

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..

rakesh_k_gupta Mon, 03/09/2015 - 22:29

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.

 

 

Richard Burts Tue, 03/10/2015 - 04:11

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

Richard Burts Mon, 05/11/2015 - 08:26

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

Steven Williams Mon, 05/11/2015 - 08:28

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.

Richard Burts Mon, 05/11/2015 - 08:43

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

Richard Burts Mon, 01/11/2016 - 10:56

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 

Ditmar Tavares Fri, 03/23/2012 - 12:38

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.

Richard Burts Tue, 02/10/2015 - 19:26

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

Steven Williams Tue, 02/24/2015 - 13:53

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?

Richard Burts Tue, 02/24/2015 - 14:20

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

sistematico Fri, 08/05/2016 - 12:28

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..

Richard Burts Fri, 08/05/2016 - 12:49

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

HTH

Rick

Actions

This Discussion