When Wi-Fi won’t work well…

… then you are probably using a commercial hot-spot, or maybe someone has tried to provide some “security.” The last couple of days gave me a chance to experience a variety of Wi-Fi setups. Besides the generally working open conference network a…

… then you are probably using a commercial hot-spot, or maybe someone has tried to provide some “security.”

Media_httplogdoesnote_gjeeq

The last couple of days gave me a chance to experience a variety of Wi-Fi setups. Besides the generally working open conference network at WOS (hidden behind a NAT box, of course), there were the insecure, but cumbersome security mechanisms at TU-Berlin (ultimately circumvented for many people in the room by setting up a laptop as a router between an ad-hoc open network and the official Internet access), and airport Wi-Fi at CGN and TXL.CGN is in T-Mobile’s hands. The design of the payment process looked reasonable, at least as long as you are a T-Com or T-Mobile subscriber. Random 404 errors and wrong host names in SSL certificates (hotspot.t-mobile.net vs. hot-spot.t-mobile.net) pointed towards a rather unprofessional implementation, though.(The Vodafone setup in MUC about which I ranted in March had a more cumbersome billing design, but was implemented better.)TXL (where the photo was taken this morning) is more open to a number of wireless providers. Access points are shared between providers; users are then supposed to pick providers from some web page. When trying to go further than that, I got inconsistent and irreproducible behavior, including 404 messages, transparent proxies complaining, and timeouts. The “wlan-zone” was useless for me.Open and free Wi-Fi should be a convenience at airports — spending the waiting time attempting to debug a network is not a productive activity at all.

WOS: Ross Anderson on DRM and Competition.

Ross Anderson speaks on DRM and Competition. Economics of software: Value of a software company is accumulated switching cost of users — if switching 100 seats to OpenOffice costs less than 50,000 ???, you don’t pay 500 ??? per seat for Microsoft Off…

Ross Anderson speaks on DRM and Competition.Economics of software: Value of a software company is accumulated switching cost of users — if switching 100 seats to OpenOffice costs less than 50,000 、, you don’t pay 500 、 per seat for Microsoft Office. If it costs more, Microsoft charges more. What happens with new document/right management technologies Microsoft is about to supply, enabled by trustworthy computing? Need permission from senders to convert files to other technology. Switching costs explode.Use TC to lock in users by locking up their data. Software startups to have lower probability ofsuccess. Software industry much less dynamic, much more like “normal” industry. Small number of big players, big entry costs, less jobs.Playstation model: Subsidize hardware from software sales. TC computers cheaper. Later, maybe PC free, “Office plan” for monthly rent. Effect on free software when commercial software comes with free hardware? Internal Market? Talking services now, not products!TC has nasty effects on competition policy. Twist anti-circumvention into anti-competitive tools. Need digital rights directive — not just about consumers, but about markets. Not just about music, about everything — because everything contains software in the near future.

WOS, last day: Pre-shared keys + XAUTH, again.

I’m at WOS 3 in Berlin, now sitting in the Copyrights in Europe workshop at the Technical University’s main building. After the main conference network behaved interestingly yesterday, people are now struggling with the TU’s WLAN security setup. I…

Media_httplogdoesnote_doepj

I’m at WOS 3 in Berlin, now sitting in the Copyrights in Europe workshop at the Technical University’s main building. After the main conference network behaved interestingly yesterday, people are now struggling with the TU’s WLAN security setup. IPSEC with pre-shared keys and XAUTH over unencrypted WLAN, of course.User names and passwords are distributed on tiny paper strips. Keys and software are distributed on CD-ROMs that can’t be mounted properly by many people here. The key information, though, has now made it to one of the blackboards, after it was unscrambled.

Too much text alert.

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

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.

Ethics of full disclosure.

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…

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?

Security solutions that make things worse.

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…

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.