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

From: Thor Lancelot Simon <[email-masked]>
Date: Fri, 12 Dec 2003 18:36:45 -0500

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	                                      [email-masked]
   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

---

From: Thor Lancelot Simon <[email-masked]>
Date: Sat, 13 Dec 2003 00:53:26 -0500

> I should send it here anyway; so that's what I'm doing.

Just to provide another example of just how badly some vendors -- or,
at least, their sales/marketing folks -- Don't Get It, and just how
they're likely to try to wiggle through holes in even the most carefully
constructed protocols to inflict dangerous "solutions" on their customers
while claiming to have implemented what the IETF specified: here's Cisco's
response to my raising the XAUTH issue on Bugtraq, followed by my response
to it.

In fairness to Cisco, it turns out that between my originally pointing out
the "authenticate the DN, not the CA!" issue to them and the present time,
they did eventually fix that problem, and make a note of it in the 
appropriate places.  But the lengths of rationalization to which some folks
will go in order to justify dangerous use of protocol "extensions" that
weren't accepted is pretty scary.

Perhaps the next time something like XAUTH is proposed, the standard it
impacts should be explicitly revised to MUST NOT some of the dangerous
things it does.  At least that way the implementations in question could
not claim to conform to the standard.

On Fri, Dec 12, 2003 at 09:10:50PM -0800, Sharad Ahlawat wrote:
> 
> Issue #2: This is a widely known common aspect of the Pre Shared Keys (PSK) 
> authentication mechanism since 1999. With PSK, there is no way for a client 
> to identify what is on the other side of the connection except that the other 
> side has the same PSK.

Sharad's (Cisco's?) highly disingenuous claim is completely false.

In fact, the security vulnerability in question is caused by Cisco's 
decision to deliberately *misuse* the preshared key authentication method 
of IKE, in combination with the very dangerous XAUTH extension to IKE which 
was not accepted by the IETF IPsec wworking group.

As is specified by the relevant standards and as was pointed out in the
working group while XAUTH was under discussion, the entire security of
the PSK authentication method relies upon the fact that these keys are,
in fact, a shared secret between the two IPsec peers -- *not* a "VPN
server" and an arbitrary number of "clients".  In combination with the
rejected XAUTH extension, the misuse of PSK that Cisco advocates and
supports is particularly dangerous because it leads to the disclosure of
persistent authentication information such as user passwords.

Indeed, with preshared key authentication, there is no way for a client
to identify what is on the other side of the connection except that the
other side has the same preshared key.  That much is intrinsic to the
design of the protocol *and is why only two parties must ever have
knowledge of any single preshared key*.  

Yet Cisco deliberately chooses to *recommend* to its customers an IKE
configuration in which many parties use the same preshared key, and,
even worse, use that key to "protect" the dangerous and nonstandard
XAUTH exchange in which the client will give password or other legacy
authentication information to the other end with no guarantee of what,
exactly, that other end might be.

In other words, Sharad confirms that Cisco knows just how dangerous
this is, while glossing over the fact that Cisco sales engineers and
other field personnel continue to *recommend* this configuration to
customers.  Indeed, if this configuration is so widely understood to
be dangerous, why does the Cisco client software even support it,
even going so far as to gloss over the fact that a preshared key is
being used by more than two parties by calling it a "group password"?

Thor

---

From: Henry Spencer <[email-masked]>
Date: Sat, 13 Dec 2003 19:46:35 -0500 (EST)

On Fri, 12 Dec 2003, Thor Lancelot Simon wrote:
> 1) Configuration *really matters*...

When I started working with the FreeS/WAN project, upper management made a
big point that there should (ideally) be *no way* to misconfigure the
software to give a false appearance of security:  communications should
fail, or be obviously insecure, or be truly and thoroughly secure.  The
more I worked with the project, and dealt with real-user problems, the
more strongly I agreed with this. 

Yes, misconfiguration is "pilot error"... but many cases of pilot error
are really due, at least in part, to error-prone interfaces which make it
too easy for tired, stressed people to make lethal mistakes.  Engineering
the failure modes out is much more effective than exhorting people to make
fewer mistakes. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Marcus D. Leech" <[email-masked]>
Date: Sun, 14 Dec 2003 19:23:24 -0500

> the failure modes out is much more effective than exhorting people to make

I don't think that what Thor is talking about in the second case--the
  use of XAUTH and "group keys" is a "misconfiguration" in the
conventional
  sense.  Large organizations have deployed that particular mistake,
with
  nearly-full understanding of the truly-horrible security implications.

Yes, software needs to make it difficult to do truly stupid things, and
  the various horrible "group shared key" abominations in various
  XAUTH variants count as the *software* being unsufficiently clueful.
  But in the end, humans can hang themselves with quite small ropes...

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Advisor                                  Phone: (ESN) 393-9145  +1 613
763 9145
Security Architecture and Planning       Fax:   (ESN) 393-2754  +1 613
763 2754
Nortel Networks                          [email-masked]
-----------------Expressed opinions are my own, not my employer's------