Our payload will have the following format: We're able to bypass the serialization whitelist and execute our code! But how? Let's dig into it. To summarize, to achieve remote code execution, we need to do the following:ġ - Create a ysoserial CommonsBeanutils1 payload.ģ - Encapsulate the payload in a Java String object.Ĥ - Serialize the String object using the standard Java serialization functionality.ĥ - Base64 encode the serialized String object.Ħ - Send a request to /system/gateway invoking getDiffs() with the malicious parameters. One of them is getDiffs(), which is shown below: The. class contains a number of actions that are accessible by an unauthenticated remote attacker. In our case, we used this as a springboard to attack other functionality. An unauthenticated attacker can invoke the “project diff” functionality to obtain crucial information about a project. The first vulnerability in this chain is an information leak, but not used as such in our exploit. Vulnerability 1: Unauthenticated Access to Sensitive Resource Now let’s get to the exploit chain we used at Pwn2Own. If you’re interested in reading more about it, check out Java Unmarshaller Security or this Foxglove Security Blog Post. It is out of the scope of this blog to explain Java deserialization, how it happens, and how devastating it can be. Since these are all very simple types, the mechanism described here is an effective way to stop most Java deserialization attacks. It only allows the following object types to be deserialized: Before we dive into that, let's look at what a signer() request looks like:Īs it can be seen in the snippet above, the default allow list ( DEFAULT_WHITELIST) is very strict. Usually, performing client-server communications with serialized Java objects can lead to direct code execution, but in this case, it is not that simple. Its code resides in the .servlets.Gateway class. It communicates with clients using XML containing serialized Java objects. Only a few can be called by an unauthenticated user. This API endpoint allows the user to perform remote function calls. Several API endpoints are listening on that port, but the one we’re concerned with is at /system/gateway. The main ports are TCP 8088 and TCP/TLS 8043, which are used to control the administrative server over HTTP(S) and handle communication between various Ignition components. Ignition listens on a large number of TCP and UDP ports, as it has to handle several SCADA protocols in addition to its primary functionality. Before we dig deep into the vulnerabilities, let’s cover some background information on Ignition and the /system/gateway endpoint.

Ignition automation