OWASP Top 10 - Using Components With Known Vulnerabilities

Welcome to Secumantra! In this post, we’re going to talk about the number nine vulnerability from OWASP Top Ten – Using Components With Known Vulnerabilities.

OWASP (Open Web Application Security Project) is a nonprofit foundation that works to improve the security of software. OWASP Foundation is globally recognized by developers as the first step towards more secure coding. It releases OWASP Top Ten list every 2-3 years sharing the most critical security risks to modern web applications.

Components With Known Vulnerabilities

Open source software has revolutionized the modern tech industry. Due to increasing number of open source languages, frameworks and development tools, developers are able to create rich and complex web applications, usually at a fraction of the cost— in both time and money—compared to years past.

Even a simple website such as personal blogs have a lot of dependencies and open source components being used. As everyone wants to focus on core business, common features are implemented using readily available third party components. It can be either open source or licensed one.

Known security vulnerabilities are those security risks that have been identified, either by the developer/vendor of the products used, by the user/developer, or by the hacker/intruder. To exploit such vulnerabilities, hackers can identify a weak component in the system by scanning the system using automated tools or maybe manually. If it is present in your system, it is an easy target for an attack.

Generally owners of such components share information about any new vulnerability found in a released version of the component. Failing to update such third party dependencies for the backend and frontend of a website will keep your system at a risk.

Detection

You are likely vulnerable to the risk of using components with known vulnerabilities:

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 Security Misconfiguration).

Examples – Attack Scenarios

Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:

CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.
While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices).

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability that was patched in April 2014.

Prevention

Each product and solution should have a clearing process for third party components as a part of release criteria. 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.

Vendors generally address security vulnerabilities as they identify them and provide product updates or release a new version of the product. Keeping the components and libraries updated with the latest patches and upgrading as soon as the newest version becomes available helps significantly reduce the number of known vulnerabilities that put the application at risk.

Unfortunately it is becoming more common for developers to be unaware of all the components their applications are actually using, making it impossible to address all the vulnerabilities. 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.

OWASP Risk Rating

Let us look at the OWASP risk rating matrix –

Known vulnerabilities are vulnerabilities that were discovered in open source components and published in the NVD, security advisories or issue trackers. From the moment of publication , a vulnerability can be exploited by hackers who find the documentation.

It is easy to find already-written exploits for many known vulnerabilities, but other vulnerabilities require concentrated effort to develop a custom exploit.

A9:2017-Using Components with Known Vulnerabilities (source-OWASP)

According to OWASP, the problem of using components with known vulnerabilities is highly prevalent. Moreover, use of open source components is so widespread that many development leaders don’t even know what they have. The possible impact of open source vulnerabilities ranges from minor to some of the largest breaches known.

Summary

Many web applications use open source or third party components today. Components, such as libraries or frameworks run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

To avoid the risk of using components with known vulnerabilities, we should take care of using only needed and that too from trusted sources. Always keep these components up to date and apply suggested patches.

When securing your applications against any critical vulnerability (specially from OWASP Top Ten), it is always a good practice to follow defense in depth strategy.

Thank you for reading. Stay Safe, Stay Secure!