Another month, another apocalypse-summoning security catastrophe – and October was no different. Just over two weeks ago, the security team behind Drupal’s free and open-source CMS released an ominous security advisory that shocked many in the security industry. The advisory, SA-CORE-2014-005, informed users that an SQL injection flaw in all Drupal 7 sites allowed attackers access to databases and more.
But it wasn’t until last week that the Drupal Team sent out this ominous public service announcement that said the attacks had been occurring since 7.5 hours after the original security advisory was released. We were warned to “proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC.” The Team even designated it the highest possible security risk, a “highly critical” 25 out of 25. An educated guess from Drupal consultant Bevan Rudge puts the number of Drupal sites with backdoors at anywhere between ten and ninety percent.
The biggest issue with the Drupal vulnerability was that it allowed anyone to exploit it without any additional authentication. Just one line of code would allow hackers into their databases. That made it a perfect target for automated attacks, which was exactly what happened. With automated scripts, attackers have spent the past two weeks finding and exploiting any unpatched sites they came across, stealing data and installing backdoors that could easily go unobserved for long periods of time.
While this specific issue affected only those using the Drupal platform, there are always lessons to be learned from instances like this. Let’s break down some of the top takeaways from the Drupal SQL Injection Flaw.
1. You can’t put all your eggs in the Open-Source Security Teams’ basket
The vulnerability was actually listed last November in the Drupal issue tracker as a simple bug (with the hashtag #security). It could have opened the floodgates if hackers had found it before the security team did, months later.
The issue was only brought to the attention of the Drupal Team after an independent site running on Drupal performed a private security audit. They discovered the flaw and reported back to the Drupal team. From that timeline, we can glean two lessons:
Drupal QA Engineer Ryan Aslett had an excellent response for the question of who’s responsible for Drupal’s security:
“The question of “who is responsible for something like this” is simple. You are, and so am I. You can peruse the entire codebase and make sure that before running the code that it is secure enough for your own standards.”
2. CMS platforms are both a curse and a blessing
Hosting your site on a CMS platform such as WordPress, Joomla, and Drupal, has both its ups and downs, and with Drupageddon, we came face to face with one of the pitfalls. Once a vulnerability such as this one is reported to the public, the race is on for organizations and malicious actors to either fix the issue or exploit the flaw.
“When vulnerabilities surface, it’s far worse than in a homegrown website because the attack surface becomes everyone with a [CMS-hosted] site, rather than just one site,” says James Brown, CEO at StillSecure told Dark Reading last year. “It’s also more likely to be widely known and, thus, widely exploited.”
While this flaw happened to be in Drupal’s core platform, one of the benefits of using a CMS platform are the bevvy of plugins and modules that allow you to customize your site – without writing the code yourself. But it’s because someone else wrote it, that’s all the more important to take a look at what’s under the hood.
Last summer, Checkmarx did our own research on these popular platforms. We zeroed in on WordPress, the most popular CMS, used by 61% of the world’s CMS users. Our research found that about 20% of the most popular WordPress plugins contained easily-exploitable vulnerabilities and that a total of 8 million vulnerable WordPress plugins were downloaded.
While the off-the-shelf frameworks work well for many organizations, CMS platforms do necessitate a bit more security legwork at times.
3. The time lapse between security advisories and hackers exploiting the vulnerabilities is getting smaller and smaller.
“If your website was not updated within a day of the announcement, it is probably compromised,” wrote Drupal consultant Bevan Rudge. “Even if your website was updated within a day, it may be compromised.”
The fact that within 7 hours of the original security advisory hackers were already using the vulnerability to exploit myriads of sites just goes to show how important proper disclosures are as well as how important it is to follow the news of relevant security advisories.
4. Responsible disclosure goes both ways.
Between the way the original bug was disclosed, to how hackers worked faster than expected to use the vulnerability themselves, we can all mostly agree that the issue wasn’t handled well from the get-go.
The security researchers who discovered the flaw made it clear that they instructed Drupal’s team to disclose the issue in a different way, and others have echoed that sentiment.
As Gavin Millard told The Register, “announcing a fundamental flaw in the code to everyone without giving much runway to the users of Drupal to proactively patch gives ample time for attackers to weaponise the flaw and exfiltrate data or manipulate the systems for later exploitation.”
In response to the incident, the Drupal community has been discussing a variety of solutions going forward. Some have suggested that Security Teams offer a pre-release in order first to warn admins and owners to look out for the security advisory. Others discussed improving the clarity of how security issues are reported and automatically monitoring new issues in the queue.
5. Once again, “more eyes make all bugs shallow” is NOT always the case.
It’s not up to the Drupal Team to make sure the open-source project you’re using is secure enough for your standards. If you’re invested in the security of your site, you’ll go the extra mile and scan the code both manually and automatically – and on a regular basis.
As the Drupal team themselves admitted, software security is never perfect, and the same goes for them. So, does this latest incident prove how insecure open source platforms such as Drupal are? Drupal’s Aslett put it this way: “No. It proves that all software has potential security issues and just like Heartbleed, Shellshock, Poodle, and all of the multitudes of unnamed security vulnerabilities out there, Drupal also may have undiscovered vulnerabilities.”
As we saw with both Heartbleed and Shellshock, just because it is open-source doesn’t mean its bug free; this flaw even dated back to 2008. And while we know better than to think that security by obscurity is in any way better, we also need to understand open source’s drawbacks and work TOGETHER towards remediating them.
6. Strong security policies and controls aren’t just “nice-to-have’s” – they’re a MUST.
Security testing is critical. If anyone came out “on top” in this whole story, it’s the organization that hired the security team to audit their code. A security policy that includes thoroughly scanning and looking at code on a regular basis and implementing updates quickly are a few of the best ways to ensure your own security.
On the other end of the spectrum, many more organizations without strong security policies in place are probably dealing with the blowback from one of the latest security issues. If you’re included in that group, now may be a good time to revise your policies.
7. In security, there is no end.
It’s easy to get in the mindset of using patching and updating as your go-to methods for keeping secure. In reality, that’s just staying afloat, hoping not to get pulled under by any undercurrent that comes your way. Just in the way that the patch and update were not the end of it for a second for Drupal’s security team, keeping your site or system updated is really just the beginning of security for you. In security, as with most other matters in life, there is always room for improvement.
The silver lining here is that while mistakes like this vulnerability happen, there are people and organizations doing it right, including both the team at Sektion Eins who reported the SQL injection vulnerability and the Drupal Team for working with them and getting a fix out as soon as possible. Security is NEVER done, and this is another example of how vigilance and proactivity can pay off.
If you got Drupalled (should that term catch on, it was coined here first!), the good guys at Drupal have a guide for getting your site back into your hands. If you’re a Checkmarx user running a Drupal site, take the time to run a scan on your site’s source code today and commit to fixing the issues you find.
Want to learn more about how Checkmarx can help you secure your site? Contact us today.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.