Multiple vulnerabilites in vendor IKE implementations, including Cisco,

[Thor Lancelot Simon <tls () rek tjls com>]

Nortel, and Microsoft
Reply-To: tls () rek tjls com

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