Updated: Added information about Macs and some additional reference links.
This new vulnerability is much easier to exploit than heartbleed and can have a huge negative impact to your organization. Windows Server environments are not immune either. We have been waiting for the dust to settle before jumping on the media hype about all of this, and we wanted to make sure that information was gethered from multiple sources, official security organizations had made their opinions public, and that we weren’t just posting information to try and gather web hits.
According to Errata Security
What is ShellShock?
Shellshock is a vulnerability in a shell within Linux called Bash. This shell is available on much of the web; at least 35% of all web servers are running Apache which doesn’t necessarily mean those servers have Bash installed, but many if not most of them will.
For a comprehensive and technical overview of the bug, visit TroyHunt’s post about it. We are not going to dig into the details; we want to make sure you have the information you need to make a decision for your organization.
Why should my organization be concerned?
This vulnerability can allow an attacker from the outside without access to anything, but a public facing webpage to gain access to a shell. In the best case scenario, we don’t anyone gaining a shell on an internal system because they would have the potential to perform any command they want. Now, there are commands that require elevated priveleges to execute, but I have found more than my fair share of web servers running sites as root or similar. The attacks also don’t have to come from the web. Early proofs of concept have shown vulnerabilities from SSH and DHCP as well as other protocols as well. This vulnerability is a perfect candidate for a wide spread worm.
According to Robert Graham at Errata Security, the issue is much more widespread than we think, and the vulnerability is already being exploited and attacked in the wild.
To summarize, this vulnearbility could potentially provide someone full control of a server with minimal effort(look how easily the vulnearbility was exploited here by just browsing to a web page or here by setting up a DHCP server). Think about it, if a DHCP server can exploit, and Macs are vulnerable, what is the risk of using a Mac on public wifi now? That is why the CVSS score is as bad as it gets:
CVSS Severity (version 2.0):
CVSS v2 Base Score: 10.0 (HIGH)
Impact Subscore: 10.0
Exploitability Subscore: 10.0
CVSS Version 2 Metrics:
Access Vector: Network exploitable
Access Complexity: Low
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service
Source: NIST
How do I know if I am vulnerable?
On a linux machine (this can be devices with embedded linux as well such as phones, routers, switches, etc) run the following command:
env x='() { :;}; echo this machine is vulnerable' bash -c "echo testing"
If the output of this command contains ‘this machine is vulnerable’, then it is.
Macs are vulnerable as well, but there is a little more effort to test. Additionally, users are dependent upon Apple to push out the updates.
What do we do?
That one is tough because not all systems have updates. For those that do have updates, it can be completed with minimal effort (though standard change control procedures should be used). Many linux distributions have released updates, but as some researchers have noted not all fixes have worked.
Here is the processes we suggest taking within your network:
- Don’t panic, most of your primary systems are not vulnerable.
- Identify all systems that may be running bash which includes Macs (giving priority to any with public facing websites or even services such as Telnet, FTP, SSH, etc)
- First, if you have public facing Telnet or SSH turn it off. If you have public facing FTP, it should at least be running SFTP or FTPS.
- Contact vendor support or vendor resources and determine if patches are available (here is a good starting point for vendor information)
- Deploy patches, and retest
- For devices where patches are unavailable, consider the risk to the organization, if the risk outweighs the benefit consider options including shutting down the device
- Is the device public facing?
- Does it have direct access to important information?
- What would the impact to the business be if this device went down?
- Is this device necessary?
If you need assistance performing any of the services please contact us at info@securit360.com or call us at 205-202-4233.
