The Dangers of Open-Source Vulnerabilities, and What You Can Do About It

Neglecting basic security practices exposes companies to long-standing security threats.

• By Gilad David Maayan
• Aug 19, 2019

Currently, about 96 percent of the applications in the enterprise market use open-source software. On the one hand, this makes development easier for both developers and third-party vendors. On the other hand, it presents risks and exposes some die-hard vulnerabilities.

The reason behind the open-source vulnerability relies exactly on its openness, as the same code is seen by all users, including attackers. Therefore, once they find an exploit or flaw, they will use it to cause harm, retrieving sensitive data from systems that have not been updated. Attackers can lurk inside a network for months undetected, as happened with the Equifax breach in 2017, which exposed 145 million customers due to outdated software.

What Are Open-Source Vulnerabilities?

Open-source vulnerabilities and exploits in proprietary products share similarities. Both involve poorly written code, leaving “holes” or gaps that attackers can use to carry out malicious activities, such as modifying the code to extract sensitive data or damage the system.

Some examples include instructing a computer to “flood” a system with requests, leading to issues such as Denial of Service (DoS) effectively taking down a service. Other exploits can include the hacker manipulating a system remotely, leaking financial and personal information or even taking over a system and demanding ransom.

However, there are significant differences between open-source and proprietary software. A dedicated staff of professional developers is behind proprietary software, writing the code according to the directives of their organization. On the other hand, open-source is, well, “open,” meaning anybody can write, fix and maintain the projects.

Proprietary software involves a central design by an organization that standardizes its process for new additions and fixes. Open-source is a bit more chaotic, with contributors adding new features and improving the software all the time.

This lack of central control gives plenty of opportunities for attackers to find gaps and vulnerabilities. The fast pace of development, driven by DevOps methodologies, implies that developers will sometimes use open-source code from free repositories without properly checking that they are not inserting vulnerabilities into the project. While there are software solutions that track the open-source code origin, not all emerging dev companies have the resources to deploy them.

The main problem with open-source software is that because of its distributed nature, a vulnerability can remain undetected for a long time. In turn, an attacker exploiting it can hide for an extended period of time. The main reason open-source is so vulnerable is exactly because it is free and built by unaccountable users. Therefore, most large open-source companies pay users to detect vulnerabilities, including Google Patch Rewards, with reasonable success.

Not all vulnerabilities are the same and the degree of severity varies greatly, with most reports consisting of minor and easily patchable ones. However, sometimes open-source vulnerabilities pose a serious risk. Unfortunately, these are often discovered after a meaningful data breach has occurred. One such example is the now infamous Equifax data breach.

In 2017, vulnerabilities in the open-source code led to a data breach of more than 145 million records in the U.S.A. While the vulnerability was patched two months before the data breach, since the company didn’t update the systems, the patch didn’t have the chance to run. This led to the creation of the term “zero-day attack.” By following simple security procedures, companies can avoid similar heartaches.

Causes of Open-Source Risks

As we mentioned above, failure to patch or update software is the number one cause of vulnerabilities. Another aspect that is strongly debated in the security community is the need for disclosure of vulnerabilities.

On one hand, disclosing the vulnerability as soon as it is discovered allows for the open-source community to come out with the patch and fix it. On the other hand, it also opens the door to attackers to take advantage of this freshly discovered vulnerability.

Let’s see some of the causes of the risks in open-source code:

• The public nature of the code—in open-source projects, all the code is available to anybody, so people within the community can pool resources and identify flaws in the code, repairing the issue before announcing the vulnerability. However, since all vulnerabilities become public information on the National Vulnerability Database (NVD), attackers can use this same information to target an organization that still didn’t apply the patch.
• Operational risks—using open source components can expose an organization to operational issues by not tracking open source components and updating them.
• Rights infringement—companies that don’t track the open-source components sometimes face intellectual property infringement.
• Malpractice of developers—careless developers copying and pasting code from open source repositories can involve transferring the vulnerabilities to the project they are working on. In addition, once the flawed code is added to the codebase, there is no way to update it or track it. Therefore, the whole project is subject to the vulnerabilities introduced with the external code.

Examples of Known Vulnerabilities

Heartbleed

Meet CVE-2014-0160. Also known as Heartbleed, is another example of a die-hard open source vulnerability. This security hole was discovered in OpenSSL 1.01 in 2014 when the software was used by two-thirds of the secured websites through the Apache and NGINX code library.

The Heartbleed vulnerability resulted in a fully open way for attackers to enter and extract sensitive data remotely, causing users to lose authentication credentials and stealing secret keys. Although a patch was released in April, 2014, it still has not been updated in about 200,000 servers worldwide using the unpatched version.

ShellShock

CVE-2014-6271 is another open-source vulnerability coming from 2014, operating in open-source components for decades before it can be resolved. Started in Bash for over 20 years, and can open Linux, Unix and Mac servers to severe attacks.

Eventually, the bug was exploited through malware droppers, backdoors, distributed denial of service attacks and even data exfiltration. Moreover, it is still not resolved nowadays. This “cheap attack”, as it is called by the IBM X-Force, only requires basic coding skills to enter servers that are still unpatched, even when there is a patch available.

Tips for Keeping Open-Source Components Secure

After reading the examples mentioned above, it is not surprising that the first tip is to update your open source components and software. Since more than 80% of the breaches happen at the application layer, and sometimes up to 80% of the codebase is open-source, protecting and checking the code for vulnerabilities should be a must in every developing process.

Because of the distinct characteristics of open source software, it requires unique solutions, such as Software Composition Analysis (SCA) tools that can identify and track open source components in your environment, generating alerts when discovering vulnerabilities.

Other tips include tracking your open source components, monitoring to find vulnerabilities and creating open-source code use policies.

The Bottom Line

A meaningful data breach can cost millions of dollars to fix, and the long term consequences can be disastrous. Neglecting basic security practices exposes companies to long-standing security threats. Open-source code is not going away, given how its advantages have driven the technology revolution. The only answer is to implement simple and effective measures, using solutions and tools designed to address its specific challenges.