The Tales of N4nj0

IBM InfoSphere Information Server - Java Deserialization


A Java Deserialization vulnerability is found on IBM InfoSphere Information Server
The vulnerability allows a remote attacker to fully compromise the operating system remotely, by using the specialized tool BarMIe.
Full credits are for security researchers Damiano Proietti, Davide De Rubeis and Matteo Brutti.

Product Information

The IBM Info Sphere Information Server product features the JReport service, which is a Java service that does not make sure that the content of Java objects being deserialized is safe. In this way it has been possible to exploit malicious objects to obtain a remote command execution on the machine that hosts the product.
By using an RMI enumeration tool it is possible to identify the fact that the port that exposed the JReport service is vulnerable to such an attack.

We tried to contact IBM PSIRT security team, but they do not recognize the security issue because the product is end-of-life. I am releasing the full disclosure for the reason I believe, which is that users have to be informed to make appropriate decisions, especially those who cannot afford an upgrade for several reasons.

It is recommended to update to the latest version, disable the JReport service, or at least enforce the firewall rules to that vulnerable service port.

Vulnerability Details

Deserialization of Untrusted Data (CWE-502)

  • Summary: When the JReport service is enabled as a web service, it is possible to create and send malicious Java objects to obtain a remote command execution on the remote target.
  • Prerequisites: The JReport service needs to be enabled on InfoSphere.
  • CVE and CVSS Score: CVE-2020-27583 | 9.8 (Critical)

Step-by-step instructions and PoC

RMI Vulnerability Enumeration

The JReport service exposing objects via an RMI registry is found on port 58611.
The following command can be used to enumerate the target:

java -jar BaRMIe_v1.01.jar -enum <IP> <PORT>

Target enumeration

RMI Vulnerability Exploitation

The following command can be used to attack the target:

java -jar BaRMIe_v1.01.jar -attack <IP> <PORT>

Target attack (1)

The BaRMIe tool uses the Apache Commons collection software as a vector for the bind() method.

The Registry.bind() method in the Java version used by JReport does not validate the type of the parameter before deserializing it, so it is possible to alter one of the parameters used. This lack of validation allows the use of a crafted payload, which issues commands to the host server, after being deserialized.

It is possible to enter the target information interactively, when requested by the tool.
In this case, the payload used is the creation of a file in the /tmp folder of the server, but the tool itself cannot verify the successful attack.

Target attack (2)

By logging to the target machine, it is verified that the file is created in the /tmp folder, so the RCE is successful.

Attack validation

To remotely compromise the target, it is possible to upload and execute a simple python reverse shell.
After getting root access via the exploit, it is found that the parent process which is using the vulnerable JReport service is IBM Info Sphere.

Searching for the PID of JReport service

It is confirmed that the vulnerable version is

Vulnerable version

Security Impact

By exploiting this issue an attacker is able to execute commands with the privilege of the web service, which is running as root in this case. With this privilege level, an attacker can access to any kind of sensitive data and perform any kind of malicious activity with the affected target.


  • 31/07/2020: First disclosure IBM PSIRT Team
  • 31/07/2020: Automatic acknowledge e-mail from IBM PSIRT Team. Nice to have 😊
  • 24/08/2020: Ping request to IBM PSIRT Team for news.
  • 26/08/2020: IBM PSIRT Team reports that the product is out of support since 2016 and they no longer provide fixes or security bulletins for this version.
  • 20/10/2020: Requested the CVE to MITRE using the CNA of Last Resort (CNA-LR). It is the one to use when the vendor does not recognize the issue because of the end-of-life reason.
  • 20/11/2020: MITRE assigned in reserved state.
  • 18/01/2021: As a lot of time passed from our first notification, I am releasing the full disclosure.
  • 21/01/2021: MITRE release the reservation for the CVE ID.
  • 26/01/2021: NVD sored the CVE as 9.8 (Critical).