Contrast Assess uncovers Spring-Kafka deserialization zero day

Earlier in August, a Contrast Security customer reported what they initially thought was a false positive: a deserialization vulnerability in Spring-Kafka. 

Spring, developed by VMware and Pivotal Software, is an open-source framework for building enterprise Java applications, while the Spring for Apache Kafka (Spring-Kafka) project applies core Spring concepts to the development of Kafka-based messaging solutions.

The reason why the customer thought it was a false positive was that it was found within the Spring framework itself, rather than in the customer’s own code, and because Spring appeared to add deserialization protection.

But it turned out that the vulnerability was no false positive; it was, in fact, a zero-day deserialization vulnerability in Spring-Kafka. 

Contrast Security was able to detect the vulnerability because in April 2023, the company added support for Spring-Kafka to its Assess runtime security solution. Contrast Assess — which continuously detects and prioritizes vulnerabilities and guides users through risk elimination — confirmed that it was, in fact, a true positive. VMware’s Security team confirmed the zero day and, on Aug. 23, pushed out a fix. The Common Vulnerability and Exposure (CVE) number CVE-2023-34040 has been assigned. 

What is insecure deserialization? 

Insecure deserialization, which in 2017 was tucked into the broader Open Worldwide Application Security Project (OWASP) Top 10 category of Software and Data Integrity Failures, occurs when a vulnerability allows untrusted or unknown data to be passed, enabling a denial-of-service (DoS) attack, code execution, authentication bypass or other types of abuse to an application’s logic.

The vulnerability trace ended at the following method in ListenerUtils.byteArrayToDeserializationException(): 

Note the use of resolveClass(): It was added to Java in JEP-290, which was a mechanism designed “to narrow the classes that can be deserialized from any class available to an application down to a context-appropriate set of classes” and allows the caller to check that the class being deserialized is what was expected. 

Significantly flawed deserialization check

But there are a couple of significant problems with this check:

1. Only the top-level class is being checked. ( resolveClass() ) would be called again for any nested objects, but only during the first call is a check made.
2. The check is made against the name of the class as a string. In this case, that would be:

org.springframework.kafka.support.serializer.DeserializationException

But what if the attacker generated an object that seemed to match the root class name, but which also contained a dangerous payload? Details of how this can be achieved are available here on Github. 

Once done, Serialized DeserializationExceptions can be added as a header to messages added to the Kafka queue and then read by the consumer application — i.e., the process that removes data from a shared data structure. 

By default, this is not read by the consumer application.

To enable this feature, either or both of these need to be configured:

checkDeserExWhenKeyNull

checkDeserExWhenValueNull

If either of these are enabled, the consumer application is vulnerable.

Note: The above contains no customer data. The finding is from the proof of concept (POC) below.

The POC

The POC contains two separate Java applications: 

1. A producer application that generates the message containing the serialized payload as a header, and
2. A consumer application that deserializes that payload.

Two payloads are available: an example of a remote code execution (RCE) gadget and a DoS payload. The DoS payload does not require any special gadget classes to exist on the consumer’s class path. 

Also, when the attack is executed, the consumer application fails to complete the read operation, leaving the message on the Kafka Queue. When the consumer (or another consumer in the same cluster) is restarted, it tries to read the message, and it again gets DoSed. The only way to remediate this is to either manually intervene and remove the message from the queue or wait until the retention period has ended and the message is auto-deleted from the queue, potentially leading to data loss as other messages sent just after the DoS message may also fall under the retention period.

Remediation

VMware has issued a fix for CVE-2023-34040, Private Header Type for DeserializationExceptions. 

More background on Contrast Assess

Two customers reached out to Contrast about this zero day after Contrast Assess flagged it. Both companies had the vulnerable configuration enabled. There might be yet more customers affected, but they haven’t flagged it to Contrast as a potential false positive.

Assess offers continuous, real-time security assessments throughout the application life cycle, ensuring that vulnerabilities are identified and addressed as soon as they’re introduced. The Contrast platform offers pointed, code-level remediation guidance to those who need to  understand and to fix vulnerabilities. The technology uses Contrast’s innovative Security Trace format, which pinpoints exactly where a vulnerability appears in the code and how it works. This enables developers to easily fix vulnerabilities without the need of security expertise.

By analyzing application code and data flows in real time, Contrast Assess can deliver highly accurate vulnerability detection with minimal false positives.

Find and fix real-time vulnerabilities with Contrast Assess. Get in touch to book a demo or get our free trial today.