About
One of the most prevailing risks to the organization are not an unknown weakness, but the complexity of the web application itself.
Description
Vulnerable and Outdated Components are vulnerabilities, gaps in the security of the components, that have been discovered either by the developer or user of the products or by the hacker/intruder.
One of the most prevailing risks to the organization are not an unknown weakness, but the complexity of the web application itself. Most of the code in a modern web application is not original or built in-house, but components come from several sources. Sometimes you use third-party vendor products or open-source projects hosted on sites such as GitHub, and even those components depend on other components from different sources. Open-source software has revolutionized the modern tech industry and nowhere is that more noticeable than the domain of web application development. Nowadays, developers can create complex web applications, usually at a fraction of the cost— in both time and money—compared to years past, which comes at an expense. The use of open-source components is so widespread that many development leaders don't even know what they have. Hence, it is becoming more common for them to be unaware of all the components the application is using, making it impossible to address all the vulnerabilities.
Attackers identify a vulnerable component by scanning the system using automated tools or by manual analyzing, which is less common since more advanced skills are required. Plus, the majority of attackers are not going to invest the time and effort needed to design a custom exploit, especially if they can find security flaws within your application or application’s dependencies effortlessly.
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. The exploitation of the vulnerability can facilitate severe data loss or server takeover. Applications and APIs using components with these vulnerabilities may undermine application defenses and enable various attacks and impacts.
Overview
According to OWASP, the problem of using vulnerable and outdated components is highly prevalent. The estimation is that well over 80% of all software includes, at least, some open source components. According to WhiteSource’s research, “91% of software projects contain indirect open source dependencies. The average project relies on no less than 64 different libraries with eight different licenses.” Also, “in 65% of the cases, open-source components bring with them additional dependencies that are subject to a different license.”
Sometimes vulnerabilities are deliberate since the developers often leave “backdoor” into their systems to access it remotely after it is deployed. Most, however, are unintentional. These are due to security gaps inherent in the design of the product.
Detection
The first step is to use static code analysis and check the technologies. Some scanners such as retire.js help in detection, but determining exploitability requires additional effort. You might also find CVEs with public exploits on multiple online resources, such as Exploit DB for public exploits, Snyk for open-source libraries, and CVE databases for vulnerabilities.
Potential impact
The possible impact of open source vulnerabilities ranges from minor to some of the broadest breaches known.
Prevention
While OWASP acknowledges that the easiest way to avoid known security risks is to evade using components that were not written in-house, they also underline that this is an unrealistic option. Such a course of action would deprive a company of valuable resources and significantly increase the cost and timeframe of any development projects.
OWASP also recommends 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.
Cases
In July of 2017, Equifax, a United States credit bureau, encountered a massive data breach that leaked the personal information of over 147 million people. The scope and impact of this data breach are remarkable. The direct cause of the breach was inadequate management practices, which meant their components would go quite some time without getting patched. Several months before the attackers hacked into the network, a vulnerability was found in the Struts framework, Apache Struts CVE-2017-5638. Attackers used this vulnerability to gain access to Equifax’s system, and from there to personal data.
The vulnerability was also found in Spring Remote Code Execution. Attackers misused the Expression Language, giving them the ability to execute arbitrary code, which then resulted in the server take-over.
____________________________________________________________________________________________
References and more information:
Last updated