OWASP Top 10 in 2021: Vulnerable and Outdated Components Practical Overview

If you know about a vulnerability, you can be certain that adversaries also know about it – and are working to exploit it. It sounds like a no-brainer; but using components with known vulnerabilities still makes #6 in the current OWASP list of the ten most critical web application security risks.

Application Security Series
Monday, May 10, 2021

Panamanian law firm, Mossack Fonseca (MF), closed its doors in March 2018. The reason goes back to 2015, when MF was breached, and the subsequent leak of confidential papers between MF and its clients that became known as the Panama Papers. The mainstream media focused on an international corporate and celebrity tax-avoidance scandal; but the cybersecurity focus was on one of the biggest and most dramatic breaches in history. 2.6 TB of data comprising 11.5 million documents on client/attorney information for more than 214,000 offshore entities were leaked from Mossack Fonseca.

Do you want to have an in-depth understanding of all modern aspects of
Vulnerable and Outdated Components?
Read this article and bookmark it to get back later, we regularly update this page.

The cause of the breach was nothing more complex than exploitation of unpatched versions of WordPress and Drupal used by MF. The applications had known security issues that had been fixed by the developers – but MF had failed to apply the appropriate security updates.

Using Components with Known Vulnerabilities

More and more apps are using pre-existing components rather than being coded completely from scratch. Web applications often need fast turnaround, and with the quantity of open-source components available, there's no reason not to make use of them. Analysis indicates that 96% of applications make at least some use of open-source components. On average, more than half of an application's codebase consists of open-source rather than proprietary code.

96% of applications make at least some use of open-source components.

The problem is exacerbated by the tendency for software developers to use open source components often developed by programmers in developing countries. Under pressure to deliver at speed, these components are not sufficiently checked before use. The result can be new websites and applications with deeply embedded vulnerabilities unknown to the application operator. But once that vulnerability is discovered by cybercriminals, applications using the vulnerable component can be found and exploited. It could be a simple flaw in a small component, but one that ultimately makes the entire system hackable.

This is a serious problem for small (and sometimes not-so-small) companies or individuals who make use of JavaScript, PHP or Python libraries to obtain free pre-written routines used to make their websites more appealing and/or interactive. Since the libraries exist, the scripts are often used without being checked, or any awareness that they may introduce a vulnerability to the application.

Of course, there's no guarantee that any component of an application – open-source, proprietary or licensed – will be fully secure. Developers and/or security researchers often discover new vulnerabilities after publication, and issue security patches to correct them. Not all components will receive the necessary patches, but even when they do, if the user fails to apply them, the vulnerability remains.

Unpatched known vulnerabilities are a serious risk. As soon as a vulnerability is fixed by the developer, its existence becomes public knowledge. Hackers rush to develop and use exploits before users have time to patch the applications. This is a growing problem: Gartner has predicted that by 2020, 99% of exploited security flaws will have been already known for at least a year.

Gartner has predicted that by 2020, 99% of exploited security flaws will have been already known for at least a year.

Security databases like the Mitre CVE and the NIST NVD collate publicly known security vulnerabilities. They provide an easy way to see at a glance if an application, API, CMS or other app or component has any associated security vulnerabilities. However, by the time a vulnerability makes it on to a public database, the application should be considered at risk until it is patched.

The extent of the problem

Placed at ninth out of ten security risks, it may appear as if using components with known vulnerabilities would be one of the lesser risks. This would be a mistake.

Analysis by Snyk, an IT group focusing on open-source components and code, placed the risk as the most disastrous of the OWASP top 10. Using components with known vulnerabilities accounts for 24% of the known real-world breaches associated with the OWASP top 10.

According to Veracode's 2017 State of Software Security, 77% of all applications contain at least one security vulnerability. This applies to Java especially, with more than half of all Java applications using components with known vulnerabilities.

According to Ponemon’s June 2018 State of Vulnerability Response report, 48% of companies have suffered a breach in the last two years, and 58% of those involved a known and unpatched vulnerability.

According to Ponemon, 58% of breaches for the last two years involved a known and unpatched vulnerability.

