Web hosting is a pretty saturated market. Software like cPanel and WHM make it easy to rent a server and sell space on it to others, who can then even go on to resell it themselves. Promises of “unlimited bandwidth and disk space” can be had for less than the cost of a nice lunch. Commodity servers end up hosting thousands of disparate websites for thousands of different people all over the world, and nobody involved even needs to know what “shell access” means.
UNIX-like systems were designed for multiple, simultaneous users. Its roots are in an era where computers were too expensive for people to have one of their own, and decades of effort have gone into ensuring that the users of the system are safe from one another. Think of it like having a thousand different housemates. Maybe you trust them, but do you trust everyone they have over? Do you even know who they have over? After enough conflicts and theft, you end up with something like an apartment building, with strong locks, alarm systems, security guards, and so on.
That’s how shared hosting environments are today. Some are better than others; most of them have locks, but only a few have alarms, even fewer have actual security personnel. The cheaper it costs to live there, the less they’ll have in the way of security. But they all have the same problem: the weakest link is somebody else.
In this article, I’ll walk you through a real attack on a real website on a real shared web host. Using various common vulnerabilities, we’ll find somebody else to let us in the building, find an abandoned unit, steal someone’s keys — and then we’ll walk out with everything. It won’t be anything new to an experienced hacker or penetration tester, but you might find it interesting if you develop web applications, have a site on a shared hosting service, or have ever wanted an inside look at what “real hacking” in a web2.0 world is like.
A few months ago, I was approached by Pixeleen Mistral, managing editor for The Alphaville Herald (NWS). She had gotten a reputable tip about a security problem on the website of a popular third-party service for Second Life, and asked if I knew anything about it. The service in question was BanLink, which provides a way for groups in Second Life to share their ban lists. Since the whole point of the service is ostensibly to hinder griefers, it seemed like a pretty hot target for exploitation, and a security vulnerability was potentially big news.
The problem ended up being SQL injection: the ability to modify the queries the website makes to the back-end database. SQL injection is among the most prevalent and most dangerous security problems in web applications. OWASP‘s top ten list placed injection flaws at 6th place in 2004, 2nd place in 2007, and they’re going to be 1st place in 2010. This particular application was vulnerable to injection in pretty much every single parameter on every single page, and any errors from the database were reported in full. As far as these things go, it was a gold mine.