Since Drupal is a community project, the code is always being fixed, updated, and changed. In the past few months there have been a number of major security holes that have been fixed -- but part of the process of fixing vulnerabilities in open-source code is communicating what the holes are, how they might be exploited, and how to prevent writing code that contains those holes in the future. So it becomes a double-edged sword -- the issue is fixed, but hackers can take the information and exploit sites that haven't been updated yet.
The security announcement on 10/15 is flagged as critical because every Drupal 7 site is vulnerable to attacks by anonymous users. Other security updates are flagged as such, but are usually less critical (for the vulnerabilities to be exploitable, a malicious user generally needs to have login access along with access to specific settings or admin features). On the sites that I am engaged to maintain on an ongoing basis, I'll usually check for updates and test/deploy once per month, but the 10/15 release was definitely a "drop everything and update now" moment.
I was ready to jump in and start updating sites as soon as 7.32 was released, because many Drupal service providers, including Pantheon and Acquia, sent out notices to their customers in the days before the release, indicating that one was coming without going into the technical details. Since this is the first time that's ever happened in my experience, I knew that the release was going to be pretty important.
Of course, not everyone updated their sites immediately, and I've been contacted by a handlful to new/potential clients looking for help. In most cases, he attacks that I've seen have been one of two types, the creation of new users assigned to a new 'superadmin' role, and the addition of an item to the database that enables files to be uploaded directly to the server. Additional symptoms were the inability to log in (due to a 403 being returned for /user), and PHP error messages displaying, which indicates that the backdoor has been used to write to existing files and implements an exploit I've seen previously on Wordpress sites.
It was also interesting seeing how this vulnerability affected sites that I had built, but do not have a maintenance agreement in place for (and had to get approval before updating). For a few sites, new users and roles were created, but the malicious user account(s) didn't do anything on the sites (probably due to the new account not having proper missions, since I always create an Admin or Editor role instead of placing content admin permissions with the default Authenticated role). One site had the uploaded files exploit in play, but since I use version control it was very easy to identify and remove new or updated files that shouldn't be there!
For further reading:
Release announcement FAQ: https://www.drupal.org/node/2357241
"Your Drupal site got hacked. Now what?": https://github.com/greggles/cracking-drupal/blob/master/after-an-exploit.md
Flowchart of how to detect backdoors that may have been installed: http://drupal.geek.nz/blog/your-drupal-website-has-backdoor
Posted October 29, 2014 in Drupal