Hacked

I got hax0red. Totally pwned.

I run BlogAfrica.com and EthanZuckerman.com off an hosted account through Rimu Hosting, an excellent New Zealand-based company who I highly recommend. Rimu takes a very hands-off approach to systems, which I appreciate, but means that you’re responsible for keeping your software up to date.

I would confess to being less than religious about patching all my systems. I don’t know how the old system got compromised – I believe it was a Webmin bug – but I found out about it because a good samaritian forwarded me an email. The email invited an unsuspecting web user to download a greeting card from blogafrica.com/greetings/filename.exe. Needless to say, there’s no greeting card system on BlogAfrica, and the .exe is a nasty trojan which will open countless backdoors in a windows system.

The smart guys at Rimu were able to detect the attack once we were warned, though the attackers had used an excellent rootkit, which covered most of their traces. But we couldn’t lock them out. Most of the binaries on the server had been replaced, and I would delete the virus-ridden files, only to watch them reappear a few minutes later.

What’s more frustrating than this was that tens of thousands of emails were being sent driving people to my site, which overloaded the server every time I brought it up Apache long enough to try to recall my WordPress and Reblog settings for a new install on another server. Eventually, I just shut off nameservice to the old address, pointed it to the new servers and worked with the Rimu guys to get the two sites up on a new box. We’re almost there – there’s a date bug we’re still working out on BlogAfrica, and right now it looks like every post is from the 1970s. But I think this blog is more or less ironed out… and please let me know if it’s not.

My colleague Jonathan Zittrain has been writing about the dark side of “generativity“, the power to run arbitrary code on your machine, and how this makes it possible both for new applications like Skype to propogate… and how it makes it possible for hackers to design nasty code to penetrate your systems. One of the topics in the geek community for years has been “Why haven’t we seen a truly brutal, system-wrecking, internet-destroying virus?” One answer has been that there’s been no profit motive for building one. But I think we’re there – the rise of malware sites detected by Google suggests that there’s a community that’s focused on:

– Using bugs in webmin or cPanel to gain access to hosted accounts. (My colleagues at StopBadware reported over 10,000 malware sites hosted by a single hosting provider, which suggests either a bug in an administrative package, or massive password compromise.)

– Injecting downloadable malware onto compromised sites

– Sending large quantities of spam to promote the malware, using social engineering (a downloadable greeing card is more likely to be opened than a random .exe on the web)

– Compromising the machines that download the malware, probably to use some as zombies to send more spam.

This isn’t quite as slick an attack as the one I found on my friend’s server, which added Javascript to her page to open an iframe and start a download in the background, but it’s very sinister, and was done competently enough that my only solution was to leave the old server for a newer, more fully-patched box. The process felt a little like gathering my worldly possessions, running across the street, and dumping my worldly goods in a new house, then torching the old one. Not an enjoyable experience.

A few days ago, I was reading the specification for Bitfrost, the security system designed to protect the One Laptop Per Child XO machine from widespread security compromise while enabling kids to customize, explore, program and hack the machine. I was struck by this passage in Ivan Krstic’s document:

The 1971 version of UNIX supported the following security permissions on user files:

* non-owner can change file (write)
* non-owner can read file
* owner can change file (write)
* owner can read file
* file can be executed
* file is set-uid

These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What’s deeply troubling — almost unbelievable — about these permissions is that they’ve remained virtually the _only_ real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.

In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can’t stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?

Krstic goes on to argue that it might have made sense to give the same permission to change files to programs that we give to users in 1971 – all programs we used were ones we’d written, or were written by people we trusted. But that trust shouldn’t be a default today, and the Bitfrost model tries to envision a version of “trusted computing” that isn’t about DRM and not trusting the user, but is primarily about trusting the user to make certain decisions when she reaches certain levels of expertise. While there’s some disagreement on the OLPC wiki about whether it’s addressing the right threats, it’s an impressive step towards thinking about a version of trusted computing I’d find easier to live with. Because, you know, it’s getting dangerous out there…