[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How IKE is sometimes (mis-)used in the real world.



This is a copy of a message I sent to BUGTRAQ earlier today.  It is
written for a significantly less technical and less IPsec-savvy
audience than the usual suspects on this list but a few people sugested
I should send it here anyway; so that's what I'm doing.

If you're looking for the followup discussion in the BUGTRAQ archive,
note that it's gotten mis-threaded somehow.  The original message is
at http://www.securityfocus.com/archive/1/347351 but some of the
responses have been threaded onto
http://www.securityfocus.com/archive/1/347392, I guess because
the Subject: line changed.

Ultimately, I'd call the lessons of this silliness twofold:

1) Configuration *really matters*.  It may be that protocol documents
   should specifically advise against particularly stupid ways to use
   seemingly obvious protocol features, e.g. using certificate 
   authentication but authenticating a CA instead of a DN.

2) Letting really bad protocol extensions "die on the vine" may not be
   enough.  XAUTH has done a lot of damage in a number of ways and it
   may be that there should be explicit advice to _not_ implement
   certain extensions to standards-track protocols that are known to
   compromise those protocols' design goals (e.g. mutual authentication).


------------------------

INTRODUCTION

This message will describe two serious vulnerabilities in the default
configurations of IKE implementations.  They are particularly common in
so called "VPN client" implementations.  Both allow easy session stealing 
and man-in-the-middle attacks; one allows the persistent authenticator
for the client (e.g. a password) to be stolen.

I used to maintain the IKE implementation at an IPsec vendor.  While doing
interoperability testing with other implementations, we discovered that the
default configurations of those implementations were horribly insecure.
Worse, we discovered that some implementations could *only* run in insecure
configurations!

I disclosed the problems to several relevant vendors.  Since I'm singling
a few companies out for criticism here, I'll single one out for praise:
Certicom.  I described one of the issues to them and they proposed a fix
the next day, and implemented it.  But the experience elsewhere was not
so good!

In fact, I have recently heard first-hand of multiple Cisco sales engineers 
strongly pushing a vulnerable configuration on a customer who stood to 
expose thousands of Kerberos passwords were they to use it; I hope that 
this message helps to stop such irresponsible actions.

The first issue is relatively simple, and is explained in a short, direct
manner.  The second is not too complex technically either but requires some
understanding of the way the IKE protocol works to really understand.  I
have made the explanation rather lengthy, nontechnical, and folksy, because
I suspect it's the sort of thing one would want to show his boss.

