Drupalgeddon. Most Drupal developers roll their eyes at the term, but the truth is, catastrophic things can and will happen if you neglect this, or other critical security updates for days or even hours after they are released. Malicious hackers are ready and waiting to exploit unpatched Drupal sites.
We recently had an organization come to us who was dealing with just this very problem, and we were able to repair their exploited site. It was a time-intensive, painstaking process, which could have been avoided by applying regular security updates.
The State of Things
This site had been infiltrated so that every piece of content (node) had some JavaScript inserted into it, redirecting the visitors to a malicious site. The site had not been updated since Drupal 7.44 – nearly two years ago – putting it at an enormous amount of risk. The first thing we did was patch the codebase and get that deployed to the production site. They had already swapped out a week-old database to get rid of the malicious links, at the expense of losing a week’s worth of content.
Next, we spun up a totally clean server. Once the hackers were in, we really don’t know what they could have done, so creating a new server was much faster than trying to scan every last file. We manage our server creation with Ansible, so this was relatively quick and painless.
We set up the new server with the clean code and the tainted database to see what we could do. First, we enabled “Advanced Content Filtering” on CKEditor so that the inserted scripts wouldn’t be rendered on the page. This solved the redirect issue, which was a quick win. However, we still needed to get the malicious code out of the database. To accomplish this, we created an update hook to load the body of every node, look for the malicious string, remove it, and re-save the node.
Luckily, this site’s nodes were in the hundreds; if it had been tens or hundreds of thousands, a different approach likely would have been needed.
We then took a look through the Drupal files directory to make sure there wasn’t anything malicious added to the file system. Thankfully, everything looked normal. With a clean codebase, database, and file system, we pointed the DNS to the new server, and decommissioned the old one. Problem solved. Did I mention the organization had two sites with the same problem? So we did all of this twice.
The Cost
We don’t know what this cost the organization in terms of their customers’ trust, but we imagine there was an impact there; as a user, I’d be hesitant to revisit a site that sent me to a suspicious link. We can tell you that it took exponentially more time to clean up than if we had been tasked to regularly keep the site up to date.
How to Avoid It
Updating your site isn’t a particularly complex undertaking if you do it regularly; sign up for security alerts, know when the release windows are, and be prepared to apply the update. In fact, you may have someone on your team already who is capable of this. If not, or you’re unsure, keep a professional at the ready. A team like Chromatic can make sure your site is safe and always up-to-date, along with any other security concerns you may have. If you’re not sure if your site is vulnerable, contact us today!
