Month: June 2004

It seems like too long documents are fashionable these days.It’s not just three days worth of broadcast treaty negotiations that have been minuted by a group of daring bloggers and NGO participants in the recent Geneva negotiations. (Donna Wentworth: required reading.)For the ICANN addict, there are also three WHOIS Task Force reports totaling 202 pages of text, a Draft Procedure For Designating Subsequent .net Operator, and a modest six-page GNSO draft for criteria to be used in selecting that operator; all these documents are waiting for public comment some time in June.

One of the ever-returning topics in computer security fora looks at “full disclosure”: Is it ethical to release tools that exploit a security vulnerability? Is it ethical to release information that makes it trivial to produce an exploit? One side of the argument basically says that it’s not ethical because releasing exploits doesn’t add anything for the white-hat consumer of the news, but makes attacks easy for script kiddies. The other side of the argument often talks about suppliers who don’t move swiftly to fix problems unless an exploit is known and publicly available. This side of the argument also notes that it’s often not possible to describe a fix without making an exploit obvious.There is another angle to this, though: Where vulnerabilities are due to design issues, and workarounds are expensive, unavailability of public exploits may lead to continued deployment of insecure setups, despite awareness that security design is flawed. Of course, it’s a dangerous assumption to conclude that just because there is no publicly available exploit, possible attackers aren’t able to get access to a private one.”Hi, you realize that your recently-deployed WLAN+VPN setup can be used to steal user names and passwords, possibly on a massive scale?” — “Well, yeah, we knew about the vulnerability, but it didn’t look like it’s easily exploitable, and after all, there are no exploits out there.” — “It’s extremely easy to exploit. Look, here’s how it goes, and yes, I have the software I need to do this. Want a demo?” — “duh. But we’d be interesting to learn about secure setups.”I wonder, can it be unethical to keep an exploit to a well-known security weakness private?

WLAN is insecure, and should be secured by adding a VPN as an additional layer of security, says conventional wisdom. An approach that’s still being deployed uses pre-shared keys for ISAKMP phase 1, and XAUTH in phase 2.As has been pointed out by others before, these setups are inherently insecure: Any party with access to the IPSec shared “secret” (often found on public web servers) can impersonate the VPN gateway; clients will happily supply the fake gateway with login credentials. Frequently, these are persistent passwords that can also be used to access anything else in the networks affected.Theoretically, the easiest exploit of this kind of problem consists in setting up an access point and a machine that runs a DHCP server and an off-the-shelf ISAKMP/IKE daemon which doesn’t really do XAUTH, but just records passwords. This isn’t a real MITM attack — but then again, the credentials one can reap are considerably more valuable than the additional data that one could get by doing a true MITM, so even this straight-forward reference attack can do considerable damage. (Think about some thousand Kerberos passwords.)Unfortunately, it turns out that this theoretical attack fails due to (1) idiosyncrasies of the CISCO VPN client (bad packet lengths), and (2) due to the fact that none of the easily available open source IPSEC implementations appear to implement both XAUTH and ISAKMP’s aggressive exchange (which seems to be typically used by the CISCO client, and is always used by vpnc) — openswan-1 may be an exception to this, but I wasn’t able to get it to run here. I can only speculate that the lack of availability of a ready-to-use attack tool contributes to the continued deployment of this kind of systems.Still, it is relatively easy to implement the simple attack: vpnc comes with all the library routines one needs to comfortably manipulate ISAKMP packets. Starting from vpnc, implementing a simple ISAKMP responder that takes the client through phase 1 and obtains credentials in phase 2 is a matter of a couple of hours on a lazy holiday.The message here is that the attacks against pre-shared key networks with XAUTH are anything but academic or difficult: Implementation is easy. I would be extremely surprised if no implementations were floating around in black-hat circles. It will only be a matter of time before one of these programs becomes readily available.