A Trio of Bugs Used to Exploit Inductive Automation at Pwn2Own Miami

Before we dig deep into the vulnerabilities, let’s cover some background information on Ignition and the /system/gateway endpoint. 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.

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.

Several API endpoints are listening on that port, but the one we’re concerned with is at /system/gateway. This API endpoint allows the user to perform remote function calls. Only a few can be called by an unauthenticated user. The Login.designer() function is one of them. It communicates with clients using XML containing serialized Java objects. Its code resides in the com.inductiveautomation.ignition.gateway.servlets.Gateway class.

Usually, performing client-server communications with serialized Java objects can lead to direct code execution, but in this case, it is not that simple. Before we dive into that, let's look at what a Login.designer() request looks like:

The request and response contain serialized Java objects that are passed to functions that can be called remotely. The example above shows a call to the designer() function of the com.inductiveautomation.ignition.gateway.servlets.gateway.functions.Login class with four arguments.

The call stack before we reach Login.designer() is as follows:

com.inductiveautomation.ignition.gateway.servlets.Gateway.doPost()
com.inductiveautomation.ignition.gateway.servlets.gateway.AbstractGatewayFunction.invoke()
com.inductiveautomation.ignition.gateway.servlets.gateway.functions.Login.designer()

The Gateway.doPost() servlet performs some version and sanity checks then sends the request to AbstractGatewayFunction.invoke(), which parses and validates it before calling Login.designer(), as shown below:

This function does the following:

1 - Parses the received message.
2 - Identifies the function to be called.
3 - Checks the function arguments to determine if they are safe to be deserialized.
4 - Ensures the number of arguments corresponds to the expected number for the target function.
5 - Calls the function with the deserialized arguments.
6 - Sends the response back to the client.

Before being deserialized, the arguments are checked to ensure they contain “safe” objects. This is done by calling decodeToObjectFragile() from com.inductiveautomation.ignition.common.Base64. This function takes two arguments: a String with a Base64 encoded object and an allowed list of classes that are safe to deserialize.

As seen above, if decodeToObjectFragile() receives null instead of a list of allowed classes, it uses a “normal” ObjectInputStream to deserialize the object, with all the problems and insecurity it brings. However, if an allowed list is specified, decodeToObjectFragile uses the SaferObjectInputStream class instead to deserialize the object.

The SaferObjectInputStream class is a wrapper around ObjectInputStream that checks the class of each object being deserialized. If the class is not part of the allowed list, it rejects all input and terminates processing before any harmful effects occur. Here’s how that looks:

As it can be seen in the snippet above, the default allow list (DEFAULT_WHITELIST) is very strict. It only allows the following object types to be deserialized:

      -- String
      -- Byte
      -- Short
      -- Integer
      -- Long
      -- Number
      -- Float
      -- Double
      -- Boolean
      -- Date
      -- Color
      -- ArrayList
      -- HashMap
      -- Enum

Since these are all very simple types, the mechanism described here is an effective way to stop most Java deserialization attacks.

It is out of the scope of this blog to explain Java deserialization, how it happens, and how devastating it can be. If you’re interested in reading more about it, check out Java Unmarshaller Security or this Foxglove Security Blog Post. Now let’s get to the exploit chain we used at Pwn2Own.

Vulnerability 1: Unauthenticated Access to Sensitive Resource

The first vulnerability in this chain is an information leak, but not used as such in our exploit. An unauthenticated attacker can invoke the “project diff” functionality to obtain crucial information about a project. In our case, we used this as a springboard to attack other functionality.

The com.inductiveautomation.ignition.gateway.servlets.gateway.functions.ProjectDownload class contains a number of actions that are accessible by an unauthenticated remote attacker. One of them is getDiffs(), which is shown below:

As seen above, this function compares the provided data with the project data in the server and returns a diff. If an attacker provides a valid project name, it is possible to trick the server into handing over all the project data.

Again, this functionality is not used in the exploit. Instead, this function is used as a springboard to further attack the system, which will be further explained below.

Vulnerability #2: Insecure Java Deserialization

As it can be seen in Snippet 6, ProjectDownload.getDiffs() uses Base64.decodeToObjectFragile() function to decode project data. This function was already explained in Snippet 4. As we explained above, if no class allow list is provided in the second argument to the function, it uses the standard unsafe ObjectInputStream class to decode the given object. This leads to a classic Java deserialization vulnerability, which ultimately results in remote code execution when chained with the final vulnerability.

To summarize, to achieve remote code execution, we need to do the following:

1 - Create a ysoserial CommonsBeanutils1 payload.
2 - Base64 encode the payload.
3 - Encapsulate the payload in a Java String object.
4 - Serialize the String object using the standard Java serialization functionality.
5 - Base64 encode the serialized String object.
6 - Send a request to /system/gateway invoking getDiffs() with the malicious parameters.

We're able to bypass the serialization whitelist and execute our code! But how? Let's dig into it.

Our payload will have the following format:

base64(String(base64(YSOSERIAL_PAYLOAD))

The code shown in Snippet 3 will perform Base64 decoding on it, which will result in:

String(base64(YSOSERIAL_PAYLOAD))

This is checked against the whitelist shown in the previous section and allowed to be deserialized since it’s a String class. We then go into ProjectDownload.getDiffs(). It takes our String argument and calls Base64.decodeToObjectFragile() on it without specifying a whitelist.

As shown in Snippet 4, this will Base64 decode the String and then invoke ObjectInputStream.readObject() on our malicious object (YSOSERIAL_PAYLOAD), resulting in code execution!

Payload Generation

To create our payload, we start by calling ysoserial as shown below:

In this code, <YSOSERIAL_BASE64_PAYLOAD> should contain the output of Snippet 7.

Finally, we send the following request to the target:

The <PAYLOAD> will contain the output of running Snippet 8. The target will respond with:

The response contains a stack trace indicating something went wrong, but the payload was executed as SYSTEM (or root on Linux).

With the payload provided in Snippet 7, a file will appear in C:\flashback.txt with the text nt authority\system. This shows we have achieved unauthenticated remote code execution.