On October 15th, 2014, the highly critical SA-CORE-2014-005 - Drupal core - SQL injection vulnerability was announced. Shortly afterwards, research showed that sites not patched that same day could very well be compromised. Two weeks later, a public service announcement was released explaining the gravity of the situation. There was also a FAQ, a flowchart for dealing with it and a module that could potentially confirm a compromised site. Needless to say, it was a challenging time for the community.

At the time, I was asked by a client of mine to analyze a site to determine risk.

Some common attack vectors associated with the vulnerability were:

• Changing the superuser’s (user ID 1) username, password or e-mail address.
• Adding new users to the user table with the administrator role (usually ID 3).
• Adding entries to the menu_router table.
• Adding PHP files to the code base or in the sites/all/files directory.
• Adding nodes (pages) or blocks with executable PHP.
• Downloading the list of user passwords
• Determining hackability through the version listed in CHANGELOG.txt
• Spawned processes run by the Web server
• Adding new roles
• Permission changes

So based on the above, and some other sources, it was possible to produce a list of things one could look for to determine if a site had been compromised. As has been discussed elsewhere, failure to confirm any of these did not mean the site was not compromised, but it did provide some indication of risk.

1. Rerun the Security Review module.
2. Perform checks with the Drupalgeddon & Site Audit modules.
3. Check for changes to user 1’s username, password or e-mail address.
4. Check all users in roles other than “anonymous” and “authenticated”.
5. Check for strange entries in the menu_router table.
6. Check for code files outside of version control.
7. Check for code files inside sites/all/files.
8. Check for new nodes or blocks in the DB.
9. Check for strange processes spawned by the Web server user.
10. Check for any new roles.
11. Check for any permission changes.
12. Check the mail logs for anything suspicious being sent out.
13. Scan site with the Sucuri tools Free Website Malware and Security Scanner and Unmask Parasites.

There are some worthwhile things to note with respect to the checklist above:

1. Some of the clues (such as 5 and 6 above) would have been long gone as they’re rebuilt during cache clears and deployments.
2. It’s theoretically possible that malicious processes could have been spawned by the Web servers. The names could have been renamed to look non-malicious, but unless something was set up to make these persist across power cycles, they would be wiped on a system reboot.
3. It’s also theoretically possible that user passwords could have been compromised. In Drupal 7, hashed passwords are salted, but the random string used for the salt could have been read as it’s in sites/colan.consulting/settings.php. With that in mind, the site would be susceptible to brute force, dictionary and rainbow table attacks. If the site isn’t going to be rebuilt, it would be a good idea to expire all passwords and forcing users to reset them. If another system is handling authentication, this isn’t an issue.

And of course there could be any number of other things. The best course of action would be to rebuild the site. If that’s a challenge, always consider the level of risk before deciding not to. Hopefully we won’t have to make too many of these determinations in the future.

References

• Shields Up!
• Learning from hackers a week after the Drupal SQL Injection announcement
• Drupal SQL Injection Attempts in the Wild
• Drupal Vulnerability: Mass Scans & Targeted Exploitation
• UPDATE: New vulnerability–Drupal Project PSA
• What We Are Seeing With Drupal SA 2014-005
• Drupal SA-CORE-2014-005 - How to tell if my server / sites were compromised?
• FAQ on SA-CORE-2014-005
• How to improve security on Drupal websites
• Drupal SQL Injection Attempts in the Wild
• Drupal Warns – Every Drupal 7 Website was Compromised Unless Patched