Multiple vulnerabilites in vendor IKE implementations, including Cisco,
Nortel, and Microsoft
Reply-To: tls@xxxxxxxxxxxx
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