The 2020 State of the Software Supply Chain Report is available!

Study Shows High-Performance Dev Teams Fix OSS Vulns 26x Faster | Press Release

blog-logo Sonatype Blog

From Prototype Pollution to full-on remote code execution, how can adversaries exploit npm modules?

August 19, 2020 By Akshay 'Ax' Sharma

The NodeJS component express-fileupload - touting 7 million downloads from the npm registry -  now has a critical Prototype Pollution vulnerability.

At a minimum, this vulnerability lets attackers toy with your NodeJS applications and cause a series of HTTP 500 errors (i.e., Denial of Service (DoS)). More advanced exploits target the template-altering capabilities of the flaw, enabling hackers to execute remote code on a vulnerable machine.

The NodeJS component “express-fileupload” is a rather popular choice among developers because it provides a variety of file upload options, and can be easily integrated into your application. If you are relying on a vulnerable “express-fileupload” version for file upload functionality, you should be aware of the security risks it can cause.

The vulnerability (CVE-2020-7699) was discovered by security researcher Posix at the end of July, where he provided more details in this blog post.   

Why Prototype Pollution vulnerabilities matter?

Prototype Pollution vulnerabilities are interesting due to their versatility for the attacker. Imagine being able to alter every single object and property of a JavaScript application because of nothing but an inherent “design flaw” in the language. 

We previously explained what Prototype Pollution is, and how it impacts the popular “lodash” component in a previous Nexus Intelligence Insight. Recall from that post that JavaScript is a prototyping language, and the ability to modify the basic template that all objects and properties build-upon, is an intended feature of the language. 

Previously, Prototype Pollution vulnerabilities in JavaScript code used in a client-side context have posed security issues. But, their exploitation has typically ended in the user’s browser crashing, or an app misbehaving on the client-side, meaning the impact was contained.

But ever since the advent of “serverless” architecture and NodeJS-powered apps, the same language (JS), now powers thousands of backend apps. This presents a far higher security risk to everyone, if organizations do not stay up to date with the latest NodeJS vulnerabilities and patch as required.

Garrett Calpouzos, Security Research Team Lead at Sonatype, says, “The severity of Prototype Pollution vulnerabilities is dependent on where this component is used. If used as part of front-end JavaScript, these vulnerabilities essentially result in Cross-Site Scripting (XSS), whereas if you use the component as part of a backend NodeJS application, this vulnerability is more equivalent to Remote Code Execution (RCE).”

With Prototype Pollution vulnerabilities like these, all it takes is a single HTTP request for an attacker to get shell access and remotely execute commands on a server running “express-fileupload” along with other open-source libraries (e.g., EJS).

 


A reverse shell PoC exploiting CVE-2020-7699
Source: Posix blog

How does Sonatype get this right?

As soon as the Sonatype Security Research team was made aware of the vulnerability impacting this heavily-downloaded component, we expedited our deep dive research.  During the research, we realized that the official NVD advisory was incorrect because even though public discourse on forums stated that version 1.1.8 is fixed, it was only partially fixed.

In the fix made to 1.1.8, while the uploaded JSON values containing ‘__proto__’ are deemed invalid and filtered, the logic doesn’t yet take into account another variation of the exploit. 


Partial fix applied by “express-fileupload” for the vulnerability in 1.1.8
(via GitHub)

As pointed out by a user securityMB, an attacker can simply use “constructor.prototype” as opposed to the “__proto__” mutator to bypass this check, and still pollute the prototype of objects.

Noticing this, the highly responsive project developers were quick to deprecate version 1.1.8 from npm downloads and issue an improved fix, which went into version 1.1.9:

pasted image 0-Aug-21-2020-07-23-51-30-PM

Improved fix that went into version 1.1.9 of “express-fileupload” (via GitHub)


Furthermore, to extend the protections offered by this fix to arrays, and preventing modification of object methods and properties other than “__proto__” and “constructor,” the project has yet again made some enhancements in versions 1.1.10 and above. This is all accounted for in Sonatype’s data.

unnamed-Aug-21-2020-07-25-11-65-PM

Further enhancement which extends protections to arrays and other object methods
Source: GitHub

The takeaway

The responsiveness demonstrated by the “express-fileupload” team in patching the flaw is commendable, as is the responsible disclosure on the researcher’s (Posix) part.

But, this vulnerable component that has more than 7 million downloads could easily be lurking in your software supply chain.

Without complete insights, as provided by Sonatype, some developers may continue to use version 1.1.8 under the false impression it is patched, which, as we saw, isn’t the case. Sonatype recommends upgrading to express-fileupload version 1.1.10 or above, as present in npm downloads, which contains the fix for this vulnerability.

With thousands of vulnerabilities reported every year in open source components, it is virtually impossible to manually keep track of each exploit and how it specifically applies to your app dev environment. DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of malicious intent. Sonatype Nexus customers were notified of CVE-2020-7699 within hours of the discovery, and their development teams automatically received instructions on how to remediate the risk.

If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to find out quickly.

Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.

Tags: vulnerabilities, npm, featured, Nexus Intelligence Insights

Written by Akshay 'Ax' Sharma

Endorsed an Exceptional Talent (‘a recognized leader’) by the British Government, Akshay aka Ax is a Security Researcher at Sonatype and Engineer who holds passion for perpetual learning. In his spare time, he loves exploiting vulnerabilities ethically and educating a wide range of audiences.