Open-source vulnerabilities which will not die: Who is to blame?

Major open-source vulnerabilities have wreaked havoc and caused heartache for IT admins worldwide.
Written by Charlie Osborne, Contributing Writer

Open-source technologies are found in popular services offered by the largest technology and Internet companies worldwide.

An audit conducted by Black Duck by Synopsys estimates that 96 percent of commonly-used applications in the enterprise utilize open-source components.

Open-source projects are critical to the fabric of modern-day software and talented developers by the thousands give up their time to create software and critical components that we all use today.

However, the nature of open-source software can allow for vulnerabilities and bugs to go unnoticed, sometimes for decades.

Various bug bounty programs, such as Google Patch Rewards, have been running for years but problems can still slip through the net.

Not all open-source bugs are created equally. A sexy name and promises of doom to any software which relies upon open-source components -- such as libraries -- have been used previously simply for publicity by some companies.

As reported by ZDNet's Steven J. Vaughan-Nichols, the case of GoSecure and the "Chaos" bug could be included in the list, as the "vulnerability" required brute-forcing credentials in the outset, which is only possible when weak or lax passwords are in use.

However, there are still cases in which open-source systems and the overlay software depending on them are placed at real risk.

Equifax, for example, has blamed the use of open-source components as the reason the firm became the victim of a data breach resulting in the exposure of 145.5 million US records.

Names, social security numbers, birthdates, and home addresses, as well as partial driving license details, may have been stolen.

This vulnerability believed to be at fault was in Apache Struts.

In response to Equifax's claims, the Apache Struts Project Management Committee said the attackers "either used an earlier announced vulnerability on an unpatched Equifax server or exploited a vulnerability not known at this point in time -- a so-called zero-day exploit."

It turned out to be the former. CVE-2017-5638 was identified and disclosed by US CERT and patched two months before the data breach took place.

However, Equifax did not update its systems.

When open-source vulnerabilities make the news, it is often the case that the software itself is not at fault; but rather, organizations are failing to maintain patch processes which resolve critical vulnerabilities in a reasonable timeframe -- or due to a lack of understanding, they may not know which open-source components are in use.

See also: Open-source vulnerabilities plague enterprise codebase systems

The Equifax debacle highlighted the importance of keeping systems up-to-date, but there are other open-source bugs which are being left unresolved, too, to the detriment of companies worldwide.

HeartBleed, CVE-2014-0160, is an extremely dangerous security hole in OpenSSL. The vulnerability was discovered in OpenSSL 1.01 in 2014, which at the time was used by an estimated two-thirds of all secured websites.

OpenSSL acted as a default open-source code library for Apache and NGINX web servers. The HeartBleed security flaw allows attackers to remotely expose sensitive data, possibly including user authentication credentials and secret keys, through incorrect memory handling.

A patch was released on April 7, 2014. As of 2017, this vulnerability was still present in close to 200,000 servers worldwide.

See also: How to recover from Heartbleed

Another player from 2014 is ShellShock, CVE-2014-6271, a bug which has been present in Bash for over two decades and has the potential to open up Unix, Linux, and Mac servers to severe attacks.

Successful exploitation of the bug -- which scored a perfect CVSS score of 10 -- in the wild included reports from cybersecurity professionals who observed the execution of payloads including malware droppers, reverse shells and backdoors, data exfiltration, and distributed denial-of-service (DDoS) attacks.

ShellShock is still considered a problem, even today. The reason? According to IBM X-Force researchers, it is a "very cheap attack" as it only requires basic programming skills -- and some servers are still vulnerable, despite a patch being available for years.

Decrypting RSA with Obsolete and Weakened eNcryption (Drown), first made public in 2016, is an OpenSSL vulnerability which utilizes a deprecated security protocol, Secure Sockets Layer (SSLv2), to attack websites, break encryption and steal sensitive information.

TechRepublic: 8 hurdles IT must overcome if they want open source success

At the time of discovery, it was estimated that Drown could hijack close to 30 percent of all HTTPS servers -- which was believed to be roughly 11 million websites. Yahoo, Sina, and Alibaba were among those found to be vulnerable.

Servers which still have SSLv2 enabled are still vulnerable to attack.

Open-source components are found in many services and systems and without them, we would not be as technologically advanced as we are today.

However, there are latent vulnerabilities which, when made public, require companies to scour their systems to find out if they are using particular components, and if so, patch them quickly.

As the average cost of a data breach has now reached $3.86 million, the effort is worth it.

According to a recent Snyk survey, 69 percent of Red Hat Linux vulnerabilities are fixed within a day of public disclosure, and 90 percent were fixed within 14 days.

However, only 25 percent of open-source code maintainers notify users of vulnerabilities and only 10 percent file a CVE, according to the research.

The Equifax incident was due to a bug which was patched, exploits surfaced only days later, and within two months, this caused one of the biggest data breaches to date. This should serve as a reminder for both open-source developers and companies taking advantage of open-source components that security is not the responsibility of just one or the other -- but rather, it must be a collaborative effort.

The top open-source rookies, projects in 2018

Previous and related coverage

Editorial standards