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

[whiteford]

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.

[Richard Burts]

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

[whiteford]

it meets both your criteria and is 8 characters long.

[Richard Burts]

Andy

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

HTH

Rick

[whiteford]

Yeah, could false positive?

[sistematico]

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]

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]

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

[Steven Williams]

Both sides of the tunnel are using Main mode.

[Richard Burts]

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]

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]

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

[sindan]

CLI:  show vpn-sessiondb detail l2l

[Richard Burts]

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]

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.