Website Malware – Drupal Injections Targeting Cookies

Many folks are unfamiliar with the Drupal CMS, it doesn’t enjoy the popularity that some others do like WordPress and Joomla, but its a powerful CMS none the less. What it does have in common with its counterparts is that its susceptible to attacks and infections. We don’t often write about it, but we do work on the platform. We decided to give it some attention this week because of the increased number of Drupal infections we’re seeing.

They’re slightly different when compared to other CMS applications and so is the remediation process. In this post we’ll show an infection that seems to be all the craze this week, findings courtesy of Fioravante Souza – one of Sr Malware Engineers.

The Payload

Most of the sites infected with this payload are also accompanied by other iframe injections. Those iframe injections are not special, they are often attached to every file – PHP, JS, HTML, and beging with document.write and reference some file like cgi?5 or cfg?11. If you have some terminal sense you should be able to find them and remove them, if you need help you can always use our free scanner, it’ll display any payloads hitting the readers browser. Here is the payload though that we were most interested in as it was obfuscated and very painful to find and remove.

When you decoded it, it will drop a div with an iframe reference:

<DIV id=check360 style="DISPLAY: none"><iframe src="http://360.{not so nice domain}.ru/index.html?p=236768" width=".....

Notice the correlation between the subdomain 360 and the DIV id check360. If you download the payload from the malicious domain you find yourself a little gem:

That’s right, it’s tracking and generating a cookie by the application. It’s designed to pull the cookies being generated by the site and push them to the counter.php file. It’s unclear what its doing with it at this time as we’re trying to reinvestigate the counter.php file, once we know more we’ll update. We do know that it’s generating something like this:

site.com/counter.php?id=ID&r=REFERRER

This does mean however that if you this payload you’re going to want to look and verify that the counter.php file is checked and removed if it exists on the server.

Finding and Removing

Like most things it has similar traits, for instance the initial payload loves to inject itself in html and javascript files. You can often find them in here /sites/all/modules/, includes, /sites/default/files/js and in the database.

If you have terminal access to the box you’re going to want to use something like this – courtesy of our Sr Support Analyst Rodrigo Escobar:

# grep "i5463" * -r 2>/dev/null |awk -F":" '{ print $1 }'

This will list out all the files that contain the payload, this is important because although it likes to inject itself into HTML and JS files, it is also know to inject itself in other files without extensions or random extensions. You want to remove all the injections before proceeding.

Next, you’re going to want to reset your cache in Drupal by modifying your index.php with this:

drupal_flush_all_caches();
drupal_set_message('cache flushed.'); 

Insert and load the site once and you’ll be on your way. This is a one time situation, when you’re done, you’re going to go back and remove.

Lastly, and very carefully, you’re going to want to purge your database. You can reset your database to update, if only momentarily, by modifying your settings.php file with this value:

$update_free_access = TRUE;

Please be sure to backup your database before running it as you could ruin things depending on how its configured. You can then run http://{your site}/update.php and follow the instructions. When you’re done, don’t forget to reset the value to False

Happy Hunting!

If you find yourself dealing with this, the instructions above should help, if you continue to have problems or would rather not deal with it just let us know, we’d be happy to take care of it for you. 🙂