This year, Snyk and Cloud Foundry are working together to provide monthly posts focused on helping you stay more secure. This is the third installment. Read the first and second posts as well.
This and the following few posts will comprise a short series on some of the most common types of vulnerabilities for two of the main ecosystems we track in our vulnerability database, namely Maven and npm. The Snyk Vulnerability database consists of vulnerabilities from over 1,000,000 open source packages we track that use Composer, Go, Maven, npm, NuGet, pip and Rubygems.
In 2017, the number of vulnerabilities published across our tracked ecosystems reached an all-time high, increasing by 83 percent from 2016. We can see what vulnerability types were the most common offenders in the two main ecosystems, which we’ll talk about here.
In our April and May posts, we’ll dig deeper into some of these vulnerabilities to see how they can be exploited.
JavaScript (npm)
1. Directory Traversal – Example: the st package.
The most common vulnerability in the npm ecosystem is Directory traversal. This is a vulnerability that typically occurs when a relative directory path is provided but not validated. Without validation, the relative directory passed in could reference a parent directory, gaining access to sensitive data. For example, one approach that is frequently used to execute an exploit is by using html entities, in which the ‘.’ is represented with ‘%2E’. In such cases, a request for the following url /%2E%2E/%2E%2E/%2E%2E/etc/password would result in /etc/passwd being leaked.
2. Resources Downloaded over Insecure Protocol – Example: Chromedriver.
This vulnerability allows attackers to perform a Man in the Middle (MitM) attack. When resources are downloaded over an insecure protocol, it is possible for an attacker to intercept this connection and alter the packages received.
3. Cross-Site Scripting (XSS) – Example: the handlebars package.
XSS attacks occur when an attacker tricks a user’s browser into executing malicious JavaScript code in the victim’s own environment. Such scripts can steal the user’s session cookies for the domain, retrieve typed password or credit cards, scrape or modify its content, and perform or modify actions on the user’s behalf, actions which would otherwise be typically blocked by the browser’s Same Origin Policy. For more info, check out XSS Attacks, the Next Wave.
4. Malicious Packages – Example: the crossenv package.
Malicious packages typically use typosquatting to bait unknowing users to install them. These packages carry a similar name to an original package, offer all the functionality of their original, but also include a code snippet that sends all your environment variables to a remote server controlled by malicious operators when your code is running.
5. Regular Expression Denial of Service (ReDoS) – Example: the moment package.
A ReDoS is a type of Denial of Service attack, caused by exploiting the non-linear nature of Regular Expressions which can ultimately end up making it easy for attackers to take your site down. One of the key advantages of Node.js is its scalability due the ability to process multiple requests with an event loop under a single thread. The downside is, if you are able to cause the event loop to get stuck on a single task (like trying to match a regular expression) other legitimate requests will not get served.
6. Arbitrary Code Injection – Example: the ejs package.
Code Injection is subtly different to code execution. Code injection occurs when an attacker exploits an already running application by inserting malicious code into the application which changes the path of execution. An attacker might craft a malicious payload to inject arbitrary commands, and in the worst case invoke a server side remote command execution.
Maven
1. Denial of Service (DoS) – Example: the jackson data processor.
A Denial of Service is a vulnerability that saturates the resources of the back end servers, that will then affect other user requests. This is often through CPU consumption but can also be filling server disks, memory or other resources.
2. Arbitrary Code Execution – Example: the Apache Struts library.
Arbitrary Code Execution is the running of malicious code sent to a vulnerable server. Often this code will call commands on the remote machine. It is often a result of another vulnerability, for example, a deserialization vulnerability, as in the struts case.
3. Cross-Site Scripting (XSS) – Example: Jenkins CI Server Plugin.
See the XSS description in the npm section above.
4. XXE Injection – Example: Apache Batic graphics package.
XXE is an XML External Entity vulnerability, an attack that can cause problems to a weakly configured XML parser when XML input is received that contains references to external entities. This could lead to sensitive file exposures and other vulnerabilities. For more information, see an example vulnerability in Nokogiri.
5. Access Restriction Bypass – Example: Apache tomcat app server.
This vulnerability is exactly what it says on the tin. When it’s possible to access resources without going through the required security checks, an attacker has bypassed the restrictions or constraints. This gives attackers much more control over resources to which they shouldn’t have access.
6. Deserialization – Example: the Jackson data processor.
This vulnerability is more of a problem to Java as it relies on Serialization heavily. The process of serializing and deserializing objects into a sequence of bytes is so that the stream can then be persisted to a disk or database or sent over the network. The vulnerability exists in the deserialization process. When deserializing untrusted data without verifying its validity, the data can provide an attacker access to the state or flow of execution.
There are several vulnerabilities that stand out as being particularly common, no matter the ecosystem. XSS vulnerabilities, for example, are actually among the five most popular vulnerability types for all ecosystems we monitor, and the most common vulnerability found in Pip packages and Rubygems as well as a top occurring issue in Serverless applications.
In the next two blog posts, we’ll look at some of these vulnerabilities in more depth and examine some of the examples of their exploitation to show exactly how dangerous they can be.
