Onderwerp: Cracking preshared keys

Hi,

we would like to announce the publication of a proof of concept paper 'PSK
cracking using IKE Aggressive Mode'. Paper can be downloaded from
www.ernw.de/download/pskattack.pdf .

The theoretical vulnerability about this topic is not new. While we were
preparing a talk about VPN hacking we configured the lab that is described
in the paper to do some kind of demonstration. We were able to capture and
crack successfully PSKs of a cisco router due to the issue that the cisco
router switches automatically to aggressive mode if the initiating clients
demands it.

This attack depends on some conditions on the vpn gateway.

1. Preshared keys are use for authentication
2. The vpn gateway must allow any ip address to establish a vpn connection
3. The vpn gateway must support aggressive mode
4. Of course the psk must be weak to crack it in an acceptable amount of time

Under these circimstances it's possible to capture and crack the preshared
key of a vpn gateway and gain unauthorized access to private networks.

To prevent your vpn gateways from being compromised we suggest the
following actions:
- Don't use preshared key for authentication, if its possible. Otherwise
ensure that you use very strong keys.
- If possible, don't allow vpn connections from any ip address (difficult,
I know).
- Disable aggressive mode, if it's supported (for example in Checkpoint
Firewall-1 where it's disabled per default).

cheers
Michael




ERNW Enno Rey Netzwerke GmbH - Zaehringerstr. 46 - 69115 Heidelberg
Tel. +49 6221 480390 - Fax +49 6221 419008 - Mobil +49 173 6745903

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is in response to the mail of mthumann@ernw.de from ERNW Gmbh
posted on 2003-Apr-23:

At 11:35 23/04/2003 +0100, Michael Thumann wrote:
>we would like to announce the publication of a proof of concept paper=20
>'PSK cracking using IKE Aggressive Mode'. Paper can be downloaded from
>www.ernw.de/download/pskattack.pdf .

The mail itself can be found at=20
http://www.securityfocus.com/archive/1/319487

This text can be found at
http://www.cisco.com/warp/public/707...30422-ike.html

IKE (Internet Key Exchange) is used during Phase 1 and Phase 2 of=20
establishing an IPSec connection. Phase 1 is where the two ISA KMP=20
(Internet Security Association and Key Management Protocol) peers=20
establish a secure, authenticated channel with which to communicate.
This is called the ISAKMP Security Association (SA). "Main Mode"=20
and "Aggressive Mode" each accomplish a Phase 1 exchange. Each=20
generates authenticated keying material from an ephemeral=20
Diffie-Hellman exchange. Every participant in IKE must possess a=20
key which may be either pre-shared (PSK) or a public key. There=20
are inherent risks to configurations that use pre-shared keys which
are exaggerated when Aggressive Mode is used.

When responding to IPSec session initialization, Cisco IOS=AE software
may use Aggressive Mode even if it has not been explicitly configured
to do so. Cisco IOS software initially tries to negotiate using Main=20
Mode but, failing that, resorts to Aggressive Mode.

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=20
(brute force) attack on the pre-shared keys. The detailed analysis of
the attack is given in the article by John Pliam. The article is=20
located at http://www.ima.umn.edu/~pliam/xauth/. Although this article
is about Aggressive Mode, the thread referenced below also contains
references to Main Mode.

Please note that this attack method has been known and discussed=20
within the IETF IPSec Working Group. You can find the thread at
http://www.vpnc.org/ietf-ipsec/99.ip...rd2.html#01451 (Subject:=20
Weak authentication in Xauth and IKE). The IPSec Working Group has=20
understood and acknowledged this attack avenue, but has deemed that=20
this is an acceptable risk. There are public information-gathering=20
tools which target IPSec session initiation and brute-force the=20
pre-shared key. One of them can be found at=20
http://ikecrack.sourceforge.net/=20

The most exposed users are those who use IPSec to connect to=20
internal resources across a hostile network (for example, a
sales person visiting a customer). The entire session may be=20
intercepted on the hostile network and manipulated while the user
is unaware of such activity. Note that the recorded session (the=20
one that was used to discover PSK) cannot be decrypted. It is still
protected by the ephemeral Diffie-Hellman key exchange. An adversary
can either use a pre-shared key to impersonate a trusted user and=20
connect to the protected network, or it can mount an active=20
Man-in-The-Middle (MiTM) attack on any new session. Another high-risk
scenario is group pre-shared keys, that is, a single shared key is=20
assigned to all dial-in users.

Please note that the same class of attack is possible even if=20
Xauth (Extended Authentication) is used. This is because Xauth is=20
performed after Phase 1 is completed and, for this attack, an adversary
needs only a packet from Phase 1. Furthermore, after the pre-shared=20
key has been discovered, an adversary can mount an active MiTM attack
on Xauth. The outcome depends on the exact authentication method used
in Xauth.

Mitigation of this risk is to use, as long as practical, strong=20
pre-shared keys, and to change them frequently. In Cisco IOS software,=20
the PSK can be up to 128 characters in length. According to some=20
estimates, one character carries from 1.3 to up to 4 bits of entropy.=20
This means that the password can have, at maximum, anywhere from 166=20
to 512 bits of entropy. The length of the PSK should be determined=20
by your security policy.

