How to Deal with Open Source Vulnerabilities

Despite the shockwaves following the Equifax hack in September 2017, the industry still has a long way to go in protecting their products. A key area to focus on is the open source components that comprise 60-80% of the code base in modern applications. Learn how to detect vulnerable open source components and keep your products secure.

Much of the world was rudely introduced to the concept of open source vulnerabilities last September when news began to stream out surrounding the hack of credit rating agency Equifax. Attackers had exploited a vulnerability in the Apache Struts2 open source component, making off with the personally identifiable information of some 147.9 million people, mostly in the United States.

By all appearances, the company was unaware that they were using the vulnerable open source component in their web application, and failed to implement a patch in time to prevent the breach.

While hacks like Heartbleed have caught the public’s focus for brief periods, the scope of quantity and quality of information that was stolen in this attack drew a lot more attention of the public..

It was also a wakeup call for organizations that they had a greater range of responsibility to protect the code that safeguards their users’ data, even if it is code that they did not write themselves. This most commonly comes in the form of open source components, made available for use free of charge, and widely used by developers in companies racing to boost their offerings' time-to-market. Developers depend on open source components to provide them with useful features that they would otherwise have to write on their own. Usage of open source is reported to be growing, with Gartner estimating that open source comprises up to 80% of the code in most of the products that we know and love.

However, despite the exploit, security for open source components is still being overlooked by far too many companies that are not aware of the scale of this threat or even how much open source they are really using.

One of the primary causes for this lack of attention would appear to be ignorance of what open source vulnerabilities are, how they are found, and what they can do to protect themselves and their customers.

Back to Basics: What are Open Source Vulnerabilities?

Vulnerabilities in open source are similar to exploits found in proprietary products. These are bits of code that were either written with mistakes that hackers can take advantage of, or features that allow an attacker to carry out a harmful action in a way that was not intended by the author of the code.

In some cases this can lead to issues like a denial of service (DoS) and take a service offline, while other more serious exploits can give the hacker the keys to the kingdom by providing them with remote access to your system.  

However, this is where the similarity between open source and proprietary ends. Whereas in-house code is written by a group of developers who are following the centralized direction of their organization, open source is highly distributed amongst the members of the community who write, fix, and generally maintain the projects.

This centralized versus distributed system is often referred to as the Cathedral and the Bazaar. Without the central design of a distinct organization that plans out its logic and has a standardized system for addressing new additions and fixes, open source code follows a different, often looser set of rules that make it harder to manage.

Stepping into this chaotic space can be complicated for organizations to handle, and is a boon for hackers who take advantage of the lack of centralized control. Far too often, developers will take open source code from one of the multitude of repositories on sites like GitHub, all without checking if the component has any known vulnerabilities. Even worse, very few have solutions in place for tracking the open source in their inventory or products.

So, like we saw in the case of Equifax where they did not know that they were depending on vulnerable code, you simply cannot patch what you do not know you have. Like many organizations that develop code, Equifax may have been using a tool for testing the code in their applications, but it is clear that they did not have one that was built for the purpose of analyzing open source components.

How Are Open Source Vulnerabilities Found and Who is Searching for Them?

Security tools such as Static Application Security Testing (SAST) or Dynamic Application Security Testing (DAST) know how to work well with proprietary code. They work with the logic of how the code is written within the organization, using a set of rules like a Whitelist to find potential flaws in the code that can be hacked by attackers.  

However, because open source is not set up the same way, these tools are of lesser use for finding vulnerabilities. Instead, we are reliant on scores of researchers and community members who spend their time testing through the code to find the flaws. They pour over the code, poke and prod it, test theories of what could go wrong, write their attack code, and try to fuzz the application into giving up the crown jewels.

While they do make use of some automated tools to pick up the low hanging fruit in the code, this testing process is a long and arduous task. By some estimates, it can average researchers three months to find a single vulnerability.

By its nature, open source software is a living, breathing entity that is maintained by a community of developers who donate their time to build better projects. As a part of their effort to make the projects stronger, many community members take the time to seek out vulnerabilities on their own, alerting the project managers when they discover code that could be exploited by malcontents, criminals, and even state actors in some cases. Many of these researchers make their contributions out of their love for open source and the respect that comes with helping to make the code a little bit safer.

