Drupal - Drupal SA-CORE-2014-005 - How to tell if my server / sites were compromised?
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.)
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.
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
