Java Deserialization Vulnerability Found to be Widespread Across SaaS Vendor SDKs

Recently, we’ve identified a number of our customers who are susceptible to a deserialization-based remote control execution (RCE) vulnerability. In the majority of cases, a subset of the gadget chain (circumstances to exploit the deserialization vulnerability) is being triggered by customer application’s dependency on a one or more 3rd party Software-as-a-Service SDKs, which in turn depends on a vulnerable version of jackson-databind. In other words, this vulnerability is particularly tricky to catch, because it is contextual: The exposure comes from how various libraries interact with each other.

The vulnerability impacts numerous SaaS SDKs. We are currently in the process of disclosure. As of publishing, we can share that the following SDKs have been impacted and we applaud these organizations for their rapid response:

• SendGrid (upgrade to v4.2.1)
• GoodData (upgrade to v2.25.1-SNAPSHOT)
• .. the rest will be announced individually, as vendors provide updates

ShiftLeft determined these gadget chains using:

• the application’s DNA (e.g. application’s attack surface and data flow analysis) derived from our Semantic-Property-Graph,
• software composition analysis (your logic, it’s open source dependencies, 3rd party SDK & it’s transitive dependencies and open source framework. Note that this is entirely derived from connecting the semantic graph of the application with it’s direct + transitive dependencies and 3rd party SDK dependencies)
• attack payload detection and operational state characteristics using our runtime agent.

To recover for such a vulnerability, a series of steps should be applied with precision and care:

• conduct impact analysis to identify surface exposure (list of services using vendor SDK)
• continuous communication with vendor to identify a remediation and upgrade plan
• deploying upgrade to all services and test impact of upgrade
• determine characteristics of application that trigger the exploit along with this component’s vulnerability

All of these steps mentioned above would need to be orchestrated in sequence, which is time consuming. This leaves security teams with a terrible choice: suspend/limit service or accept the risk of exploit from a known vulnerability.

Let us illustrate the expansive scope of this exploit using one such library.

• Jackson is a popular library for parsing JSON documents in Java.
• Jackson-Databind is a module of the Jackson library that allows automatic transformation from JSON to Java objects and vice versa.

In June 2017, an unsafe deserialization vulnerability was discovered in the Jackson-Databind module (CVE-2017–7525) and was patched by creating a blacklist that doesn’t accept certain dangerous Java classes.

At the beginning of 2018, jackson-databind was reported to contain another remote code execution (RCE) vulnerability (CVE-2017–17485) that affects versions 2.9.3 and earlier, 2.7.9.1 and earlier, and 2.8.10 and earlier. This vulnerability is caused by jackson-dababind’s incomplete blacklist.

An application that uses jackson-databind will become vulnerable when the enableDefaultTyping method is called via the ObjectMapper object within the application. An attacker can thus compromise the application by sending maliciously crafted JSON input to gain direct control over a server. Currently, a proof of concept (POC) exploit for this vulnerability has been publicly available. All users who are affected by this vulnerability should upgrade to the latest versions as soon as possible to fix this issue.

Impact of Deserialization Vulnerability

Affected Versions

Jackson-databind version <= 2.9.3
Jackson-databind version <= 2.7.9.1
Jackson-databind version <= 2.8.10

Unaffected Versions

Jackson-databind version 2.9.3.1
Jackson-databind version 2.7.9.2
Jackson-databind version 2.8.11

Repair proposal

Upgrade to 2.9.5

<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.5</version>
</dependency>

Coming Soon , at v3.x , whitelisting-based serialization for these polymorph classes

Recommendations for your code base

– Disable the enableDefaultTyping() method;
– Filter incoming JSON data from the client or check the type.
– Implement ObjectInputFilter as described in JEP-290
– Check if JDK > v8u45

Gadgets

The classes that we can use to escalate a deserialization into RCE (remote code execution) are called gadgets. One or more gadgets working in sequence with each other is called a gadget chain

But there is a large number of java classes out there and it’s impossible to defend against all of them.

In combination with Jackson Databind, some of the classes in your application that lend to trigger this gadget chain are:

• JDK <= v8u45 (using Xalan XLST library included in JDK) https://bit.ly/2JF1FX3
• Spring Framework
  3.0.0 to 3.0.5
  2.5.0 to 2.5.6.SEC02 (Community releases)
  2.5.0 to 2.5.7.SR01 (Commercial customers)

In order for a class to be a valid gadget for a jackson deserialization attack these criteria needs to be fulfilled:

• A default constructor, i.e. a constructor without any arguments.
• A method that acts on the argument in a non-trivial way, the simplest is if you are able to provide a serialized java class with a function that gets called.

@cowtowncoder had written an excellent article explaining polymorphic typing — On Jackson CVEs: Don’t Panic — Here is what you need to know

Patch whack-a-mole — History of patches applied to protect against the vulnerability

