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
