Checking if your sites been hacked - Drupalgeddon: Drupal SA-CORE-2014-005

Drupal have advised that if you didn't update your site within 7 hours of the Drupal SA-CORE-2014-005 security release, you should assume your site has been compromised and roll-back to a pre October 15th backup. Below are some steps you can take to ascertain whether your site was compromised, and steps to take if you're unable to roll-back to pre-15th October.

  1. Check files integrity for changes using Git status or if not possible using Hacked;
  2. Scan public / private files locations for *.php, *.sh and any other suspicious files. There are some strategies to improve this procedure: for instance, if only images uploads are allowed, then scan for files other than images;
  3. If the webserver setup is permissive in terms of permissions and users (e.g. Apache user can write anywhere), it will be additionally required to perform audit of the entire server;
  4. Install, Security review, Drupalgeddon, Site Audit contributed modules and execute these modules checks;
  5. Set another Drupal hash salt in settings.php file for password generation;
  6. Reset passwords of all users ;
  7. If pages are built using the Features module, and it's possible, then revert all the features to their original state;
  8. Rebuild the menu executing core ‘menu_rebuild()’ function;
  9. Access the website as an admin user and define a list of areas that need to be manually checked, for instance:
    • Roles
    • Blocks
    • Panels
    • Filters
  10. Review the `variable` table to find any suspicious values. On some installations it might be possible to truncate the table entirely, if the Features module is used and if default values of variables are acceptable.
  11. Check the database for new MySQL users, update MySQL passwords and regenerate passwords/tokens for any systems, which are integrated;
  12. Check users to find if any have ‘admin’ role when they shouldn't.
    See thispost for SQL scripts to check for new admin users created after the 15th Oct.
  13. Check roles to find if any have altered permissions, or any new ones have been created.
    See this post for a SQL script to check for new roles created after the 15th Oct.
  14. Check `menu_router` and `users` tables for suspicious entries, e.g. with ‘file_put_contents’ callbacks;
  15. If MySQL/Apache logs are available then they can be used to perform additional checks and detect attacks by patterns, e.g. grep using ‘?q=node&destination=node’;
  16. Dump the entire website HTML, e.g. using some crawler, and grep for additional parameters in links;
  17. If possible analyse sessions table for logins of admin/advanced users from external IP addresses and check their last login dates;

See the flowchart here which details steps to discover and recover from Drupalgeddon.

Comments

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.