I've spent my evenings this week tracking down a website hack. It's not on this server, but on another some friends and I maintain. A message came in on the trouble ticket system, "you have a hack". Someone had noticed pages full of links to "blue pill" sites stuck up on our site. I volunteered to look into it. I've had to do this sort of forensic/detective work a few times in the past; it's pretty fun and challenging.
The first clue was that the files were all owned by the web server process, indicating a high likelihood that a vulnerability in the web site had been exploited (as opposed to some other type of hack masquerading as a web sploit). The second clue was that there was a zip file, plus all the files had the same timestamp, indicating that they were extracted from the zip (versus uploaded individually). That meant that the hacker had been able to execute code on our server. Arbitrary code execution is a severe vulnerability, it means the hacker can pretty much do anything (limited only by the privileges of the web server process).
This all pointed to PHP. There's a ton of PHP code on this system. PHP itself was notoriously crackable early on, but by about age ten they'd rooted out all the major security flaws (it's still a case study in how not to design, or grow, a programming language). But since PHP has such a low barrier to entry, the code that web programmers write with it is often flawed.
We're using third-party software like mediawiki (wiki system), vbulletin (forums), gallery (images) and wordpress (blogging). Some of those have a pretty bad track record, and I'm looking at wordpress when I say that. And there's a variety of WP vintages on this system. But there's also a lot of custom code written by people I don't even know, with a variety of skill and attention to security concerns. But there's also some legacy Perl CGI code, some of it written by me, that could be at fault....
Read More
