Coders Conquer Security: Share & Learn Series - Using Components with Known Vulnerabilities

What is the one thing that all applications have? Components, also known as dependencies or libraries. There is very little code in the world that doesn't depend on other code at some point in time. You even start with a mountain of dependencies from the time you create the application!

Since all applications use components, most of which you haven't written, vulnerabilities within the components you use can become liabilities. Let's discuss what using components with known vulnerabilities means, how dangerous it is, and how to resolve it.

Understand Using Components with Known Vulnerabilities

All complex software has vulnerabilities. That's the nature of the beast. So your components will never be 100% safe. However, when vulnerabilities are found in components, do you know about it? Are you prepared for it?

Problems arise most often when components are used past their useful life or after vulnerabilities are found. Most components and libraries release patches for security vulnerabilities at or before the same time the vulnerability is announced. Therefore, when vulnerabilities in components are discovered and announced, updating the components as soon as possible is of utmost importance. Don't leave vulnerable software in production.

Components can come from several sources. Sometimes you buy third-party vendor products which integrate directly with your custom code. These components become a part of your code and operate at the same level of privilege. Another source is open source projects hosted on sites such as GitHub. Open source can be dangerous since not all open source libraries have been carefully vetted or audited for vulnerabilities.

Attackers use component vulnerability information to their advantage. Since the vulnerabilities are announced publicly, attackers know about the vulnerabilities the same time you do. Attackers also have techniques they can use to find out what components you're using. Once they know this information, they'll know how to attack your application if it isn't patched.

Know Why Vulnerable Components are Dangerous

If you're looking for evidence of how dangerous using components with known vulnerabilities is, look no further than the Equifax breach of 2017.

In July of 2017, Equifax, a United States credit bureau, discovered a massive data breach which leaked the personally identifiable information of over 147 million people. The scope and impact of this data breach is unprecedented. Recently, news has come out about Equifax's lax security practices.

One of those lax practices was patch management. Equifax didn't have good patch management practices, which meant their components would go quite some time without getting patched. This was the direct cause of the breach.

Equifax's website used the Apache Struts web framework. Several months before the attackers hacked into the network, a vulnerability was found in the Struts framework, Apache Struts CVE-2017-5638. However, Equifax didn't patch the vulnerability. Attackers used this vulnerability to gain access to Equifax's network. From there, they gained access to a treasure trove of personal information.

Many websites are based on web frameworks not written by the company. This is standard practice since building in all of the necessary functionality from scratch would be too large of an undertaking. However, depending strongly on a framework can open you up to vulnerabilities. Don't become the next Equifax.

How to Protect Against Vulnerable Components

There is no silver bullet to protecting against using vulnerable components. However, there are policies and controls you can use to mitigate the risk of vulnerable components being used to compromise your systems.

You need to know what components and which version of each component you're using to build your applications. Dependency management tools such as OWASP's Dependency Check help you to get a handle on what dependencies you're using. Dependency Check will also tell you if any of those components has a publicly disclosed vulnerability.

A patch management methodology is also essential. When vulnerabilities are discovered, have a system in place for the patches to be downloaded, tested, and released into production smoothly. Keeping your software patched prevents months-old vulnerabilities from being used by attackers.

Finally, have policies in place governing the use of open source and third-party components. Developers don't like to have red tape, and that is understandable. However, there has to be a vetting process for code not written by your organization. It doesn't have to be heavyweight, but is a must to prevent unknown components from being used. At the least, an inventory of components used must be kept up-to-date.

Don't Get Bitten by the Third-Party Bug

Components will have vulnerabilities. You business applications will use components, whether from a vendor or from an open source library. This doesn't mean your organization need be vulnerable to attack.

Even though attackers know what vulnerabilities exist at the same time you do, patches usually are made available at the same time as the public announcements. So, be sure to educate yourself on what your application is using. Know what is vulnerable. Keep your components patched!

Ready to discover (and defeat) some vulnerable components? Head to the arena to engage in battle: [Start Here]