A9 Using Components with Known Vulnerabilities

A9 Using Components with Known Vulnerabilities

Using components with known vulnerabilities is one of the vulnerability categories on OWASP‘s list of the ten most common vulnerabilities.

This kind of attack happens when we are providing full privileges, whether knowingly or unknowingly, to the application components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

The Using Components with Known Vulnerabilities OWASP top 10 entry emphasises the fact that third party software libraries have flaws. 

Two recent examples of software components that are well known, and have been widely used for years, that turned out to have flaws are:

OpenSSL library. A software component often used to help secure data used by web applications. In 2014 the Heartbleed bug was discovered in OpenSSL. This bug allowed data encrypted with the SSL/TLS routines in OpenSSL to be compromised. It’s since been fixed. Update your OpenSSL if you haven’t yet!

BASH Unix shell. The venerable BASH shell, that has been in use for two decades, was discovered in 2014 to have vulnerabilities that allowed command line injections to execute commands. These were dubbed Shellshock. The BASH shell has since been patched to address the issues. Again, update BASH if you haven’t done so recently.

These examples are not given to single out these two pieces of software, rather they illustrate that even software that has been in use for a long time can contain vulnerabilities. All software does. It’s how we deal with these that is important.

Is the Application Vulnerable?

• If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.

• If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.

• If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.

• If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.

• If software developers do not test the compatibility of updated, upgraded, or patched libraries.

• If you do not secure the components' configurations (see  A6:2017-Security Misconfiguration).

How to protect against this vulnerability

• There should be a patch management process in place to:

• Remove unused dependencies, unnecessary features, components, files, and documentation.

• Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. 

• Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use.

• Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.

• Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue.

• Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.