IBM WebSphere Java Deserialization (RCE)

Identified Vulnerability through Nessus

According to Nessus, the following critical vulnerability exists on target IBM WAS and was exploited by sending a crafted Java object.

Vulnerability Information

CVE ID: CVE-2015-7450

Description:

Serialized-object interfaces in certain IBM analytics, business solutions, cognitive, IT infrastructure, and mobile and social products allow remote attackers to execute arbitrary commands via a crafted serialized Java object, related to the InvokerTransformer class in the Apache Commons Collections library.

Further Information: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7450

Approach

Nessus Analysis

We were curious how Nessus was able to exploit this vulnerability and how we could take advantage of it in order to port it to Metasploit.

Nessus Plugin ID for this vulnerability is 87171, so we performed a quick grep to find the full name of it and proceed to analysis.

Nessus uses Nessus Attack Scripting Language (NASL) as scripting language, therefore it is simple and very easy to be used. Additional information and examples how NASL tool can be run/used you can find here.

Plugin NASL code is quite simple. At first performs an “Information Gathering” about the host’s OS and then a request is sent on the default port (8880) where WAS application is listening.

Intercepting the communication we expect to see the following SOAP response.

The following NASL code lines are self explanatory. First, an ICMP echo request will be sent depending on the remote host operating system that the vulnerable application resides on. In our case WAS application was installed on a Windows Server 2008 R2, so the following ping command will be executed.

ping -n 10 192.168.1.7

where 192.168.1.7 is the host where Nessus is installed.

The rest of the code is the most difficult part as it builds a proper SOAP request encapsulating the arbitrary ping command and then performs a POST request to the target.

The tricky part of the code comes when the ping action is called. We were very curious about what could happen by replacing the ping request with something like cmd.exe without any argument, at least as a start. So we modified the above part of the code to something like the following:

# if("windows" >< tolower(os)) ping_cmd = "ping -n 10 ";
# else ping_cmd = "ping -c 10 -p " + string(id_tag) + " ";
rce_cmd = "cmd.exe";
# ping_cmd += this_host();
ping_cmd = rce_cmd;

We commented the if_else statement as we have already performed OS fingerprinting and we already knew that the remote host runs on Windows Server 2008 R2. Leaving the rest of the code as is, we launched NASL tool and waited for the cmd.exe to start on the remote system.

Note: It is worth mentioning that during the execution of the script the following verbose messages may appear in case audit-trail option is enabled. As it is shown at the following screenshot, script reported that port 8880 is not affected but it is a false positive message since NASL script waits for a ping request back in order to verify the existence of the vulnerability.

Checking alongside with the script execution the current processes of the target system, the awaited cmd.exe process started under java.exe and it also runs with SYSTEM privileges like the Java Runtime.

Using Metasploit

Parsing Web-Delivery Payload

At this point we tried to follow an easy approach to verify that the use of Powershell code could be possible for further exploitation, so we embedded inside the NASL script the following Powershell code lines.

rce_cmd = "powershell.exe -nop -ep bypass -c ping 192.168.1.7";

Everything worked as expected and Nessus verified once more that the exploitation succeeded as we performed a ping action back to the host system.

The first thing we did was to fire up Metasploit using the web_delivery module and embedding the output into the NASL script. The result was a fully functional meterpreter session.