Sunday, December 12, 2010

keeping your leaks leaky

Image number four here has a certain additional spice, doesn't it? What a week. As well as WikiLeaks being the website they couldn't hang, 4chan became a geopolitical actor, thus fulfilling my prediction that in the future, trolls would be considered a strategic resource like oil. The BBC interviewed a builder from Leeds thinking he was a Liberal MP, but as it turned out, it didn't matter - the real MP did exactly what the fake one said. And of course there was the case of James Naughtie, demonstrating that the BBC really is the voice of the nation. Speak for England! Prince Charles got a nasty surprise from the students, which startled the mainstream media into actually covering the demonstrators' main grievance for once.

A lot has been written about how Wikileaks is staying online and I don't propose to add to it - this piece on CNET and this one from Renesys should tell you all you need. If you're looking for mirrors the list is currently here and there's a mirror of the mirror list here.

However, there are a couple of good technical points to be made here that I've not seen elsewhere.

First of all, Wikileaks is a website designed to be easily cloned. If you look at it, each page is a self-contained file with a flat URI - there are no signs of a query string, and each cable released has a unique ID within the same directory. This is important because it means that the process of creating a mirror is just to copy all the files into the /public_html/ directory of another web server. On a Unix-like system, it could be a one-liner command (the site doesn't actually let you do this the quickest way) - the utility wget is capable not only of traversing the directory and downloading all files, but also of changing links within them to point to the same filename in the target directory. The -m or --mirror option activates the options -N -r -l inf --no-remove-listing, which will in order ensure you only download material you haven't already loaded, that wget will get everything in the target directory or directories, and that any directory listings will be preserved. -p requires that everything needed to make up a page, such as a photo of Julian Assange, will be retrieved. -k turns on link conversion.

It might be enough to do: wget -N -p -k wikileaks.wherever /home/you/public_html/

So it's easy to create a mirror, and it's trivial to keep it up to date - you could just run your script as a cron job to grab whatever gets released every day. Anyone thinking of a really controversial Internet project should, IMHO, consider design-for-cloning to be a useful pattern. The clone count is now in the thousands.

Second technical point: what a horrible idea Mastercard SecureCode (and its pal Verified by Visa) is. I already hated it before this - it's a password, that should be a strong password because it's financial, but that I don't use that often and therefore can't remember, and it trains you to accept the idea of typing confidential information into a random web site you didn't ask for. Essentially all phishing requires you to type your bank details into something that you didn't ask for. Forcing the public to type their bank details into some random website they didn't ask for is howling insane. Right?

Also, the failure case is horrible - you get to reset the password by disclosing a whole lot of confidential information into the same random website you didn't ask for, so an attacker who managed to inject a frame into the original merchant's website could fake a failed payment and harvest all the information they would need to empty your bank account. And the service support when they imposed it on me was dire, especially as the SecureCode web site went down part way through the process.

But it's worse than that. An important part of the way card payments are accepted on the Web is that, as is also true in shops, you interact with the merchant, whose bank interacts with the wider infrastructure. So you should know who you're dealing with. Further, the bank should at least have some idea who its merchants are - they are customers after all - and restrict access to the system to them. And there's more than one bank that provides merchant service, so there are no single points of failure.

The SecureCode (and its Visa twin) websites, though, are customer-facing, so they have to accept traffic from the whole of the Internet. And all the Mastercard payments from the Web have to go via the SecureCode website. So you have a critical operational function, that is a single point of failure, and that is exposed to every last dog on the Internet. It's only surprising that somebody didn't bring it down earlier, especially when things like Bees with machine guns! are available.

1 comment:

Anonymous said...

Completely agreed on the fundamental broken-ness of 3DSecure. However, I haven't seen any confirmation of an DDos related outage. All I could find was some early anectodal reports from merchants in a (I think) story. Is there more detail somewhere?
I'm a bit skeptical that there was an outage. A large part of the problem with 3DSecure is that the authentication page is (generally) served by a 3rd party service provider (i.e. not your bank, not Mastercard) of which there are several. These are not the sort of companies that the Anonymous masses are going to know about without being told, and I haven't seen them mentioned on Twitter etc.

kostenloser Counter