#Drupalgeddon If you haven’t updated your drupal site, it’s infected

Do you host a Drupal website? Did you update within 7hrs of the latest Drupal update? If not your site is likely infected. Ours were.

The main issue is an SQL Injection vulnerability in the core of Drupal that can even allow arbitrary PHP to be executed. The fiasco is being called #Drupalgeddon.

If you run a Drupal site then check this page for information on how to fix it or this, which highlights how useful git is.

At one of the companies I work with we have a number of servers and host over 100 domains. Our main production server hosts a mixture of Drupal, WordPress and custom sites on a normal LAMP stack.

#Drupalgeddon hit us yesterday, (not long after a ZDNet article saying things didn’t seem to be too bad) and before we knew it nearly all the sites on the server were infected. The infection of spam and backdoor files weren’t limited to the Drupal sites but spread to to any other sites that the Apache server had write access to. This included WordPress and custom coded sites.

 

Process I roughly used :

1. Identify the most important sites. These will be ones that are the
2. Take them down (to prevent re-infection before we can fix it), usually just disabling the apache vhost
3. Backup the site in case there was any new user submitted files that hadn’t made their way into the backup system. E.g
   sudo cp -Rv /var/www/sitename/www /var/www/sitename/www_haxored_2014-10-30th/
4. Check against the previous point in time snapshot and see which files had changed. Check the files and either delete the new ones that are just spam or blatant back doors, remove the infected sections of some files or if the infection was bad enough then restore from backup (usually an rsync with –delete-before ). E.g
   sudo rsync -rlpgoD -vzhc --dry-run --delete-before /backups/rsnapshot/hourly.2/production.server/var/www/sitename/www/ -e ssh production.server:/var/www/sitename/www/
5. Run the drush upgrade command to update Drupal to the latest version. I.e
   sudo drush pm-update projects drupal-7.32
   Note : If you don’t have ssh access or Drush (the Drupal command line tool) installed. You’ll probably have to extract the latest Drupal core files over the top via FTP, or enable web access to only your IP address and try logging in.
6. Activate the site and check everything is fine. E.g
   sudo a2ensite sitename
7. Change all the passwords. User logins, MySQL DB passwords and more.
8. Check the servers email queue and ensure it’s not been sending vast amounts of spam. Ours had over 6,500 in there. E.g
   sudo exim -bp

Thankfully we had rsnapshot backups of the server from only a couple of hours before the server was hit with the infection allowing me to easily use an rsync dry run to see which files had been changed, to investigate which were OK changes and which we needed to blow away. About half the sites were so infected I backed it up then just wiped it out back to our backup. Then

There was two main backdoor files or infection types that I identified and which I identified using the following :

sudo find . -type f -name '*.php' -exec grep --files-with-matches 'PCT4BA6ODSE_' "{}" \;
sudo find . -type f -name '*.php' -exec grep --files-with-matches 'Ly4qL2U=' "{}" \;

Those commands will run a find on the PHP files from the current folder and recursively upwards and if the file contains those snippets it will output the name of the file(s) so you can start trawling. Note that the hackers have MANY different techniques up their sleeves and this is by no means a guarantee that your site is infected, it’s just something that helped me.

The top one is usually in a file which was named security.php and contained code that looked like :

preg_replace(base64_decode('Ly4qL2U='),base64_decode('ZXZhbChnemluZmxhdGUoYmFzZTY0X2RlY29kZSgnVFp6WGpzTmFrMTdmNWR5TWJRN01uR0RNQlhQT3BCandBd1p6RUhNbW45NXF6d0QyaFZxUVJIVlRlMWQ5dFZaTDBMeVc5ZjlleTdsUDgvSy8vUVArei84Qmx2Lzgrei8vdWduOFh6ZEovSzdoMzRYNzE0MVF2MnZ5ZHgvenU2Wi9GK0YzSWY3enNiOWpTT3cvbi9OL2owUCs2ejcwUCs5RGY4ZWh2OGR4OFhmN3Y0NGovaDc3LzI0a....

The code is a base64 encoded bit of code that runs

eval(gzinflate(base64_decode('TZzXjsNak17f5dyMbQ7MnGDMBXPO.....

which is itself a base64 encoded gzipped bit of code that creates a bit of HTML form code that looks like it tries to steal your username and password, although I haven’t looked at it too hard and it probably does all sorts of other stuff.
I’m not a security researcher just a general sys admin, web dev and entrepreneur, so don’t have the tools or time to analyse these in much detail.

An interesting one was $sF="PCT4BA6ODSE_";$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s22=${strtoupper(.....
The code is explained well here and basically it allows the script to eval (run) any PHP POST requests sent to the script with a certain variable name. A great snippet of code for the haxors who want to re-infect your machine.

The interesting bit about it is that it was appended to the files with a LOT of white space between the opening <?php and the actual code. This has the effect of being off the screen when you go to look at the file in nano (and vim or anything which doesn’t have line wrapping enabled). Thankfully it’s really easy to see the content if you cat or use head on the file. Once you know what it looks like you can then grep for it as I’d done.

There was a third file, usually called wp-xmlrpc.php which contained what looked like normal version packaging information, but for Joomla not WordPress or Drupal and scrolling down a little there was more base64 encoded fun.

If you are a security researcher then I’m sure you’ve got your hands full, but if it helps I can supply a copy of the infected files. Otherwise, if you are a sys admin then good luck!