The open source authors have released new versions to fix this vulnerability by expanding the blacklist and advising users to upgrade as soon as possible.

An hour passed, and the blacklist was updated to contain more dangerous classes.

In December 2017 CVE-2017–17485 was allocated for this exact same vulnerability because it was found that the blacklist didn’t contain dangerous classes from the Spring framework.

After a while another bypass on the blacklist is discovered, now being tracked as CVE-2017–15095.

This is probably not the last change being made on this blacklist because new dangerous classes and gadget chains (Several classes that when combined may lead to Remote Code Execution) are discovered from time to time by security researchers.

The new major version (3.x) of jackson-databind will address this issue via a new API layer that provides a way to achieve whitelisting-based serialization for these polymorph classes. Until then, Jackson-databind may have pre-zero day exposure to additional classes that aren’t yet known to be dangerous.

Case and point, protecting by patching is not a conducive strategy because attackers are regularly identifying newer exploitive classes that can be used to trigger a gadget chain.

Exploit Proof-of-Concept

conikeec/jackspoilt

Conditions to trigger gadget chain

• Dependency on Jackson 2.8.7 — https://github.com/conikeec/jackspoilt/blob/master/pom.xml#L87-L91
• Dependency on Xalan XSLT 2.7.2 — https://github.com/conikeec/jackspoilt/blob/master/pom.xml#L105-L109 [or] JDK <= v8u45 (using Xalan XLST library included in JDK) https://bit.ly/2JF1FX3
• Deserialization of Untrusted Data — https://github.com/conikeec/jackspoilt/blob/master/src/main/java/io/shiftleft/jackspoilt/App.java#L35-L46 , https://github.com/conikeec/jackspoilt/blob/master/src/main/java/io/shiftleft/jackspoilt/App.java#L35-L46
• Enable polymorphic handling in Jackson — https://github.com/conikeec/jackspoilt/blob/master/src/main/java/io/shiftleft/jackspoilt/App.java#L22

How ShiftLeft Can Help

ShiftLeft can help with the three core problems with this type of vulnerability: Context, Whack-a-Mole and Being at the mercy of your SDK providers.

Contextual Vulnerabilities: The contextual severity of this deserialization vulnerability dramatically increases, based on how your application interacts with/leverages other libraries. Managing CVEs across all your libraries is challenging on its own. Confirming the contextual usage of each CVE, versus all the components that make up your application/service, is extremely tedious and time-consuming.

Whack-a-Mole Patching: The whack-a-mole nature of constantly needing to patch is operationally inefficient and inherently insecure. As we have seen, new vulnerable classes can be added to the blacklist hourly. It is likely that more classes will be added before the whitelist approach can be update in 3.x. Hence, even with the latest update, there may still be pre-zero day classes that can be exploited.

Dependency on SDK Providers: Even if you’ve patched all of the Jackson-databind libraries in your custom code, you may still be vulnerably through the SDKs your service leverages. As you will see, as more vendors update their SDKs, there is a difference in speed at which each one patches. As a downstream consumer of the SDK, short of ripping-and-replacing, Security teams don’t have many options prior to the release of the patch from their vendor.

ShiftLeft solves all of these of these problems: First, and how we initially identified this issue, is that our Semantic Property Graph analyzes how the application works and extracts “Security DNA” from source code. As part of this process it understands how each component (your custom code, open source libraries and 3rd party SDKs) interact with each other. Hence, automatically identifying contextual vulnerabilities is right smack in our wheelhouse.

Second, we provide runtime protection for any vulnerability that the Semantic Property Graph identifies so you can avoid whack-a-mole all together. Of course, we advise that you ultimately update to the latest versions of any vulnerable SDKs in a timely manner. However, instantly patching isn’t always realistic, and, because both future updates to the jackson-databind blacklist are likely, and your SDK vendor may not update in a timely manner, you probably have exposure, even when you are able to patch instantly.

ShiftLeft’s runtime protection is extracted from your application’s security DNA, so it is customized and defined by exactly what your application is vulnerable. Hence, your application is protected from the universe of possible pre-zero-day-whack-a-mole blacklist/patch updates so you’re no longer dependent on your SDK vendor to update their services and you can update your custom code in accordance with your schedule, rather than in a panic.

Please see screenshots and videos below for how ShiftLeft protects your application from this contextual deserialization vulnerability.

Credits

What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability

On Jackson CVEs: Don’t Panic — Here is what you need to know by @cowtowncoder

AppSecCali 2015: Marshalling Pickles

Java-Deserialization-Cheat-Sheet

Blind-Java-Deserialization-Commons-Gadgets.html

---

Java Deserialization Vulnerability Found to be Widespread Across SaaS Vendor SDKs was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/java-deserialization-vulnerability-found-to-be-widespread-across-saas-vendor-sdks-8e7ec3dfc5fa?source=rss----86a4f941c7da---4