“Shellshock” effects on the SMB

Late last week, a critical vulnerability (CVE-2014-6271) affecting many Unix-based systems, including Linux variants and Mac OSX was discovered which, in certain circumstances, allows remote code execution on affected systems. In order to achieve remote code execution, an attacker must have access to a bash shell or a service on the affected machine with access to the bash shell. Most notably, widely-used web services such as the Apache web server or an ssh server will in many cases be vulnerable. An initial patched version of the bash shell was later discovered to still be vulnerable with 2 related vulnerabilities (CVE-2014-6277 and CVE-2014-6278) being reported. As of the writing of this article, these vulnerabilities remain at zero-day status.

In layman’s terms, this is a big deal – bigger than the “Heartbleed” vulnerability from a few months back. Working exploit code is available and has already been incorporated into several Metasploit modules. Even scarier, the vulnerability has been present for 20+ years.

Even the SMB that operates (on the surface) exclusively in a Windows environment can be affected. Systems inventories and should be conducted to identify potentially vulnerable systems and risk assessment and mitigation strategies should be implemented. Simply saying “we run Windows so we are safe” is not a prudent tactic to take. Two major classes of potentially overlooked systems that come to mind immediately are:

  • Firewalls and routers – many such devices run Unix-based operating systems under the hood. While administration consoles such as HTTP and SSH should not be accessible from the internet as a security best practice, they commonly are.
  • Third-party hosted sites – web hosts commonly run Apache web servers on Unix-based operating systems. Inventory all sites affiliated with your organization and obtain documentation as to the vulnerability status of these systems from your vendors.

A bash script which will check a local bash version for the various vulnerabilities is available here. We would advise cloning the git repo to allow for easy future updating as the author may continue to update the script as new vulnerabilities are found.

Businesses should naturally focus on services which are accessible from the internet first and foremost, and then circle back through the internal network as internal vulnerabilities still can pose a significant threat. Port scans of your entire public IP range should be performed to ensure that no publicly-accessible services have slipped under the radar. Filtering and IDS/IPS mechanisms can mitigate the threat as signatures are developed, however the best course of action is to deny access to vulnerable systems where possible.

For our financial institution clients, the FFIEC has issued guidance for dealing with these vulnerabilities and businesses of all types will be well served to take similar measures.

The aftermath of this particular set of vulnerabilities is likely to be a slow and painful process as many affected devices are not easily patched – from thermostats and refrigerators to centrifuges and critical healthcare equipment, the world may be quite a ways away from understanding the true breadth and depth of this one.