I know of at least one version of one "VPN client" IKE implementation that
*can not be configured* to not suffer from one or the other of these two
issues.

	ISSUE 1: VALIDATION OF CERTIFICATE AUTHORITY RATHER THAN IDENTITY
		 SIGNED FOR BY AUTHORITY IN CERTIFICATE ALLOWS SESSION
		 STEALING OR "SERVER" IMPERSONATION

	The fundamental issue here is that some implementations allow the
	user to specify only the name of the *certificate authority* that
	must have signed the certificate for the peer, not the actual
	name of the peer that should appear in the certificate.

	"But," you may say, "My VPN gateway assigns an IP address and
	traffic filtering policy based on the name (DN) in the certificate,
	so I'm safe!"

	Wrong.  You aren't, not if you use the same certificate authority
	for the "client" certs and the "server" cert.  Why not?  Because
	*every client has a certificate signed by the same CA as the
	server, and that's all that the other clients will check*.  So,
	the attacker need only:

	1) Impersonate the server's IP address: come on, if this weren't
	   a concern, we wouldn't be using IPsec at all, so we have to
	   assume it's trivial.

	2) Present the other client with *any valid client certificate at
	   all*.  It will be accepted as if it were the *server's*
	   certificate, because it's signed by the right CA!

	3) Use that same client certificate to negotiate IKE with the
	   real server.

	4) MITM all of the hapless client's traffic.  Whoops.

	Analogy: implementations that allow this attack are like banks
	that let you withdraw all of the money from anyone's account,
	at all, just because you have a passbook for the same type of
	account you're claiming to be the signer for, without checking
	the name in the passbook or even looking at your signature.

		PARTICULAR CONCERNS:

		1) Implementations that "loosely" bind IP addresses to
		   identities.  Such implementations allow stealing of 
		   sessions without bothering to impersonate the server, by 
		   doing a first, out-of-band authentication step, then doing
		   IKE, but accepting any valid certificate in that
		   IKE session, or perhaps by letting any valid certificate
		   negotiate IKE, then doing user authentication "secured
		   by IPsec" (let's say with a web browser), *then allowing
		   any valid certificate from the right CA to renegotiate
		   IKE, including Phase 1, thereby stealing all of the
		   authenticated user's state, including IP address and
		   TCP sessions!*

		2) Implementations that *cannot* be configured to use a
		   different CA for client and server.  These are a
		   special case, and are even worse than implementations
		   that don't check the name in the certificate because it
		   is *impossible* to use them to do anything secure: you
		   *cannot* use the workaround of using a CA for the server
		   that never signs any certificate but the server's
		   certificate, thus guaranteeing that the server's identity
		   can't be spoofed towards the client.

		   The IKE implementation in Windows 2000 SP2+ and XP is
		   of this type.

	ISSUE 2: USE OF THE IETF-REJECTED "XAUTH" IKE EXTENSION WITH
	IKE ITSELF AUTHENTICATED ONLY BY A PRESHARED KEY SHARED BY MORE
	THAN TWO PARTIES  (A.K.A. "THE 'GROUP PASSWORD' OR 'XAUTH' HOLE).

	This one is particularly bad because it allows the stealing of
	persisitent user authenticators.  Worse, it is the default
	configuration of many "VPN client" IPsec implementations.

	To understand this attack you need to understand a little bit
	about IKE -- but not tremendously much (whereas the first attack
	just exploited a thoroughly mindless misuse of certificate-based
	authentication and required only an understanding of identities
	to grasp).

	[I'm going to gloss over some details here; I hope my fellow IKE
	implementators will forgive me.]

	The IKE standard is very flexible, separating the keying of the
	actual message-encryption and message-authentication algorithms
	used in IPsec (ESP and optionally AH) into two "phases".

	In the first phase ("Phase 1"), the identities of the parties 
	negotiating the keys are exchanged and validated, and secrets used 
	to encrypt and authenticate future exchanges of keys are negotiated.

	In the second phase ("Phase 2"), keys for the actual algorithms 
	used to protect normal (non-IKE) IP traffic are exchanged.

	Phase 2 is pretty simple, and doesn't concern us right now.  One
	neat thing about the protocol is that you can (and usually do)
	perform Phase 2 many times under the protection of a single Phase
	1 "security association" ("SA"), which is the fancy name for "those
	secrets we negotiated to encrypt and authenticate future exchanges
	with".  The only place the parties negotiating the keys really prove
	their identities is in Phase 1; having proven that, they can do 
	Phase 2 repeatedly knowing that they're talking to the right guy.

	Consequently, it is in Phase 1 that the identities of the parties
	are exchanged in a form that human beings would recognize.  IP
	addresses, domain names, or the name of a human being or another
	entitity as expressed in an X.509 certificate -- roughly, who you 
	are, where you work, what your address is, and so forth.

	Notice that that list in the last paragraph did *not* include
	"an arbitrary username".  That will be important later in this
	discussion.
	
	IKE is designed for use on the Internet, and the Internet is a very
	dangerous place indeed.  People use it on wireless networks, even,
	where it's trivial to impersonate any "server" you want to just by
	having a stronger radio signal.  So there is a *very* real
	possibility that someone may be impersonating what you think of as 
	the "server" side of your IKE negotiation, and the protocol is 
	designed to protect you from giving your password ("preshared key", 
	in IPsec talk) to an imposter.

	That's why IKE authenticates the "server" just like it authenticates
	the "client".  Indeed, IKE doesn't talk about "server" and "client";
	it just talks about a "peer", because both ends are authenticated the
	same way.

	Nonstandard IKE implementations that use the rejected "XAUTH"
	extension throw all of that away, and allow any "server" to steal
	secrets from the "clients".  Here's how.

	Usually, if you're not using certificates, IKE is authenticated
	with a passphrase -- a "preshared key" or "PSK" shared by both ends.
	In the certificate case, the first messages in the protocol that
	prove that John is John and that JohnCo's VPN server is JohnCo's
	VPN server sign a bunch of stuff exchanged earlier -- if John
	started the negotiation, his signature produces "SIG_I", and the
	server's produces "SIG_R".

	In the preshared-key form of the protocol, something very roughly
	like CHAP is done, instead.  John takes a bunch of stuff, some
	generated by him and some generated by the JohnCo VPN server, and
	encrypts ("hashes") it with the secret key, producing "HASH_I"
	and proving that he has the secret key.  The JohnCo VPN server
	takes some other stuff, encrypts it with the secret key, producing
	"HASH_R", and thus proves that _it_ has the secret key.  Since only
	John and the JohnCo VPN server have that key, the exchange is
	secure, and they know they're talking to the right guys at the other
	end.

	The security of the entire rest of the IKE protocol -- and thus of
	all of IPsec itself -- relies on this proof: that John and his
	VPN server have the same secret key, and that they're the only ones
	who have it.

	Let's consider what would happen if John, Bob, Bill, Joe, and Steve
	all had the secret key.  Now, when John connected to what he thought
	was the JohnCo VPN server, it could actually be Bob, Bill, Joe, or
	Steve instead.  How would he know?  He wouldn't.  The attacker could
	just turn around and negotiate with the *real* server behind John's
	back, and do anything he wanted to with John's traffic -- read it,
	change it, anything.

	That's bad enough.  But what the typical "VPN client" implementation
	does is even worse.

	How does the VPN server know which preshared key to use to decrypt
	that HASH_I message from the client?  If it had a "username" as the
	identity, we'd be getting somewhere -- it could look up the right
	preshared key, and away we go.  But it doesn't.  Instead, it has an
	IP address -- and in the modern Internet, users' IP addresses change
	all the time.  Uh oh.  So when it gets to the first encrypted message
	of the protocol, what does it do?

	The real answer is, "if you want to do authentication based on the
	identities of human beings, not IP addresses, use certificates; they
	have a *name* in them!"  But in practice, there are some workarounds.

	The one that's reasonably secure is to exchange a single-use-only
	preshared key using another secure channel, such as an an SSL-
	protected web page.  You bind the IP address and that one-time-only
	password together, and you know who you're talking to and can prove
	that he's him.  The "PIC" protocol does something like this with
	short-lived certificates.

	What's *not* secure is to use XAUTH, an extension to IKE that was
	not accepted by the IETF working group to which it was proposed.

	What XAUTH does is a username/password exchange *after* the Phase 1
	IPsec protocol has already started up.  Every user uses the *same*
	preshared key to talk to the server.  So, as we know from the
	discussion above, at this point the server knows only that the user
	is one of Bob, Bill, Joe, Steve, etc. -- and the user doesn't know
	if he's talking to the server or to some other user who happens to
	be using the server's IP address.  That's why implementations that
	do XAUTH call the preshared key the "group password".  Oh, sure, it
	authenticates to the server that one of a given "group" of users is
	talking to it -- but it doesn't authenticate anything to the client
	*at all*.  The client could be talking to anyone; no way to know.

	*Then*, in XAUTH, a username and a secondary authenticator are
	exchanged -- but *only for the client*.  That is, the client
	tells the server what his username is; the server may challenge
	him, for example for a SecureID token value or one-time-password,
	but usually instead for a plain, old reusable password.  And the
	client goes ahead and supplies it.  Then the "Phase 1" security
	association is established, and the rest of keying occurs.

	Whoops.  Keying *with what system, exactly, at the other end*?
	The client has no way to know, so he's subject to all that whole
	set of ugly session stealing, traffic sniffing, etc. attacks.  But
	it gets worse.  In this attack, the fake server has got something
	much more valuable than the user's traffic for the duration of
	*this* session: he has an authenticator that he can use to talk
	to the *real* server *as the victim of the attack* at the very
	least right away, and perhaps indefinitely.

	Remember, the extra exchange added by XAUTH was only the "client"
	sending his password to the "server".  So the client has no extra
	authenticator for the server -- it could be Bill, Joe, Bob, Steve...
	and whoever it is, that guy's got what the client sent in the XAUTH
	exchange now!

	If it's a SecureID token or a one-time password, it's probably
	only useful just for this session.  That's still valuable: the
	attacker can do the attack with essentially no risk of detection,
	since he will authenticate to the real server as the real client.

	But if it's a password... my, oh my.  The attacker now has the
	victim's password, and can use it for whatever he wants.  He can
	negotiate lots of IKE sessions -- but he can probably read the
	client's email, too; authenticate to the company's remote-desktop
	service, maybe -- the possibilities are truly endless.

	This is worst at sites with large databases of legacy 
	authentication information that use passwords as the principal
	authenticator.  For example, at MIT, everything you do is
	authenticated using your Kerberos password.  Were MIT to install
	a Cisco VPN concentrator in the usual, recommended configuration
	(which MIT's networking folks are probably smart enough to not
	do!) any user *at all* could systematically steal everyone else's
	Kerberos passwords, wait a while, and wreak absolute havoc as any
	other student, faculty, or staff member he liked, on whatever o
	campus system.

	Worse, some universities are migrating away from systems like
	Kerberos and setting up in-house certificate authorities.  Guess
	what authenticates a user to the system that provides him with
	his certificate?  You guessed it: his Kerberos password.  So an
	attacker can silently practice the XAUTH attack on a VPN
	concentrator and then bootstrap himself into ownership of a
	certificate that says he's the victim.

SUMMARY AND DISCUSSION

VPN technology is an important tool for securing private networks and the
Internet.  Both for VPN and peer-to-peer use, IPsec is *by far* the most 
comprehensive, best-designed, best-understood, and most secure protocol 
in common use.  By this I mean *actual IPsec that conforms to the relevant
standards* -- there's all kinds of garbage floating around out there like
XAUTH that is not really IPsec and should be vigorously avoided.  Customers
should insist that they're getting actual IPsec, not some miscellaneous bag
of dubious vendor extensions that might do things like give away their
passwords.

Finally, this highlights the importance at looking at vendor documentation
and, in particular, default configurations, very carefully.  All that's
required to discover that many implementations have the first hole I
describe is to ask the question "what can I actually know about the guy
on the other end if all I have is the name of a CA in my configuration
dialog"?  The answer is, of course "that he's somebody the CA signed a
certificate for" -- but since you never get to enter *which somebody you
are expecting to talk to* you can know _a priori_ that your software isn't
going to concern itself with that.  Uh-oh...

It is my hope that this message shames some vendors into smartening up and
doing the right thing.  But I am not too sanguine about that prospect.  It
is also my hope that this message makes some *customers* bludgeon their
vendors into not compromising the security of their networks.

Oh, and how hard is it to practice these attacks?  Downright simple.  To
do the first one, you need nothing but a standard IKE implementation --
any implementation, at all.  To do the second, you need an implementation
that does XAUTH -- but guess what?  The open-source "VPNC" software for
talking to Cisco VPN concentrators can do that.  We're talking total kid
stuff here; the attacks can be implemented as *shell scripts* given a
sufficiently flexible IKE, or with a tiny, tiny amount of modification
to an existing open-source IKE otherwise.

"Have fun!"

Thor


-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud