Meel

Managing Shellshock - A sample approach

Blog Post created by Meel Employee on Oct 7, 2014

Shellshock, you have heard about it, have brainstormed with your teams and now must be assessing how much is the impact to your organization or division. Let’s take a look at some of the steps that you can take to understand and enhance your security posture.

 

Starting point: Take inventory. Identify the devices that are potentially most vulnerable. These include that have “bash” installed on them.

If you are using RSA VRM (Vulnerability Risk Management) you can easily run a query rule to search for all scanned devices that have “bash”. All the information about scanned devices is already stored in the warehouse. VRM creates an active catalog of assets that is auto updated & totally in sync with what network vulnerability scanners are seeing in the environment.

 

The security analyst can run a simple query to find all devices that have “bash”. This will provide the starting inventory of devices. Proactively, the analyst can create alerts so he can monitor on his dashboard the current devices with “bash” and any new devices that are added which have “bash”.

96658

Once you have identified which devices have bash installed, as a second step, check for the devices that have sister shells such as “/bin/sh” installed, as sometimes these are copies of bash.

 

This gives a good first pass on the inventory of devices that could be impacted by Shellshock.

 

Now, you also want to cover your bases by looking for all devices that have the known “shellshock” vulnerabilities. The security analyst can run a search query on devices using CVE ids of “shellshock” vulnerabilities. So far, six vulnerabilities have been identified that are related to Shellshock: CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 & CVE-2014-7187 and CVE-2014-6277 & CVE-2014-6278.

Four of these vulnerabilities (CVE-2014-6271, 7169, 6277, 6278) are related. CVE-6271 is the key vulnerability amongst these and the other three exist because of incomplete fixes.

96659

96690

The patches are not available for some of these, yet. So, keeping a close eye on the inventory of devices would be helpful.

 

So far, you have created a good list of devices by searching for specific vulnerabilities as well as shell (bash or sh).

 

Now, prioritize the devices that need to be patched first. You may want to consider prioritizing these devices based on criticality and business context (who owns the device, risk rating, compliance rating).

As an example, E-mail servers are considered to be potential targets for Shellshock, so you may want to include type of device to patch as a key parameter in your prioritization scheme. Once you have a strategy to prioritize then you can easily add new devices such as Network Attached Storage, which has recently been identified as a target of “shellshock” attack.

 

Once prioritization is determined, kick off a remediation work flow. Involve the decision makers and cross-functional teams that are stake holders. This will provide the necessary foundation to establish the vulnerability management program for Shellshock. Follow-thru by iterative improvement in the process as you go along the remediation process.

 

Manage exceptions along the way, so the risk is properly identified and the concerned people are notified to obtain the risk exception approval.

In summary,

  • Take inventory of devices with Shellshock vulnerabilities
  • Prioritize based on criticality and business context
  • Establish vulnerability management process
  • Use KPIs to iteratively improve the vulnerability management process

 

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Here is a quick summary on GNU bash vulnerabilities:

  1. CVE-2014-6271: GNU Bash 4.3 and earlier contains a command injection vulnerability that may allow remote code execution (aka Shellshock/Bashbug). Bash supports exporting of shell functions to other instances of bash using an environment variable. This environment variable is named by the function name and starts with a "() {" as the variable value in the function definition. When Bash reaches the end of the function definition, rather than ending execution it continues to process shell commands written after the end of the function.
  2. CVE-2014-7169: This vulnerability exists because of an incomplete fix for CVE-2014-6271
  3. CVE-2014-7186: The redirection implementation in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via crafted use of here documents, aka the "redir_stack" issue.
  4. CVE-2014-7187: Off-by-one error in the read_token_word function in parse.y in GNU Bash through 4.3 bash43-026 allows remote attackers to cause a denial of service (out-of-bounds array access and application crash) or possibly have unspecified other impact via deeply nested for loops, aka the "word_lineno" issue.
  5. CVE-2014-6277: This vulnerability exists because of an incomplete fix for CVE-2014-6271 and CVE-2014-7169
  6. CVE-2014-6278: This vulnerability exists because of an incomplete fix for CVE-2014-6271, CVE-2014-7169, and CVE-2014-6277

 

Reach me on Twitter:@RajMeel7 

Outcomes