How older security vulnerabilities continue to pose a threat

Security flaws dating back more than 10 years are still around and still pose a risk of being freely exploited, says Rezillion.

Patching security vulnerabilities should be a straightforward process. A vendor issues a patch for a known flaw, and all affected organizations apply that patch. But, what seems simple in theory doesn’t necessarily play out that way in reality. A report released Monday, August 1, by security firm Rezillion looks at how older vulnerabilities patched by the vendor still pose risks to organizations.

The threat landscape spans a decade of known vulnerabilities

For its report Vintage Vulnerabilities Are Still In Style, Rezillion examined the Known Exploited Vulnerabilities Catalog maintained by the CISA (Cybersecurity and Infrastructure Security Agency) (Figure A). Among the 790 security flaws on the list, more than 400 date back from before 2020. Some 104 are from 2019, 70 from 2018 and 73 from 2017. Some 17 go back as far as 2010.

Figure A

The vulnerabilities discovered from 2010 to 2020 affect more than 4.5 million internet-facing systems and devices.

Ineffective patch management for vintage vulnerabilities leaves companies open for attacks

Although fixes have been available for these “vintage vulnerabilities” for years, many of them remain unpatched by customers and organizations. As such, they can still be freely exploited, creating a risk for software and devices that have not been updated. In fact, Rezillion detected active scanning and exploitation attempts for most of these security flaws over the past 30 days.

SEE: Mobile device security policy (TechRepublic Premium)

That problem rests in the life cycle of a security vulnerability. At the outset, a security flaw that exists in a product is potentially exploitable as no patch yet exists, though no one may be aware of it. If cyber criminals do learn of the flaw, then it becomes classified as a zero-day vulnerability. After the vendor issues and deploys a patch, the vulnerability can still be exploited but only in environments where the patch has not yet been applied.

However, IT and security teams need to be aware of available patches from a vendor, determine which patches to prioritize, and implement a system for testing and installing those patches. Without an organized and effective patch management method, this entire process can easily stumble at any one point. Savvy cyber criminals realize all of this, which is why they continue to exploit flaws that have long been fixed by the vendor.

Commonly exploited vintage vulnerabilities

Here are just some of the many vintage security flaws discovered by Rezillion:

CVE-2012-1823

PHP CGI Remote Code Execution is a validation vulnerability that lets remote attackers execute code by putting command-line options in a PHP query string. Known to be exploited in the wild, this flaw has been around for 10 years.

CVE-2014-0160

OpenSSL Sensitive Information Leak From Process Memory Vulnerability (HeartBleed) affects the Heartbeat Extension for the Transport Layer Security (TLS). In OpenSSL 1.0.1 through 1.0.1f, this bug can leak memory contents from the server to the client and vice versa, allowing anyone on the internet to read that content using vulnerable versions of the OpenSSL software. Exploited in the wild, this one was made public in April of 2014.

CVE-2015-1635

Microsoft HTTP.sys Remote Code Execution Vulnerability is a flaw in the HTTP protocol processing module (HTTP.sys) in Microsoft Internet Information Service (IIS) that could allow an attacker to remotely execute code by sending a special HTTP request to a vulnerable Windows system. Exploited in the wild, this bug has been active for more than seven years.

CVE-2018-13379

Fortinet FortiOS and FortiProxy is a flaw in the FortiProxy SSL VPN web portal that could enable a remote attacker to download FortiProxy system files through special HTTP resource requests. Exploited in the wild, this vulnerability has been around for more than four years.

CVE-2018-7600

Drupal remote code execution vulnerability (Drupalgeddon2) is a remote code execution flaw affecting several different versions of Drupal. This bug could be used by an attacker to force a server running Drupal to execute malicious code that can compromise the installation. Exploited in the wild, this one has been active for more than four years.

Tips for managing security vulnerability patches

To help organizations better manage the patching of security vulnerabilities, Rezillion offers several pieces of advice.

Be aware of attack surfaces

Make sure you’re able to see your existing attack surface through the associated CVEs and that you can identify the vulnerable assets in your environment that require patching. For this, you should have a Software Bill of Materials (SBOM), which is an inventory of all the open-source and third-party components in the applications you use.

Back up patch management with the right supporting processes

To support an effective patch management strategy, certain process should be in place, including change control, testing, and quality assurance, all of which can account for potential compatibility problems.

Make sure vulnerability and patch management efforts can scale

Once a patch management process is in place, you need to be able to easily expand it. This means scaling patching efforts as more vulnerabilities are discovered.

Prioritize the most critical vulnerabilities

Given the vast number of security flaws uncovered, you can’t possibly patch them all. Instead, focus on the most important patches. Prioritizing by such metrics as CVSS alone may not suffice. Rather, shoot for a risk-based approach through which you identify and prioritize high-risk vulnerabilities over minor bugs. To do this, examine which flaws are being exploited in the wild by consulting CISA’s Known Exploited Vulnerabilities Catalog or other sources for threat intelligence. Then, determine which vulnerabilities even exist in your environment.

Continually monitor and assess patch management strategy

Monitor your environment to make sure vulnerabilities remain fixed and patches remain in place. In some cases, Rezillion found instances in which vulnerable code that was already patched was added back into production environments by CI/CD (continuous integration and continuous deployment) processes.