We recently released our 3Q 2014 Security Roundup entitled Vulnerabilities Under Attack: Shedding Light on the Growing Attack Surface in which we highlight a number of trends like an increase in PoS malware, mobile attacks, and others. The issue I’ll dive into here is the fallout from the Shellshock vulnerability.
You can read the specifics of the vulnerability in our previous coverage of the bug but the tl:dr version is:
Needless to say, this was a serious issue.
Three months after it’s announcement, now is a good time to look back at the issue and examine it’s impact.
Simply put, bash is everywhere. It’s in a lot of places that don’t have an update or regular support system which means there are still probably a lot of devices out there that are vulnerable to this bug.
Troy tries to ballpark the number using the percentage of Apache installations. I think we can get a better idea of just how big this is with a little additional research.
Netcraft puts the current number of Apache and nginx installs (both almost exclusively run on *nix systems) at 489,984,790 total sites. That’s ~52% of their total survey. In real world terms: a lot.
Additional confirmation that we’re in the right ballpark comes from Google. A quick search using the inurl keyword returns ~497,000,000 results using “cgi-bin” which most commonly uses the underlying shell (odds are bash) to process commands.
So by any measurement, this was an absolutely massive issue. The bug was widely exposed and simply exploited.
I won’t re-hash the issue of how to protect yourself from this issue. What’s truly important about this issue is that it forced us to re-evaluate our perspective on a Linux stalwart and open source software in general.
Bash has been used for so long (the initial release was in 1989) and has had very few reported vulnerabilities. It’s been a flexible and reliable interface to our operating system for years. Because of this, it’s been deployed in everything from watches to massive super computers.
When the vulnerability was confirmed, people started to take a long hard look at how we manage the security of open source projects.
The debate is ongoing (and always will be) but the fact remains that attackers can easily scan for vulnerabilities in open source software since they have access to the source. That’s (obviously) the whole point.
The critical thing to remember is that we–the defenders–also have access to the source and can quickly fix any reported vulnerabilities. Compare that to a closed source project where you’re dependent on the maintainer to update and it balances out.
What Shellshock did highlight is that open source projects and their communities of users need to pay more attention to security.
For open source projects, dedicated security reviews are a must. Most major projects have a great reporting & resolution process. Here’s a great example of the Apache foundation’s process by Jamie Goodyear.
But that’s not enough. We need to get in front of these issues and for that, projects need our help.
If you’re using open source in your organization–and honestly who isn’t?–you should be scanning the source of these applications for security vulnerabilities. Once you’ve done that, contribute your results back to the project.
Open source thrives on community engagement, this is a great opportunity to give back to projects that have given us all some much.
You can read more about this issue and others in our 3Q 2014 Security Roundup report. Want to talk about this more? Find me on Twitter where I’m @marknca.