Gaus

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3

iQA/AwUBPqbthnsxqM8ytrWQEQKQWQCg+wMymcQM1/u4xW30utf8I8Cr9lcAoKlW
pUqNA1rS3fT4kjD58GVJ5sZ/
=3D2/U9
-----END PGP SIGNATURE-----
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt> Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
There are no insolvable problems.=20
The question is can you accept the solution?=20

Michael Thumann wrote:
>we would like to announce the publication of a proof of concept paper 'PSK
>cracking using IKE Aggressive Mode'. Paper can be downloaded from
>www.ernw.de/download/pskattack.pdf .
[...]
>4. Of course the psk must be weak to crack it in an acceptable amount of time

Well, what did you expect? In your example, the pre-shared key was
derived from the ``secret'' string "cisco". Of course, if you choose
a key that the attacker can guess, the system won't be secure. Surprise!

What do you expect IPSec to do if you give it an insecure, guessable key?
Noone claimed it would be secure in such a situation.

I find your recommendations hard to take seriously. This is not a
vulnerability in IPSec, a good reason to disable vpn access, or anything
like that. Just use some common sense in how you use the crypto. If you
must use pre-shared keys, choose strong keys; or, use public keys instead
of pre-shared keying. Surely you agree?

User: "Doctor, doctor, it hurts when I use insecure crypto keys."
Doctor: "Don't do that, then."

> Mitigation of this risk is to use, as long as practical, strong
> pre-shared keys, and to change them frequently. In Cisco IOS
software,
> the PSK can be up to 128 characters in length. According to
some
> estimates, one character carries from 1.3 to up to 4 bits of
entropy.
> This means that the password can have, at maximum, anywhere
from 166
> to 512 bits of entropy. The length of the PSK should be
determined
> by your security policy.

Just an interesting note about the above comment.

