ReDoS vulnerabilities in npm spikes by 143% and XSS continues to grow

著者:

Liran Tal

2019年2月26日

0 分で読めます

Welcome to Snyk's annual State of Open Source Security report 2019.This report is split into several posts:

Or download our lovely handcrafted pdf report which contains all of this information and more in one place.

Download the 2019 State of Open Source Security Report

Regular expression denial of service

The Node.js runtime is known to have many strengths, but one of them, the single threaded Event Loop, can also be its weakest link if not used correctly. This happens more regularly than one might think.

Regular expression denial of service (ReDoS) attacks exploit the non-linear worst-case complexity vulnerabilities that some regex patterns can lead to. For a single-threaded runtime this could be devastating, and this is why Node.js is significantly affected by this type of vulnerability.

We found that there were a growing number of ReDoS vulnerabilities disclosed over the last three years, with a spike of 143% in 2018 alone.

wordpress-sync/Regular_expression_denial_of_service_ReDoS_disclosures_on_the_rise

XSS vulnerabilities

Cross-site Scripting (XSS) attacks have been an ever-increasing pain point for web applications and we see the trend in XSS vulnerabilities spiking in 2018 across all ecosystems that Snyk has been monitoring.

XSS vulnerabilities in open source libraries are still on the rise, despite being a top concern by OWASP for more than 15 years

Within these ecosystems, we’ve detected that the npm ecosystem has seen the most XSS vulnerabilities, disclosing 225 in total; followed by Maven Central Repository with 167; and PyPI with 163 total cross-site scripting vulnerabilities. In 2018, the PHP Packagist ecosystem disclosed the most with 56 XSS vulnerabilities, followed by npm with 54, and Maven Central with 29.

wordpress-sync/XSS_vulnerabilities_disclosed_by_year

Path Traversal

Path and directory traversal vulnerabilities fiercely stand out in the npm ecosystem with record numbers of 146 and 143 disclosures in 2017 and 2018, respectively. The other ecosystems are much further behind, which is a good thing!

One might presume that this may be attributed to the plethora of static and dynamic web servers built with Node.js for both production and development use, and therefore there are many more packages in which such vulnerabilities might also be found.

wordpress-sync/Path_traversal_vulnerabilities_most_commonly_seen_in_npm

SQL injection vulnerabilities

Another common attack vector that is consistently featured in the OWASP’s top 10 over the past decade is CWE-89, more commonly known as SQL Injection.

Looking across the last three years, we can see that each of the three main ecosystems we reviewed have peaks during different years. Maven libraries lead the number of SQL injection vulnerabilities disclosed in both 2016 and 2017, followed by PHP Packagist libraries, which hit a peak in 2018.

wordpress-sync/SQL_injection_disclosures_show_spikes_by_year_and_ecosystem

Sensitive information exposure

Looking at the Maven Central and PHP Packagist registries we found they had the most vulnerabilities related to information exposure, peaking in 2018 for both ecosystems.

Information exposures often happen unintentionally. They occur when a program or system discloses potentially sensitive information, such as environment variable names and values. Cases of information exposure may also occur “by design” such as when sensitive data is provided within URL parameters.

Several examples of information exposure vulnerabilities in the Maven Central registry are apache spark, jenkins core, keyclock-saml-core packages. Jenkins ssh-agent CI plugin, for example, leaked the SSH private key in the build logs for anyone with Read permissions to see.

The PyPI registry also has a good amount of vulnerabilities found in libraries, with examples of information exposure vulnerabilities. Packages such as django displayed a user password hash to admin users who only had View permissions. The package djangorestframework-api-key saved API keys in plain text.

wordpress-sync/Sensitive_Information_Exposure_vulnerabilities_affecting_the_Java_ecosystem_1

Cleartext transmission of sensitive information

Last but not least is another unique vulnerability worthy of mention in the npm ecosystem, CWE-319, also known as Cleartext Transmission of Sensitive Information, in which resources are accessed over insecure protocols. We were able to find 44 new reported vulnerabilities in packages from 2016, and this number further rises to a hefty total of 110 packages in 2017, a 250% increase.

"The state of an ecosystem's security and its public perception are often extremely different. The lack of typing in JavaScript has spread the idea that it is an unsafe language due to type manipulation, but in any case, the number of vulnerabilities discovered in npm modules over the last couple of years is still lower than those discovered on Maven central. At the same time, some vulnerabilities may be exacerbated because Node.js still mono-threaded. ReDoS (or other CPU-exhaustion DoS), which is much more common in the Node.js world, is an example of this. Hopefully, Worker Threads will soon enable Node.js, in order to reduce these risks. The security community in Node.js has been more and more active in the past years and we can continue to work hard so that the ecosystem become safer in the future."

Vladimir de Turckheim

Node.js Foundation, Node.js Security Working Group

Spotlight: Malicious packages

You may have heard about malicious packages in a variety of contexts, such as a malicious docker container or perhaps a malicious package in a public registry of one ecosystem or another. We have also discussed developers as a malware distribution vehicle in several other contexts such as the Induc malware that infected Delphi compilers and XCodeGhost that targeted iOS and OSx developers.

However, not all malicious packages are the same in nature. With regards to ecosystem registries we can broadly classify them into the following:

a typosquatting attack where a malicious package uses a very similar name of a more popular package
a compromised maintainer’s CI or registry account resulting in the publishing of a malicious version, or a malicious package residing in a project’s list of dependencies
a socially engineered inclusion of a malicious package (or a package that will be malicious after inclusion) into a project list of dependencies

In 2018 we saw occurrences of all of these malicious package types in the npm ecosystem, known for being one of the registries that suffers from malicious packages more than others. The package that recently made the news in December 2018 was event-stream. It relied on a malicious dependency that was delivered through a seemingly innocent attempt to make an open source contribution.

This hack affected a staggering 8 million downloads of the malicious package in only two months. Another example in 2018 is the ESLint- scope package in which the maintainer’s account was compromised. We also saw a total of 11 typosquatting attacks for malicious packages published in 2018 on the npm registry.

In 2018, a malicious package was downloaded a record 8 million times. It was one of 25 typosquatting attacks in npm and PyPI

In addition to the typical typosquatting attempts that we’ve seen in the past, we also saw more mature malicious attempts to attack the npm ecosystem than in previous years, such as the ESLint-scope attack. With much higher sophistication, the event-stream incident exposed a high level of expertise and targeted attacks than we’ve seen in previous malicious attempts in the ecosystem to date.

In contrast to the npm registry, the only other registries in which we identified malicious packages were RubyGems with just one malicious package in 2018, and Python with ten malicious packages in 2017 and thirteen in 2018.

Continue reading:

Capture the Flag を始める

バーチャル 101 ワークショップオンデマンドで、Capture the Flag の課題の解決方法をご覧ください。

今すぐ見る

開発者セキュリティプラットフォーム