Two incidents, involving credit reporting firm Equifax last year and open source CMS Drupal this year, illustrate the problem. In September 2017, Equifax disclosed that it had been breached, and the personal details of 145 million people had been stolen. This figure has been amended upwards on several subsequent occasions. The point here, however, is that the breach was facilitated by a flaw in its Apache Struts system that had been fixed (but not patched by Equifax) six months earlier.

This year, a series of flaws in Drupal, so severe that they were labelled Drupalgeddon 1, 2, and 3, have bedevilled the world’s leading open source content management system. The Drupalgeddon 1 flaw was tracked as CVE-2018-7600 and patched in March 2018. Attackers started exploiting this flaw two weeks after the patch became available. In May it was reported that Drupal websites were having cryptominers and RATs installed via this and the other flaws.

Despite fixes being available, Drupal websites were continuing to use a component with a known vulnerability, and were suffering the consequences.

The BlackDuck 2018 Open Source Security and Risk Analysis report states that 8% of the codebases it had audited contained Apache Struts (as used by Equifax), and that 33% of those still contained the Struts vulnerability more than a year after it had been fixed. The report also shows that the use of open source software is growing; that 78% of the codebases it audited contained at least one vulnerability (with an average of 64 vulnerabilities per codebase); and that on average, these vulnerabilities were disclosed more than 6 years ago.

With GDPR now in effect, the business impact of using components with known vulnerabilities has become potentially more severe. A company's liability for a breach under the regulations greatly hinges on whether all viable preventative steps have been taken. In the eyes of regulators, any breach arising because of a documented vulnerability being present in an application will make the company culpable. With the potential fines so severe, and the GDPR applying to any company collecting personal data within the EU, it's more vital than ever to pay close attention to app security.

Solutions

Awareness is a company's best defence against risks from known vulnerabilities. OWASP recommends that app developers and users continuously monitor author support and vulnerability updates of any third-party app components. Should a component cease being supported and updated by its author, users should either seek an alternative or employ virtual patching until a more properly secured solution can be found.

Becoming aware of any vulnerability in components remains a major problem, and is fuelling growth in software composition analysis (SCA) firms. One example is BlackDuck, now part of Synopsis, which helps companies secure and manage open source software.

As always, any application should be streamlined and should make use of as few components and files as possible. The more components in use by an application, the greater the likelihood of unpatched vulnerabilities. Any unnecessary features should be removed, along with any dependencies or references that may still carry a security flaw. Only components from trusted sources should ever be used, with secure links and signed packages to ensure that no unauthorised party has modified the component.

Setting out a clearly-defined patch management process will help to keep app developers informed and components secure. A company should define its procedures according to the security needs of the data handled by the app. The policy should account for keeping components up-to-date, but also set out procedures for when a vulnerability is discovered, or the code can no longer be patched. This may include virtual patching, or taking the app offline until the vulnerability can be fixed.

Automated tools can help, thanks to the availability of extensive vulnerability databases. Retire.js can scan applications for vulnerable JavaScript libraries, and OWASP has created its own utility, DependencyCheck, for Java and .NET dependencies.

A web application firewall (WAF) can also be employed since defence in depth is always a good principle. But WAF is no silver bullet, and researchers have repeatedly demonstrated they can frequently be bypassed by competent attackers. In December 2017, the security researcher known as ‘theMiddle’ published a paper titled, Web Application Firewall (WAF) Evasion Techniques. He concludes, “When you write a new SecRule on your ModSecurity or something like, keep in mind that probably there’re many ways to elude your filter / regular expression. So, write it thinking of ‘how can I evade this rule?’.”

Continuous monitoring for vulnerabilities is the best solution. High-Tech Bridge's ImmuniWeb® Discovery will help identifying any shadow or legacy applications, including unprotected cloud storage such as Amazon S3 buckets, web -based APIs and microservices, domains and SSL certificates. Once you have a complete visibility of your external applications and related components, ImmuniWeb® SCA will x-ray your applications for open source software that contains publicly-known vulnerabilities or that is outdated and possesses a threat to your organization.

Awareness is a company's best defence against risks from known vulnerabilities. ImmuniWeb® Discovery will help identifying any shadow or legacy applications, including unprotected cloud storage, web-based APIs and microservices, domains and SSL certificates.

Application Security Series Latest news and insights on AI and Machine Learning for application security testing, web, mobile and IoT security vulnerabilities, and application penetration testing.