You Have A Hack

Back in 2006, someone had written a quick-n-dirty (very dirty) CMS hosted on our system, which worked by using the PHP include function. You stuck in a web site address and it included the contents. If the content is actually itself PHP, it all gets executed together. You can turn off this remote include functionality, but it's on by default (I was quite surprised by that). So there are loads of scripts out there that take advantage of this weakness. Very sophisticated web interfaces for commandeering a server. I found this curious double URL in the logs, pasted it into a browser, and all of a sudden there's a full console for everything from mass spam emails to cracking passwords. You could use it for system administration! It's not hard to imagine a script to crawl the net and find these weaknesses, you just find forms, pass URLs into the parameters, and see if anything in the content of the URL is included in the output. I ultimately found one PHP scriptkit on the system (called r57). I learned a lot about PHP programming by examining the source. .

But we'd hardened our web server a bit since then. So it had to be something a little different. I worked on two fronts. The first was examining the web logs, writing Perl scripts to analyze them for the fingerprints of certain kinds of attacks. The second was scanning the files on the web site, looking for vulnerable code. The latter yielded results more quickly. I started turning up more sploitkit PHP files in upload folders. My old friend, r57, was one of them. Another was madshell. You have to check out their source code to appreciate their evil genius. But how had they gotten there? There was a lot of code on the system for handling file uploads, and it would be impossible to verify all of it. But most of it looked pretty secure, it either validated user input (made sure they couldn't upload PHP), required a logged-in user, or both.

By going back to the logs, I could see who was using the sploitkits. By listing what else they were doing, I soon found something very disturbing: a vbulletin page was being used to run arbitrary system commands (the PHP shell_exec function). I tried it, put in a URL with the command to show the password file, and it worked. We had the latest vbulletin, and it would be surprising that such a huge, gaping, easily exploited security hole would exist in it. A check on securityfocus.com showed that there were no vulnerabilities listed for it, so it had to be one of the plugins. Sure enough, some of the other activity showed the hacker activating vbulletin plugins.

The smoking gun came in finding access from the same IP address to vbulletin plugin activation, then to the exploit it opened up, then to a bunch of commands to fetch PHP sploitkits, then a bunch of activity with those, and seconds after that, to checking out the pwnage, namely the very files that a user had noticed and started this whole debacle.

One mystery remains: how did the hacker gain administrative access to vbulletin? My theory is that it was simply a bad (poorly chosen) password by one of the admins, but I'm still digging....