Re: Insecure IKE Implementations Clarification
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@xxxxxxxxxxxx
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