Java Serialization Objects (JSO): An Exploitation Guide

Although both the offensive and defensive exploit developer communities have leveraged serialized objects for some time, many IT and IT security practitioners may not be familiar with how serialized objects are used by developers and abused by attackers. In this section, we will take a moment to explore the pros and cons of serialization and how it’s used—and abused—in modern networked applications.

What Are JSOs?

JSOs allow Java services to communicate with one another without rigidly defined structures. They provide a flexible way of exchanging data between Java services, often using files or network connections. The sender includes the structure and data types alongside the data (therefore serializing the object), while the receiver converts the stream back to an object through a process called deserialization. JSOs retain type information alongside the data and are used to transport complex Java objects around without worrying too much about what’s in them.

For example, one component of a Java application might build a “Customer” object that includes elements such as a “firstname” string, a “lastname” string, an integer amount of “money_to_spend,” and perhaps even a StreetAddress-type object that includes a few integers and strings. If components can just toss these “Customer” objects around to each other, the interfaces don’t need to know or care about what’s actually in a “Customer.” Instead, they’ll just serialize and deserialize these objects without regard to their contents, trusting that the sender and receiver do the right thing.

Abusing JSOs

Unfortunately, while the deserialization process might convert inbound object blobs to something as benign as a few type-defined strings and integers, it can just as easily produce a malicious function that launches an attacker-controlled process if the code designers don’t go out of their way to check the serialized object before acting on it. As it turns out, many receivers can't proactively limit which objects will be accepted before they’re deserialized and executed. This means attackers with the ability to build and send their own custom JSOs to a waiting deserializing interface can often gain unauthenticated remote code execution (RCE) on the receiver. Exacerbating this problem is the fact that serialized object handling is often so baked into products that modifying the way the internal components communicate is non-trivial. This makes patching serialization bugs both difficult and costly, since programmers have to pay back tech debt accrued by failing to consider object types and contents when first designing the product interfaces.

To mitigate this threat vector, vendors often opt to implement targeted blacklists that prevent the use of specific libraries leveraged to gain RCE instead of undertaking the more comprehensive patching task of redesigning the interface with malicious inputs in mind. In other words, when developers blacklist a library, the vulnerable JSO communication is left intact, but the library the exploit uses to gain RCE is blocked.

Once attackers identify another library with similar functionality, they can quickly and trivially target the new library.

To speed up retooling, tools like Chris Frohoff’s ysoserial can build a JSO using any number of libraries and wrapping a payload within one of several dozen JSOs. These tools greatly simplify risk demonstration and JSO-related vulnerability testing; their use also means that narrow, library-based blacklisting mitigation techniques are ineffective against attackers with access to public exploits and popular tooling.

Increased Prevalence of JSO-Related Vulnerabilities

Java deserialization attacks aren't new, but attackers have increasingly discovered how easy it is to develop these exploits . As Mark Reinhold , chief architect of the Java Platform Group at Oracle, recently said, "We like to call serialization the gift that keeps on giving. Right? And the type of gift it keeps on giving are security vulnerabilities."

CWE-502 is the MITRE Common Weakness Enumeration identifier that tracks vulnerabilities with deserialization of untrusted data (in Java or any other object-oriented language). Over the past five years, we've seen a sharp increase in deserialization-based CVEs , including those with CVSS scores higher than 7.0:

Many of these CVEs are found in enterprise products such as Oracle WebLogic, IBM WebSphere, Cisco Secure Access Control System (ACS), HPE Intelligent Management Center (IMC), and VMware's vSphere Integrated Containers. Given the presence of a single JSO-related CVE in a particular product, researchers and defenders can often expect that there will be more to come.

An attacker can gain unauthenticated RCE on a number of these products using a variety of public exploits within the Metasploit Framework, including the following:

Date

Metasploit Module

Status

Feb. 4, 2019

shiro_rememberme_v124_deserialize

In Review

Dec. 16, 2018

weblogic_deserialize_unicastref

In Review

Dec. 16, 2018

weblogic_deserialize_marshalledobject

In Review

Dec. 15, 2018

weblogic_deserialize_rawobject

In Review

Dec. 3, 2018

hp_imc_java_deserialize

Landed

Aug. 8, 2018

weblogic_deserialize

Landed

March 14, 2017

ibm_websphere_java_deserialize

Landed

Oct. 14, 2016

opennms_java_serialize

Landed

Internet Exposure

Given a recent increase in reported vulnerabilities involving Oracle's T3 protocol, we used Rapid7's Project Sonar framework to identify WebLogic servers exposed to the public internet in January 2019.

WebLogic itself communicates using a variety of protocols beyond T3, but it is different than many other products and services that speak only one protocol on a given port. For example, the default configuration of modern WebLogic instances provides a default endpoint, 7001/TCP, that speaks several different protocols, including T3, HTTP, SNMP, and LDAP.

To understand more about how WebLogic is exposed on the public internet, we first examined data collected as part of Sonar’sHTTP andHTTPS studies, which run approximately weekly against several dozen ports. When we examined over 120 million HTTP response bodies for a string of text known to be elicited by most WebLogic instances as part of its HTTP support, we saw 18,693 unique IPv4 addresses across 67 different TCP ports that appeared as WebLogic. Not surprisingly, the most common ports where WebLogic was found were 7001 (default) and 80 (HTTP):

