[29886] in bugtraq

home help back first fref pref prev next nref lref last post

RE: Cracking preshared keys

daemon@ATHENA.MIT.EDU (Rager, Anton (Anton))
Thu Apr 24 18:12:09 2003

content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 24 Apr 2003 12:36:44 -0600
Message-ID: <088D5F677777E344A3DA3478DB305D11022CD80D@co9510avexu1.global.avaya.com>
From: "Rager, Anton (Anton)" <arager@avaya.com>
To: "David Wagner" <daw@mozart.cs.berkeley.edu>, <bugtraq@securityfocus.com>
Content-Transfer-Encoding: 8bit


It's amazing how many folks think that IPSec VPNs are not susceptible to password cracking.  I've run into many folks that just don't think about it -- They get distracted by the strength of DH, 3DES, and SHA1, but forget that the weakest link is the password. As Cisco and David Wagner point out, this is not a vulnerability in IPSec/IKE, but is something that I've seen many engineers gloss over. They think about NTLM or Unix hash cracking, but not IPSec.

That's why I wrote IKECrack in the first place -- how secure is a bazillion bit encrypted link that uses "test" as a PSK? I worked out the details of the crack process on my own a couple years ago, then later discovered the IETF and John Pliam had already discussed and decided that it wasn't a big deal. I still find the tool useful for pentesting, but decided it didn't need a detailed whitepaper :) 

I do find it surprising that the IKE PSK attacks have not been published more widely and am very surprised that the IETF didn't modify aggressive IKE to make it a bit more secure. [I think SonOfIKE addresses some of this, but most current implementations are the older IKE]  Example areas are ID revelation [I've seen vendors strengthen this by passing a hash of the ID], passive HASH collection/cracking due to PSK being only secret in HASH, and the fact that the gateway gives an active attacker a copy of the HASH before validating the user. Many vendors seem to have made IKE aggressive modifications that make passive attacks impossible [AFIK] by using additional secret info in the HASH calculations. This also has a side effect of making active attacks [or MITM] difficult because these modified HASH calcs are generally proprietary :)

As the Cisco response indicated, PSK cracking is not limited to just aggressive mode IKE. Main mode is also vulnerable, but requires a different technique. IKECrack doesn't currently perform the main-mode attacks, but here's an overview of how the process works:
1 - the attacker needs to be a MITM or an active attacker with one of the IPSec peers DoSed and the other re-initiating IKE
2 - the attacker participates in the DH process and collects Nonce values
3 - even though main mode protects the IDs, IDs are normally the IP addresses of each endpoint. Many IPSec devices [Cisco IOS excluded] don't even give the user the ability to override the IP based ID
4 - we now have everything we need [minus the PSK] to calculate the key material used for de-crypting the 1st encrypted frame [ID packet]. 
4 - Bruteforce/Dictionary for differing PSKs and try to decrypt to frame. We know most of the encrypted frame's contents, so validation is fairly straightforward.



The bottom line is this: If you use PSK auth with either main-mode or aggressive-mode, make sure you choose strong passwords. Best option is to avoid PSK and use stronger methods if possible. I don't agree that folks should scrap agressive-mode -- just be aware that UserIDs are leaked in the clear and weak passwords are crackable.

Anton Rager
Sr. Security Consultant
Avaya Enterprise Security Practice
arager@avaya.com

IKECrack author
http://ikecrack.sourceforge.net



home help back first fref pref prev next nref lref last post