By generating 93 bytes of "cryptographic calibre" randomness, and
then base64 encoding it, you will have a password that has 744
(93*8) bits of entropy, but is 128 bytes long. If a more
efficient encoding mechanism is used (one that uses the full
valid character set on a cisco, which I don't know personally) a
larger key could potentially be generated.

If a strong key such as the one described above is used,
according to some estimates, this will take a _very_ long time to
brute force.

Cheers,
Derek

Noone was talkig about that IPSec isn't secure because of this attack
scenario. We gave recommendations how to configure IPSec in a secure way
with a proof of concept what might happen, if you don't. The described
attack won't work too, if aggressive mode can be disabled as for example in
Checkpoint FW-1, so it doens't depend only on a crackable PSK.

Using this attack every PSK is crackable, but good ones aren't crackable in
an acceptable amount of time. I don't want to start another discussion
about how to choose good password or preshared keys, I totally agree that
you get a lot of security when you choose strong ones, but if you take a
look at SANS TOP 20 ( http://www.sans.org/top20/ ) you can see that's still
one of the most common problems in praxis.

So I think, that you can see that we don't have different point of views
how to configure secure VPNs ;-)

At 00:08 24.04.03 +0000, David Wagner wrote:
>Michael Thumann wrote:
> >we would like to announce the publication of a proof of concept paper 'PSK
> >cracking using IKE Aggressive Mode'. Paper can be downloaded from
> >www.ernw.de/download/pskattack.pdf .
>[...]
> >4. Of course the psk must be weak to crack it in an acceptable amount of
> time
>
>Well, what did you expect? In your example, the pre-shared key was
>derived from the ``secret'' string "cisco". Of course, if you choose
>a key that the attacker can guess, the system won't be secure. Surprise!
>
>What do you expect IPSec to do if you give it an insecure, guessable key?
>Noone claimed it would be secure in such a situation.
>
>I find your recommendations hard to take seriously. This is not a
>vulnerability in IPSec, a good reason to disable vpn access, or anything
>like that. Just use some common sense in how you use the crypto. If you
>must use pre-shared keys, choose strong keys; or, use public keys instead
>of pre-shared keying. Surely you agree?
>
>User: "Doctor, doctor, it hurts when I use insecure crypto keys."
>Doctor: "Don't do that, then."

----------------------------------------------------------------------------------------------------
Michael Thumann mlthumann@ids-guide www.ids-guide.de
Public Key available at http://www.ids-guide.de/MichaelThumann.asc
----------------------------------------------------------------------------------------------------
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location...and i'm not
even too sure about that one
--Dennis
Huges, FBI.

Michael Thumann wrote:
> To get the XAUTH based authentication information (that is the part
> where the RADIUS Server is involved) you must start a man in the middle
> attack and this MITM attack is only possible when you've already cracked
> the preconfigured preshared key and when you are in physical position to
> perform a MITM attack (that's really not too easy).
>
> Hope that helps ;-

I'm not sure that XAUTH is the same as the "IKE Shared Secret AAA".
I got the impression from the Cisco docs that with the latter,
either the Radius password or something derived from it was used to
create the shared key for the initial Diffie-Hellman exchange.

I've documented my (probably faulty) understanding of the
process here:

http://www.jmu.edu/computing/security/vpnauth.shtml

Thanks for any clarity you can lend.

--
Gary Flynn
Security Engineer - Technical Services
James Madison University

Please R.U.N.S.A.F.E.
http://www.jmu.edu/computing/runsafe

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 =20

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].=20
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

Damir Rajnovic wrote:

>Please note that the same class of attack is possible even if
>Xauth (Extended Authentication) is used. This is because Xauth is
>performed after Phase 1 is completed and, for this attack, an adversary
>needs only a packet from Phase 1. Furthermore, after the pre-shared
>key has been discovered, an adversary can mount an active MiTM attack
>on Xauth. The outcome depends on the exact authentication method used
>in Xauth.
>
May I ask how this applies to "IKE Shared Secret AAA"?
If a Radius backend authenticator is used, is the shared key
that is vulnerable one preconfigured in the VPN hosts or one
based on the Radius password? The reason I ask is that the
preconfigured shared key can easily be lengthened but the
backend password, if based on end user passwords, is not
as easy a solution.

Thank you.

Gary Flynn
Security Engineer - James Madison University

To get the XAUTH based authentication information (that is the part where
the RADIUS Server is involved) you must start a man in the middle attack
and this MITM attack is only possible when you've already cracked the
preconfigured preshared key and when you are in physical position to
perform a MITM attack (that's really not too easy).

Hope that helps ;-

At 21:10 23.04.03 -0400, Gary Flynn wrote:
>Damir Rajnovic wrote:
>
>>Please note that the same class of attack is possible even if Xauth
>>(Extended Authentication) is used. This is because Xauth is performed
>>after Phase 1 is completed and, for this attack, an adversary
>>needs only a packet from Phase 1. Furthermore, after the pre-shared key
>>has been discovered, an adversary can mount an active MiTM attack
>>on Xauth. The outcome depends on the exact authentication method used
>>in Xauth.
>May I ask how this applies to "IKE Shared Secret AAA"?
>If a Radius backend authenticator is used, is the shared key
>that is vulnerable one preconfigured in the VPN hosts or one
>based on the Radius password? The reason I ask is that the
>preconfigured shared key can easily be lengthened but the
>backend password, if based on end user passwords, is not
>as easy a solution.
>
>Thank you.
>
>Gary Flynn
>Security Engineer - James Madison University
>


ERNW Enno Rey Netzwerke GmbH - Zaehringerstr. 46 - 69115 Heidelberg
Tel. +49 6221 480390 - Fax +49 6221 419008 - Mobil +49 173 6745903

On Thu, 24 Apr 2003, David Wagner wrote:

> Michael Thumann wrote:
> >4. Of course the psk must be weak to crack it in an acceptable amount of time
>
> What do you expect IPSec to do if you give it an insecure, guessable key?
> Noone claimed it would be secure in such a situation.
>
> I find your recommendations hard to take seriously. This is not a
> vulnerability in IPSec....

You seem to have missed the vulnerability. The vulnerability is *not* that,
if you use a weak key, an attacker has a better chance of guessing it. The
vulnerability is that you are giving away information that allows him to
test his guesses on his own, rather than by using your system to test the
keys.

In the former case, you have no idea that an attack is occurring. In the
later case, you can determine from the number of failed authentication
attempts that an attack is likely occurring, and take measures (such as
"locking" the account under attack, blocking that range of IP addresses,
or making any request from that range fail whether the secret is correct
or not). You can also greatly slow the rate at which the attacker can
make guesses by controlling the rate at which you will respond to
authentication requests.

Keep in mind that, even if you use very secure keys, there is still a
(small) chance that an attacker could guess your key anyway, just by
trying random keys for a while. Having other methods in place, as well
as secure key, will help in your defense.

cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC

In-Reply-To: <4.3.2.7.2.20030423203906.06148110@ca-uk-fs.cisco.com>

A friend of mine from Checkpoint has told me that this is not totally
correct and due to many political issues within the different IETF task
forces CheckPoint's Hybrid mode was never made into an RFC.

See:
http://www.ietf.org/proceedings/99no...isakmp-hybrid-
auth-02.txt for more details.

-Hank

>Weak authentication in Xauth and IKE). The IPSec Working Group has=20
>understood and acknowledged this attack avenue, but has deemed that=20
>this is an acceptable risk.
> Gaus

> I find your recommendations hard to take seriously. This is not a
> vulnerability in IPSec, a good reason to disable vpn access, or anything
> like that. Just use some common sense in how you use the crypto. If you
> must use pre-shared keys, choose strong keys; or, use public keys instead
> of pre-shared keying. Surely you agree?

Third option: there are some IPSEC implementations (such as
Linksys' BEFVP41 vpn router) which blacklist the attacker's IP
for a given amount of time when wrong PSK count overpasses
a threshold. It takes an eternity to try many combinations though

just my .02 eurocents

--
Stefan Laudat
CCNA & CCAI
-------------
Marriage is the only adventure open to the cowardly.
-- Voltaire