With the knowledge of which TCP ports on the public internet might be powered by WebLogic—443, 80, 7001, 8001, and 8002—we then created a way to determine whether a given endpoint speaks the T3 protocol and used this method to more accurately understand the exposure of T3 on the five ports in question.

Our technique sends a 23-byte T3 negotiation message:

t3 9.2.0.0\nAS:2048\nHL:19\n\n

The string ‘t3’ starts the T3 protocol. ‘9.2.0.0’ is the advertised WebLogic version of our client and is used by the server to determine compatibility. The ‘AS’ and ‘HL’ parameters control the JVM message header size and approximate table size, respectively, with values set according to observed defaults.

Experimentation confirmed that T3 endpoints respond with a similar message that describes the result of the T3 negotiation, falling into two groups:

1. Confirmed T3 endpoints where T3 was successfully negotiated. From this, we can identify the version of WebLogic advertised by the server.
2. Confirmed T3 endpoints where T3 was unsuccessfully negotiated because of connection filters or similar restrictions, or some type of misconfiguration such as licensing issues and WebLogic version incompatibility, among other likely scenarios.

Examining the responses from over 87 million unique IPv4 endpoints that claimed to have one of these previously identified common WebLogic ports—80, 443, 7001, 8001, and 8002—we identified 11,831 systems that are confirmed to be running WebLogic. This is 35% lower than our previous HTTP-based estimate. There are several possible reasons for this discrepancy, such as general internet-scale scanning fluctuation, or the possibility that these WebLogic instances have been explicitly configured to only speak HTTP and not T3. Further proof of this is that 1,183 systems responded negatively to our T3 probe, likely indicating that our connection to T3 was restricted for some reason.

On port 7001/TCP, one of several default ports used by WebLogic, we observed 4,577 T3-speaking IPv4 addresses. Beyond the natural fluctuation that we expected from scanning at scale like this, the lower HTTP-based estimate of 3,439 possibly indicates that there are WebLogic instances on 7001/TCP that speak T3 but not HTTP.

Port 8001/TCP is a common alternative port used by WebLogic installations in cases where the default of 7001/TCP is unavailable or a second instance is needed. We observed 1,157 T3-speaking hosts on 8001/TCP. Port 8002, an even less common alternative port for WebLogic, showed just over 300 WebLogic systems.

On the default HTTP and HTTPS ports (80 and 443), we found 5,672 and 1,133 IPv4 endpoints, respectively, that were confirmed to speak the T3 protocol.

Inspecting the WebLogic versions advertised by confirmed T3 endpoints that we successfully negotiated showed a wide variety of deployed versions, from 12.2.1.3 (the most current version of WebLogic as of early 2019) to 7.0.1.0 (released in 2002):

As part of all Sonar endpoint studies, we also noted at the time of observation any additional relevant metadata about the IP, including the organization that might “own” the IP and location details such as country and city. Examining this metadata from confirmed T3 results revealed a couple of takeaways:

• More than 25% of the IPs exposing T3 are owned by Oracle, the company that provides WebLogic, and much of the rest are owned by various cloud providers.
• More than 36% of the IPs exposing T3 are owned by organizations located in the United States, with another 32% of IPs located in China.

Organization

Count

Oracle/Oracle Cloud

2,982

China Telecom

1,677

China Unicom

867

Alibaba/Cloud

340

Amazon/AWS

264

YHSRV

252

China Mobile

204

SumTotal Systems

143

Korea Telecom

136

CenturyLink

123

Tencent

89

Microsoft/Azure

81

LG

79

OVH/SAS

69

Tata

55

Respina Networks

54

HiNet

42

China Education and Research Network Center

41

Airtel

38

Stanford University

36

Country

Count

United States

4279

China

3875

Iran

511

South Korea

307

Germany

241

India

236

United Kingdom

138

Canada

120

France

118

Brazil

115

Mexico

96

Vietnam

83

Taiwan

80

Japan

77

Pakistan

74

Singapore

74

Saudi Arabia

72

Thailand

71

Costa Rica

69

Hong Kong SAR China

67

Attacking JSO-Based Services

Exploitation can be as simple as using any one of a number of Metasploit modules ( #11136 , #11134 , #11131 , and #10436 ) against a WebLogic server that is remotely discoverable. It can also be a manual process that involves navigating a web service while intercepting traffic and then targeting the vulnerable service with tools like Burp Suite or ysoserial .

For example, an attacker who identifies a WebLogic server would be able to trivially gain unauthenticated RCE via Metasploit:

A more subtle attack would involve navigating a website or using a Java application while monitoring network traffic for the telltale signs of JSO-based interactions. A simple search for traffic containing T3 headers (or the 0xACED magic bytes) can indicate the existence of services using JSOs to communicate:

Finally, an aggressive attacker might use any number of public tools to actively scan services for JSO-based user inputs. For example, the professional version of PortSwigger’s Burp Suite supports a Java Deserialization Scanner extension that can actively identify and exploit JSO vulnerabilities. Interestingly, the extension uses a modification of Wouter Coekaerts’ SerialDOS technique to perform a library-agnostic vulnerability check of a JSO-based service, identifying the inherent vulnerability even if libraries have been blacklisted.

[1]Of course, any random-ish set of binary data may also have the magic 0xACED bytes in there somewhere, so this is more of a useful (but noisy) technique for application testers, and not so useful for network defenders looking to filter JSOs. More context than a mere 2 bytes is needed for a robust network filter.