Re: Insecure IKE Implementations Clarification

[Thor Lancelot Simon]

On Fri, Dec 12, 2003 at 09:55:30AM -0700, Aaron Adams wrote:
> Hey Thor,
>
> I was just reading over your paper and noticed that you have not really
> included any specific implementations, aside from the "Windows 2000 SP2+
> and XP", that are vulnerable to these issues.
>
> Would it be possible for you to elaborate on which specific devices, Cisco
> for instance, you found to have these insecure implementations. Although
> the implications of such issues are quite high, without an idea of the
> number of vendors, and which vendor devices for that matter, are shipping
> with these types of implementations, it's difficult to accurately deduce
> the threat.
>
> Thanks a lot and I hope to hear from you soon.

[Perhaps it would be best for me to send this followup to the list. May
I copy your text there? I won't do so without your permission]

I'm at a bit of a disadvantage because I no longer work at the company
where I did most of the interoperability testing that turned up these
problems. There, I was keeping a running tally of which versions of
which implementations had these problems, but I don't have access to
it any more (I don't know if it even still exists).

The most glaring example of the first problem is indeed the Microsoft
IKE. However, *any* implementation that can be configured to connect
to a peer and check only the CA that signed the peer's certificate, not
the actual identity that was signed for, is vulnerable if so configured.

At least some versions of the Cisco and Nortel "VPN Client" stacks have
that flaw. Old versions of Certicom MovianVPN do, too, but Certicom
fixed that by printing the DN the first time the user connects to a
new peer and, after confirmation, saving it so that in the future only
the correct certificate will be accepted. Lots of other software had
this bug -- the example configurations that came with the FreeS/WAN
X.509 certificate patch had it, for example!

The second problem is generic to *any* IKE that can be configured to
use a "group password" and then send a second authenticator using XAUTH.

*This is probably the *most common* configuration of the Cisco "VPN client"
implementation that you will find deployed in the field*. That's no
surprise, because Cisco consultants, Cisco-trained consultants, and Cisco
sales engineers push it on customers heavily as a panacea for bootstrapping
a VPN using only a legacy authentication database.

Software that can interoperate with Cisco VPN servers as the peer, using
XAUTH, is also vulnerable. That includes a lot of aftermarket "VPN
client" implementations -- off the top of my head, SafeNet, MovianVPN,
maybe the Funk AdmitOne client for handhelds -- all the usual suspects.

The key thing to understand is that using XAUTH at all basically
_presumes_ the model of use that suffers from this bug. And if the user
is entering a "group password" *and* a username/password you can be sure
that, indeed, XAUTH is in use... ugh.

A related but slightly less severe problem impacts the combination of
XAUTH with public-key authentication, but the big bad one is the combo
of XAUTH and "group passwords".

The Nortel connetivity client does, or did, something else funky to
bootstrap IKE from a legacy authenticator, computing HASH_I in a very
strange, nonstandard way. That _may_ be more secure, but I am suspicious.
It is also not really publically documented so to analyze it would require
disassembling the Nortel implementation; ugh. However, though I do not
have one here to check, it is my strong impression that modern versions of
the Nortel client use, at least as an alternative, methods that suffer
from one or the other of the two bugs I described instead.

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

[Florian Weimer]

Thor Lancelot Simon wrote:

> The second problem is generic to *any* IKE that can be configured to
> use a "group password" and then send a second authenticator using XAUTH.
>
> *This is probably the *most common* configuration of the Cisco "VPN client"
> implementation that you will find deployed in the field*. That's no
> surprise, because Cisco consultants, Cisco-trained consultants, and Cisco
> sales engineers push it on customers heavily as a panacea for bootstrapping
> a VPN using only a legacy authentication database.

There's also a PSIRT statement regarding this issue, and it's at best
embarrassing for Cisco engineering folks:

<http://www.cisco.com/warp/public/707/cisco-sn-20030422-ike.html>

I know several people work on XAUTH MITM attacks; I guess it will fall
in a couple of weeks. (Just sniffing the user password is easy, the
group password is typically public anyway; the remaining challenge
consists of putting together several tools to transparently fake a Cisco
VPN concentrator).

[Thor Lancelot Simon]

On Fri, Dec 12, 2003 at 11:00:31PM +0100, Florian Weimer wrote:
> Thor Lancelot Simon wrote:
>
> > For what it's worth, the possibility of this general type of attack was
> > repeatedly discussed in the IPsec working group and is a major reason
> > why XAUTH was abandoned. The particular password-stealing attack that I
> > describe as been widely discussed among IKE implementors for at least two
> > years; other implementors probably independently noticed it at least as
> > early as I did, which was three years ago.
>
> And we have technology deployed that solves exactly the same problem in
> a reasonable way: SSH.

Yes and no. SSH is not, by itself, a network-layer encryption solution,
and there are many applications where that's really desirable. The other
issue is, of course, that SSH's model for authenticating host identities
is, itself, a mess: in this day and age, it is not acceptable to just
punt on the problem of first contact and pretend that users will reasonably
exchange key fingerprints offline. The widespread success of sniffing
and MITM attacks on the SSH protocol -- all due to users not doing what
the protocol, by omitting any means of using a hierarchy or web to validate
host keys, requires them to do -- should be proof enough of this.

Yes, there are multiple implementations out there that implement both
chain-of-trust (certificate) and web-of-trust (PGP) mechanisms for
validating host keys on first contact. Unfortunately, the attempts to
standardize this have repeatedly been shot down in the SSH working group,
which is extremely unfortunate. Human factors *are* a real issue in
secure protocol design; secure protocols that just handwave important
issues by telling users to do something appropriate out-of-band, and
that require large numbers of users to do so on a regular basis, have a
serious design flaw, IMHO.

IPsec is a perfectly good suite of protocols. IKE itself is pretty good,
too, modulo its great complexity. The issues I have pointed out in this
thread are, in the first case, due to a fundamental misuse of public-key
cryptography and certificates, and in the second case, due to a very very
poorly designed and nonstandard protocol extension, not due to anything
about IKE itself.

Thor

[Florian Weimer]

Thor Lancelot Simon wrote:

> Yes and no. SSH is not, by itself, a network-layer encryption solution,
> and there are many applications where that's really desirable. The other
> issue is, of course, that SSH's model for authenticating host identities
> is, itself, a mess: in this day and age, it is not acceptable to just
> punt on the problem of first contact and pretend that users will reasonably
> exchange key fingerprints offline.

You don't exchange fingerprints, you just store them. Previously, I
thought that to be risky, but after having seen too many failed PKIs
implemented according to the text books, I'm no longer sure if the SSH
approach is so ugly.

FWIW, I have removed all CA certificates from my web browser and store
all web site certificates permanently. According to my threat model
(which involves greedy CAs issuing certificates after superficial
checks), this will catch a few attacks.

> The widespread success of sniffing and MITM attacks on the SSH
> protocol -- all due to users not doing what the protocol, by omitting
> any means of using a hierarchy or web to validate host keys, requires
> them to do -- should be proof enough of this.

There are very few such attacks in the wild. Most machines which do not
already have the keys I need and which are in an environment especially
prone to MITM attacks are not exactly trustworthy, either, so I don't
lose much. In fact, there is not much choice because it's impossible to
roll out root CA keys for SSH server authentication. There's no widely
used proprietary implementation that could essentially control the root
CA set (as it happened with the web browser PKI).

However, in the Cisco VPN case, the issue is moot. You can easily
distribute the concentrator certificate or fingerprint along the client
software and configuration. You already need a secure channel for that
anyway.

[Florian Weimer]

Thor Lancelot Simon wrote:

> For what it's worth, the possibility of this general type of attack was
> repeatedly discussed in the IPsec working group and is a major reason
> why XAUTH was abandoned. The particular password-stealing attack that I
> describe as been widely discussed among IKE implementors for at least two
> years; other implementors probably independently noticed it at least as
> early as I did, which was three years ago.

And we have technology deployed that solves exactly the same problem in
a reasonable way: SSH.

> What's pretty disturbing is that there is wide understanding of this
> issue among actual protocol implementors, but that Cisco field personnel
> continue to quite plainly tell customers that it does not exist at all,
> even when the risk to those customers is huge.

I have to admit that we were blinded as well. I didn't look too closely
at XAUTH at that time because it was proprietary software and no
GNU/Linux client was in sight. We should have forced Cisco to implement
hybrid mode over two years ago, but failed to do so. I'm sorry about
that mess.