Six weeks ago, the Drupal Security Team disclosed one of the most critical vulnerabilities in the history of the project. Today we’re still seeing usage statistics that indicate tens of (if not hundreds of) thousands of Drupal sites are still at risk. Given that approximately 10% of all reported Drupal installations have an eCommerce component enabled, it’s only a matter of time before we start seeing reports of stolen credit card data.
I’ve been closely watching the fallout of the SA-CORE-2014-005 Drupal core security advisory, which is sometimes referred to as “Drupageddon” to emphasize the severity of this security issue. If this is the first time you’ve heard of this, then I highly encourage you to read this comprehensive overview before continuing below. My goal is not to rehash what has already been stated in this and the many other recap articles out there. As a member of the Drupal security team and co-author of the Drupal PCI Compliance White Paper, I’m much more interested in the repercussions of SA-CORE-2014-005 on the eCommerce community, which (in my honest opinion) hasn’t been sufficiently addressed.
It’s important to state for the record that it’s not my intention to spread FUD or come off as an alarmist. Had that been the goal, I would have published this article immediately after the disclosure and the numbers I would have had to report at the time would have been purely speculative. Six weeks later, we can have an honest and open discussion about what is left in front of us.
The Good News
The exploit was responsibly disclosed to the Drupal security team rather than keeping it a secret, selling this information to the highest bidder, or leveraging it as a zero-day exploit. Any one of these alternative scenarios would have given the community zero preparation in what could have been a catastrophic attack against every known Drupal site. While clearly not everyone was spared, the damage was significantly reduced (see below).
In terms of preparation, I’m very impressed with Acquia, Pantheon, and Platform.sh, each of which deployed system wide protections that significantly reduced (and in some cases outright eliminated) the vulnerability for any Drupal 7 site hosted within their infrastructure. This was huge win for the community as a whole because large, high visibility websites tend to gravitate towards hosting with these companies and as a result (due to the protection that these services offered for this specific vulnerability) the damage was further mitigated.
For others in the community, there are many anecdotal reports of individuals immediately applying the one line patch on all of the websites they manage. I believe this rapid roll out was in large part due to the quantity of announcements to the community letting them know that something big was about to happen.
The Bad News
Unfortunately…
- Not every site was hosted with Acquia, Pantheon, and/or Platform.sh (due to cost, preference, requirements, etc).
- Not everyone has the ability or capacity to roll out patches within X hours of every security release.
- Penetration tests across all known Drupal sites began within 7 hours of the vulnerability (see the recap for more details).
- Anecdotal evidence within the community indicates that backdoor exploits have been added to virtually all sites that were not patched.
- Hundreds of thousands of Drupal websites are reporting that they are still running an older (and therefore vulnerable) version of Drupal core.
- Thousands of eCommerce websites are still reporting that they are still running an older (and therefore vulnerable) version of Drupal core.
- I’ve personally seen two Drupal eCommerce sites that were already hacked by the time I was asked to review them within days of the disclosure.
Anyone exploiting this vulnerability is essentially able to gain admin access to the Drupal application. With admin access, stealing credit card data is a fairly straightforward process for most payment gateway configurations. One of the most obvious attack vectors is to enable the php module in order to drop a keylogger within a custom block on the payment page. Beyond that, there are several other creative ways to access, log, and extract customer information from a hacked Drupal site.
Tempering the Bad News
It’s important to note that the usage numbers are not a 100% accurate representation of what’s out in the wild. Many websites were updated using a hotfix patch versus upgrading Drupal core to 7.32, which results in an underestimation of the percentage of sites that are protected. However this is countered by the fact that not all Drupal sites report their usage statistics back to Drupal.org. Also, there are sites that may simply have an eCommerce module enabled, but they are not setup to the point where they can accept payment.
Here are some other factors that may reduce the damage to the Drupal eCommerce community:
- Not all sites containing a backdoor haven’t been exploited further in any obvious way. This means that merchants still have time to cleanup the mess.
- Not all payment solutions are easy to attack. If a website is configured to use a hosted payment page, one has to either swap out the payment gateway completely or create a man in the middle attack. Both of these attacks are more likely to get caught quickly instead of going undetected for days/weeks/months.
- Not all sites are large enough to make the headlines. A breached website that only manages a couple transactions a month will still get caught, but will not make the front page of any major tech news site. However, the merchant itself will have to deal with the fallout (including fines and the cost of a forensic analysis of the breach).
While this does reduce the overall pain caused by this vulnerability, we cannot ignore the reality that it’s only a matter of time before at least one Drupal website (and possibly many more) will report that they had credit card numbers stolen. And when this happens, it will be a black eye for the community regardless of how many of the 100,000+ other eCommerce sites were protected. All it will take is one significant breach and merchants evaluating Drupal against alternatives may think twice due to a perception that it’s not as secure (regardless of whether or not that determination is true or not).
The Silver Lining(s)
What’s done is done and it won’t do the community any good to dwell on the past. Rather, we should focus on the positive as well as what we can do in the future to make the most out of this experience. I know is easier said than done because there are segments of the community that are still feeling the sting. That said, here’s my list of silver linings to this experience:
- This vulnerability is now fixed and all future Drupal installations will no longer be subject to this exact attack. This is one of the many benefits of open source software—we all reap the benefits from code contributions from the community.
- This vulnerability was so severe that it has sparked many conversations within the community on how to further harden Drupal and even roll out critical patches automatically. While this attention may wane, the fact is that this will have a permanent impact in how much importance we place on security as a community.
- For being a volunteer organization, I would argue that the Drupal security team handled the situation as best as it could. The exploit could have been leaked, the disclosure botched, etc. While there are areas that can be improved moving forward, it was a privilege to work with the other members of the team to mitigate the damage as much as possible.
- It’s possible (although highly improbable) that we may not see any reports of credit card data stolen as a direct result of this vulnerability. Only time will tell…
My final advice to anyone building, maintaining, or operating a Drupal eCommerce site: read the Drupal PCI Compliance White Paper (to learn more about ways to reduce risk) as well as read this article by Greg Knaddison to learn what to do in case you ever discover that a Drupal site’s been hacked.