It has been less than a week since news of the Shellshock vulnerability emerged, and the dust hasn’t settled yet. Our Tenable security experts share their reflections on the situation and their recommendations for reducing your exposure to Shellshock and other vulnerabilities.
Reduce your risk
Ron Gula, CEO
Along with implementing patches and fixes as they become available, there are several steps you should take to help manage your risk and reduce the threat from Shellshock.
- Work with your SIEM or Log Team to identify systems that run Bash scripts on your Linux or OS X web sites. Make these your top priorities for patching.
- Patch the vulnerability on any Internet facing Linux or OS X server or any heavily used multi-user server.
- Audit your Linux servers to look for Bash core dumps. A core dump could be the result of a successful exploit or a successful test.
- Ensure that your patch auditing program is actually auditing 100% of your assets.
- If your SIEM is collecting logs from your web sites and Linux servers, make sure that it is also collecting process accounting, which enables detailed logging of executed commands.
The best and easiest way to test for this vulnerability is to perform a credentialed patch audit of your system.
Unlike Heartbleed, which was trivial to detect with uncredentialed scanning but was difficult to patch, Shellshock is difficult to detect with uncredentialed scanning but easy to patch. With Heartbleed, all you needed was network access and you could do a reliable audit. With Shellshock, doing a good network test is a matter of having the proper configuration and being able to identify the many potential attack paths. The best and easiest way to test for this vulnerability is to perform a credentialed patch audit of your system.
IT auditing shops that don’t have mature relationships with their IT administrators may not be able to audit for this. Detecting the exploit is tricky. There are network IDS rules to detect the attack on unencrypted (non-SSL) web servers, but IDS rules to look for this attack over SSL or SSH won’t work. Instead, solutions which can monitor the commands run by servers and desktops, such as Tenable’s SecurityCenter Continuous View, can be used to identify commands which are new, anomalistic and suspect.
Peace of mind
Dick Bussiere, Principal Architect, APAC
The Shellshock vulnerability stands in stark contrast to the Heartbleed vulnerability in one important way.
Heartbleed was conceptually simple to understand. A vulnerable machine had some region of memory directly accessible to an attacker. That's obviously bad, is easily and directly exploitable, and clearly needs to be fixed.
Identify any machines that are potentially exploitable, and patch those systems
With Shellshock, the attack vectors are not so easily understood. Whether Shellshock is exploitable on a given machine depends on a more complex interaction between Bash and other subsystems on the given system. These interactions are often difficult to completely understand and test. And yes, the system may be vulnerable but, unlike Heartbleed on a system directly exposed to the Internet, it may not be exploitable.
That said, the best course of action is to identify any machines that are potentially exploitable, and patch those systems. This eliminates the risk, and also results in peace-of-mind for the system owners and administrators.
Patch and patch again
Jack Daniel, Technical Product Manager and Strategist
Check the latest list of released proofs of concept and potential Shellshock targets on Github for guidance.
Detect, validate, research, repeat
With more Bash bugs coming into the pipeline, exploitability may be different for each bug. And, of course, vulnerability or invulnerability to one bug may not translate to a similar situation for the next bug. And finding a “vulnerable system” doesn’t necessarily mean the system is vulnerable. So your strategy should be to first patch everything you can find, then look for vulnerable systems you may have missed. Detect, validate, research, repeat—for every type of system in your environment, and for every bug.
Continuous monitoring is vital
Craig Shumard, Advisory Board Member
Continuous vulnerability monitoring is not only vital, it is required today.
The Shellshock Bash vulnerability again demonstrates that having state of the art vulnerability assessment and patching capabilities are critical. It is not only critical, it is vital. The challenges to remediate the Shellshock vulnerability is that many vendors have already issued more than one patch, and it is expected that more patches will be needed to fully eradicate the vulnerability as new ways that the vulnerability can be exploited are discovered. What that means is that enterprises need mature and state of the art vulnerability assessment and patching capabilities. Specifically, enterprises need near-time inventories of their systems. And they also need to continuously scan their systems as new system are on-boarded. Again, demonstrating that continuous vulnerability monitoring is not only vital, it is required today.
The golden state
Jeff Man, PCI Security Evangelist
This is a good time to have a solid configuration management strategy with a standard build/gold image so you can forego an audit, check the master copy and push out an emergency update as needed when major vulnerabilities such as Shellshock are discovered.
The scramble to fill holes
Gavin Millard, Technical Director - EMEA
It’s good to see the operating system vendors releasing patches to address the issues exposed with Shellshock, especially with Apple now patching OS X and Red Hat delivering code that should hopefully cover the majority of the known attack vectors. However, the scramble to fix does raise some important questions we should consider:
We need to come up with a better way of encouraging reviews of critical code
- Why weren’t operating system vendors given more time to develop and release patches for such a critical vulnerability? There are always concerns from the security community around delaying disclosure, but when a vulnerability of such magnitude that can affect so many systems isn’t given time to be addressed properly, it can have massive ramifications for everyone. A major Xen vulnerability has been embargoed until tomorrow to give large cloud providers time to fix, but no such time was given to the OS vendors for Shellshock.
- With this being the second major vulnerability that has existed on a heavily used open source project but missed for an extended amount of time, we should consider Linus’ law of “Given enough eyeballs, all bugs are shallow” inaccurate. With a simple flaw in one of the most broadly deployed utilities in Unix having such a glaring hole for so long, we need to come up with a better way of encouraging reviews of critical code like Bash, the Linux kernel and other broadly deployed utilities.
Internet cracks in the foundation, not structural damage
C. Thomas, aka Space Rogue, Tenable Strategist
Shellshock, Heartbleed, and several before that have exposed the cracks in our foundation. The flaws that have always been there are now illuminated by the news camera’s spotlight for all to see, in glaring high definition, if only someone had bothered to look.
Our Internet house is not going to fall down
Unfortunately the spotlight is focusing randomly in specific areas and only showing us the most glaring holes. When it does, we ready the QUIKRETE® and patch as fast as we can lest our house comes falling down. Tomorrow the spotlight will move on and find yet another crack in a different wall—a crack that has been there for some time and was never noticed because of the darkness. Despite the cracks in our Internet foundation that have already been discovered and the ones that are waiting to be illuminated, our Internet house is not going to fall down, it is not going to become a smoking pile of rubble. Sure, there may be some water seepage in the basement where the bad guys can get in, but I firmly believe that our house is on solid ground so long as we keep the QUIKRETE at the ready.