IKE Aggressive mode what is this?

Answered Question
Nov 2nd, 2007

Hi, I have just scanned one of our routers public address, this is a Cisco 877 ADSL router in VPN mode to a Cisco Concentrator and get this vulnerability, what does it mean?

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

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.

I have this problem too.
0 votes
Correct Answer by Richard Burts about 9 years 3 weeks ago

Andy

Thanks for the additional output. The presence of statements like this referencing Main Mode

Nov 5 19:12:42.702: ISAKMP:(0:21:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

and the lack of any messages referencing aggressive mode are proof that this connection does not use aggressive mode and thus the vulnerability is minimized.

HTH

Rick

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Paolo Bevilacqua Fri, 11/02/2007 - 08:58

Hi, they are just saying if your shared key is easy to guess, your are at risk. Not really any news so far. So they say:

Otherwise a strong pre-shared key should be chosen.

Hope this helps, please rate post it it does!

whiteford Fri, 11/02/2007 - 09:10

Thanks, thing is it's 11 letters long. It includes letters, numbers, capital letters and symbols.

Do I need to encrypt the config or something?

Richard Burts Fri, 11/02/2007 - 09:53

Andy

I do not believe that you need to encrypt the config or anything like that. As Paolo explains the "vulnerability" is about the ability to brute force attack (try to guess the passwords) and you are more vulnerable with weak pre-shared keys. If your key is 11 characters with letters, numbers, and symbols then it sounds pretty strong.

There are two modes of ISAKMP negotiation for phase 1 negotiation. They both achieve the same basic things but aggressive mode requires fewer message exchanges to do it. The vulnerability suggests that you not use aggressive mode. Your Cisco will use whichever mode is used on the device that connects. For site to site VPN aggressive mode is rarely used but for the client based remote access VPN aggressive mode is more common.

I really do not think that there is anything that you need to do about this.

HTH

Rick

whiteford Sat, 11/03/2007 - 03:48

Hi, how many letters do you normally use? An example of one I no longer use is - #p0pu1at10n

Is this ok?

whiteford Sat, 11/03/2007 - 03:51

How do I know if my router in site-to-site mode is or isn't connecting to our concentrator in aggressive mode?

Richard Burts Sun, 11/04/2007 - 03:54

Andy

In my experience IPSec connections from a router to a concentrator generally do not use agressive mode. I guess that if you want to be sure you would need to run debug on the IPSec negotiation.

HTH

Rick

whiteford Sun, 11/04/2007 - 05:08

Hi Rick, what is the command for that, i have looked for something like debug ipsec, bu no luck?

Thanks

Richard Burts Sun, 11/04/2007 - 08:04

Andy

It is a bit tricky to spot because the ipsec is a parameter behind crypto in the debug command. So try debug crypto ipsec.

HTH

Rick

whiteford Sun, 11/04/2007 - 08:57

Just tried "debug crypto ipsec" and stopped the VPN then started it again, but nothing appeared on the router, am I doing this right?

Richard Burts Sun, 11/04/2007 - 19:53

Andy

When you say that you stopped and started the VPN can you be specific about how you stopped it and restarted it? I would have thought that stopping and starting the VPN would have produced some debug output.

Also can you confirm that you had done terminal monitor before doing the debug and stopping and restarting the VPN? (or that you enabled logging buffered debug and then did show log after stopping and starting the VPN)

HTH

Rick

Richard Burts Mon, 11/05/2007 - 09:32

Andy

Thanks for posting the output. I am glad to see that it is now producing debug output.

I do not believe that there is aggressive mode in the negotiation. Looking at what I suggested I realize that I should have also suggested debug crypto isakmp to give a full picture of how the negotiation is being done. Can you also run debug crypto isakmp and post the output?

HTH

Rick

Correct Answer
Richard Burts Mon, 11/05/2007 - 11:46

Andy

Thanks for the additional output. The presence of statements like this referencing Main Mode

Nov 5 19:12:42.702: ISAKMP:(0:21:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

and the lack of any messages referencing aggressive mode are proof that this connection does not use aggressive mode and thus the vulnerability is minimized.

HTH

Rick

whiteford Mon, 11/05/2007 - 12:08

Thanks again Rick, however do you think this is anything to worry about:

Nov 5 19:12:42.702: ISAKMP:(0:21:SW:1): vendor ID seems Unity/DPD but major 194 mismatch

Richard Burts Mon, 11/05/2007 - 12:43

Andy

No it is not anything to worry about. I see it lots of times and have not yet found any negative impact from it. I believe that it is cosmetic.

HTH

Rick

Actions

This Discussion