Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

9/24/2015
10:30 AM
Morey Haber
Morey Haber
Commentary
Connect Directly
Facebook
LinkedIn
Twitter
RSS
E-Mail vvv
100%
0%

Shellshock’s Cumulative Risk One Year Later

How long does it take to patch an entire distribution and bring it up to date? Longer than you think.

When Windows XP reached its end of life, there were approximately 257 outstanding security patches required to bring the OS up to date -- and this was considering cumulative versions for both commercial and business, as well as patch supercedence. Since the source code is closed, it never suffered from the fragmentation issues affecting many vulnerabilities, such as what we saw last year with the now infamous Shellshock -- impacting a half-billion Web servers and other Internet-connected devices.

On September 24, 2014, when the bug was first disclosed, open source, Linux, OS X, embedded systems, and Unix all were affected and in total, versions available from 1994 (version 1.14) to 2014 could be exploited due to this GNU bash shell vulnerability. But in the intervening 12 months, a lot more needed to be done than just patching a single platform and bringing it up to date. That in itself is something many organizations still find difficult to do today.

Why are these facts important on the one year anniversary of Shellshock? Over time, it’s become more difficult to properly perform a thorough vulnerability assessment of all the vulnerabilities that have been found in the past, many of which are still applicable. However, the biggest issue is the cumulative problem of flaws which are affecting systems. Information security teams must remember that Shellshock and other flaws are not gone even though they’ve disappeared from media headlines. Some systems, due to age, end of life, or a vendor’s incompetence, still remain unpatched today.

While mitigating controls may help reduce or eliminate the risk, the fact remains that any newly identified vulnerabilities aggravate the problem and increase the total vulnerability count with each new flaw. Shellshock, as bad as it was and may be still to this day, is just another critical vulnerability in the process and systems that are not being patched, or even assessed. This creates a cumulative risk problem, which could allow an exploit through multiple vectors versus just one.

While this may seem like common sense, it represents an interesting problem: How long does it take to patch an entire distribution and bring it up to date? Depending how many missing patches exist, more time is needed to remediate and with each new finding the snowballing effect of risk grows. This is true for any operating system and application, even when a single cumulative security update is available; the more you have to patch, the longer it will take, and the more it costs to do so.

So how can infosec teams reduce the cumulative side effects from new vulnerabilities? Here are five suggestions:

  1. Ensure that your organization has a vulnerability assessment and patch remediation process to identify risks. This helps make sure you’re patching quickly. Once a flaw is found, regardless of how, it can be closed in a timely, non-cumulative fashion.
  2. When selecting technology vendors, verify that service level agreements include security and maintenance patches, as well as end of life dates for operating systems, embedded devices or applications. This will ensure that as solutions are being deployed, they can be remediated for the life expectancy of the implementation.
  3. Vulnerability assessments themselves have evolved greatly from the days of network scanners. Many security tools from IDS/IPS systems, endpoint agents, next-generation firewalls, sniffers, etc., can detect vulnerabilities that are dormant or being actively tested in a hostile environment. Do not rely on just one technology to identify risks and missing security patches. Leverage every single one and correlate the information to identify weaknesses and attacks.
  4. Credential access is always a problem with sensitive hosts and when un-hardening is just not permissible. When local agents are not permitted to do the work (patch management, Windows update, or even vulnerability assessment agents), consider having a cloned isolated lab environment where remote access is permitted (un-harden duplicate hosts) to perform assessments. The results can then be applied to production. This works well with cloning features present in many virtualization technologies.
  5. When network assessment technologies are being deployed, work with the network infrastructure team to logically place scanners as electronically close to targets (not over WAN links) as possible. Avoid scanning through firewalls, other security sensors, and whitelist the scanner only when needed. They should be close enough to each subnet that they have unrestricted access to each target they are responsible for and every port. This includes whether they are hosted in the cloud, as a virtual image, or even a physical scanner in a remote country.

When was the last time you checked under the hood for the cumulative impact of Shellshock or other vulnerabilities? Let’s chat about that in the comments. 

With more than 20 years of IT industry experience and author of Privileged Attack Vectors and Asset Attack Vectors, Morey Haber joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. He currently oversees the vision for BeyondTrust technology ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
100%
0%
Joe Stanganelli,
User Rank: Ninja
9/27/2015 | 11:05:41 PM
Patching
Excellent points.  In my convos with IT security professionals, poor patch management is perhaps the biggest and most prolific problem they see -- and it's extra frustrating because it's such a simple fix (assuming, of course, you have a good testbed available -- lest you end up like Verizon not too long ago).
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.