Then there are the bounty hunters (noted in the most affectionate of ways) who search for vulnerabilities for the cold cash prizes. In recent years, a mini industry has risen up to help bring hackers in from the cold, allowing them to use their evil skills for good. Bug bounty programs have been set up by many of the large corporations like Microsoft for White Hat hackers to report vulnerabilities and get paid for it.

Companies like HackerOne and Bugcrowd are two of the biggest names in running these bug bounty programs for companies and even the U.S. government. Not wanting to miss out on the fun, there are a number of bug bounty initiatives in the open source community that are backed by some of the major players.

Back in 2014, the Linux Foundation set up the Core Infrastructure Initiative program in response to the Heartbleed vulnerability. They succeeded in bringing on Microsoft, Intel, Google, IBM, Amazon, VMware and many other industry leaders to raise over $3 million for bounties. Another well known program for open source is the Internet Bug Bounty (IBB) initiative that was supported by Facebook, the Ford Foundation, and most importantly GitHub with each backer providing $100,000 for payments to researchers.

Kicking Off the Response to Uncovering an Open Source Vulnerability

When a researcher finally turns up a vulnerability in a project, a series of actions are kicked off as the relevant parties are notified.

The first thing a researcher will do is send on their findings to U.S. Gov-backed non-profit MITRE Corp, the body that maintains the Common Vulnerabilities and Exposures (CVE) registry of vulnerabilities. The good folks at MITRE will then analyze the vulnerability to confirm and provide information about the exploit. This will normally include the severity rating, details about how the exploit can be carried out, and hopefully links to the patch for fixing it. It is at this stage that the vulnerability will be given an ID. This includes the year that it was reported and its unique ID number. For example, the Apache Struts2 exploit that was used against Equifax was identified as CVE-2017-5638.

As the CVE system maintained by MITRE is far from organized, the vulnerability information is listed on the National Vulnerability Database (NVD), which serves as a great directory.

At the same time, the researchers will also contact the open source component’s project managers to let them know that they have a problem to deal with. Under normal circumstances in line with the rules of fair play, the researcher will give the project manager a grace period of 60-90 days to find a fix to the vulnerability before they go public with their findings. With any luck, the project managers will come up with a solution by the end of this period.

After the CVE goes public, the information is available for all as a known vulnerability. This includes the good guys who can use the information to patch their applications as well as the baddies who have gained a free bit of intel that they can then use to target those organizations that are too slow to make the proper fixes.

It is for this reason that known vulnerabilities are the primary threat for open source components. With a wealth of fully detailed vulnerabilities listed on the NVD for free, why would a hacker waste their time trying to find one on their own?

Protecting Your Open Source Components

The challenge for security teams when it comes to open source as we have seen here, is not finding the exploits in the code itself but instead staying on top of known vulnerabilities as they become available.

There are two concerns that need to be addressed in keeping these open source components secure.

The first is to know if the open source components that are already in your inventory and products contain existing vulnerabilities. If your developers have not been using a tool to track which components they have and the security status of those components, then they might find themselves in the same situation as Equifax, lacking crucial visibility.  

In the second case, while it is possible to fix issues in a vulnerable “must have “component, developers should avoid using components with known vulnerabilities when building new products. This means using a solution that can detect vulnerable components before adding them to your inventory or product, even to the point of having automated policies that can fail a build if a developer attempts to commit a risky piece of code.  

Keeping your products — and the data contained within them — safe has become an expectation by customers, and requires implementing the right kinds of tools to catch components with known vulnerabilities before they are exploited by hackers.

Due to the large quantities of open source components that are being used across the industry, developers and security teams need automated solutions that can track all of the open source components in their inventory and products, while monitoring the vulnerability databases like the NVD to receive alerts when new vulnerabilities are found by researchers.

Software Composition Analysis (SCA) tools such as WhiteSource and Flexera were designed exactly for this purpose, and are an essential part of your application security strategy for staying ahead of the hackers, keeping your products safe while maintaining customer trust. Failing to implement an SCA tool leaves organizations open to attack, and let’s be honest — nobody wants to be the next Equifax.  

About the Author

Rami Sass is CEO and Co-Founder of WhiteSource, the leading open source security and compliance management platform. Rami is an experienced entrepreneur and executive with vast experience in defining innovative products, leading technology groups and growing companies from seed level to business maturity.