On the plus side, only instances with non-standard not recommended configurations are vulnerable. On the downside, those configurations aren’t easy to track down, and it’s easy as pie to exploit.
Researchers have shared details about a now-patched, high-severity security bug in the Apache Cassandra open-source NoSQL distributed database that’s easy to exploit and, if left unpatched, could enable attackers to gain remote code execution (RCE).
The bug, which involves how Cassandra creates user-defined-functions (UDFs) to perform custom processing of data, is tracked as CVE-2021-44521, with a high-severity rating of 8.4.
The vulnerability was discovered by JFrog’s Security Research team. In a Tuesday writeup, JFrog security researcher Omer Kaspi said that on the upside, the only Cassandra systems that are vulnerable to the flaw are those with a particular, non-standard and, specifically, not recommended configuration.
On the downside, it’s a snap to exploit, JFrog has already created a proof-of-concept (PoC) exploit. Another downside: This database is everywhere.
“This Apache security vulnerability is easy to exploit and has the potential to wreak havoc on systems, but luckily only manifests in non-default configurations of Cassandra,” Kaspi said in his writeup.
What, and Where, Exactly, is Cassandra?
Cassandra is a highly scalable, widely used distributed database known for being efficient and highly available, given that such databases don’t have a single point of failure: a big plus for businesses that can’t lose data or endure system downtime. It’s also known for being able to handle massive volumes of data across multiple servers, with fast writes of huge amounts of data that don’t bog down its read efficiency.
“Cassandra is a highly scalable, distributed NoSQL database that is extremely popular due to the benefits of its distributed nature,” Kaspi said.
As such, it’s used by enterprises with big, big names, Kaspi noted, including Netflix, Twitter, Urban Airship, Constant Contact, Reddit, Cisco, OpenX, Digg, CloudKick, Ooyala and more. The researcher added that Cassandra is also extremely popular in DevOps and cloud-native development circles, “as can be seen by its support in CNCF [cloud native Computing Foundation] projects (such as Jaeger).”
(Jaeger is an open-source, end-to-end distributed tracing platform designed to monitor and troubleshoot transactions in complex distributed systems.)
“Some companies even provide cloud-based turnkey solutions based on Cassandra, such as DataStax (a serverless, multi-cloud DBaaS),” Kaspi pointed out.
Digging Out the Risk Will Be a Royal Pain
Given Cassandra’s popularity, the fact that the flaw requires non-default user configuration settings to exploit might not be all that comforting, security experts told Threatpost.
John Bambenek, principal threat hunter at the digital IT and security operations company Netenrich, told Threatpost on Wednesday that he suspects that the non-default settings are “common in many applications around the world.”
The situation isn’t looking as bad as Log4j, but it could still potentially be widespread, and it’s going to be a chore to dig out vulnerable installations, Bambenek said via email. “Unfortunately, there is no way to know exactly how many installations are vulnerable, and this is likely the kind of vulnerability that will be missed by automated vulnerability scanners,” he said. “Enterprises will have to go into the configuration files of every Cassandra instance to determine what their risk is.”
Casey Bisson, head of product and developer relations at code-security solutions provider BluBracket, told Threatpost that the issue could have “a broad impact with very serious consequences,” as in, “Threat actors may be able to read or manipulate sensitive data in vulnerable configurations.”
Bisson suggested another potential hazard: Were a threat actor to gain write access to a database instance’s configuration, they could enable the vulnerability without the operators being aware.
The Heart of the Problem: JavaScript’s Use of the Nashorn Engine
When it comes to creating UDFs for custom data processing, Cassandra can write them by default in Java and JavaScript. When they’re written in JavaScript, Cassandra uses the Nashorn engine in the Java Runtime Environment (JRE): a JavaScript engine that runs on top of the Java Virtual Machine (JVM).
Therein lies the problem: “Nashorn is not guaranteed to be secure when accepting untrusted code. Therefore, any service that allows such behavior must always wrap the Nashorn execution in a sandbox,” according to JFrog’s writeup. “For example, running the following Nashorn JavaScript code allows execution of an arbitrary shell command – java.lang.Runtime.getRuntime().exec(“touch hacked”).
Some projects, such as NashornEscape, implement a sandbox to secure Nashorn code execution, Kaspi explained.
“The Nashorn engine gives access to arbitrary Java classes by using Java.type. For example: var System = Java.type(“java.lang.System”) will allow us to access the java.lang.System package by using the System variable,” he continued.
Users with sufficient permissions can create arbitrary functions by using the create function query.
While researching the Cassandra UDF sandbox implementation, researchers realized that a mix of specific (non-default) configuration options could allow them to abuse the Nashorn engine, escape the sandbox and achieve RCE: the vulnerability reported as CVE-2021-44521.
Mitigation and Fix
JFrog highly recommends that all Apache Cassandra users upgrade to one of the following versions, which resolve the bug:
- 3.0.x users should upgrade to 3.0.26
- 3.11.x users should upgrade to 3.11.12
- 4.0.x users should upgrade to 4.0.2
For those users who can’t update their instances, JFrog recommends these mitigations:
- If UDFs are not actively used, they can be completely disabled by setting enable_user_defined_functions to false (which is the default value)
- If UDFs are needed, set enable_user_defined_functions_threads to true (which is the default value)
- Remove the permissions of creating, altering and executing functions for untrusted users by removing the following permissions: ALL FUNCTIONS, ALL FUNCTIONS IN KEYSPACE and FUNCTION for CREATE, ALTER and EXECUTE queries.
Join Threatpost on Wed. Feb 23 at 2 PM ET for a LIVE roundtable discussion “The Secret to Keeping Secrets,” sponsored by Keeper Security, focused on how to locate and lock down your organization’s most sensitive data. Zane Bond with Keeper Security will join Threatpost’s Becky Bracken to offer concrete steps to protect your organization’s critical information in the cloud, in transit and in storage. REGISTER NOW and please Tweet us your questions ahead of time @Threatpost so they can be included in the discussion.
