Exploiting Other Remote Protocols in IBM WebSphere
September 29, 2020 | Guest UserIn a recent blog post, we disclosed how a vulnerability in the Internet InterORB Protocol (IIOP) protocol of IBM WebSphere can result in remote code execution. In this blog post, we explore how two additional protocols supported by this application server can also be leveraged to achieve the same result. The first is a logic flaw in the authentication mechanism of the wsadmin SOAP endpoint submitted by the researcher known as tint0 (ZDI-20-878), and the second is a vulnerability in a protocol used for WebSphere Extended Deployment reported by b0yd (ZDI-20-688)
CVE-2020-4464: SOAP Deserialization of Untrusted Data
This attack vector should be familiar to most, as it was used to exploit a vulnerability in IBM WebSphere back in 2015 and documented in the blog post by Foxglove Security which brought Java Deserialization vulnerabilities to the spotlight. The blog showed that it is possible to directly embed serialized objects within a SOAP request. IBM has addressed this issue by ensuring that authentication is required before reaching any deserialization code path.
In their report to ZDI, tint0 demonstrated that there was a flaw in this authentication mechanism when token-based authentication is used. The authSOAPRequest() method is responsible for authentication, which eventually calls retrieveSubject():
As shown above, retrieveSubject() extracts the token string from the SOAP request and validates it using authenticateToken(). If authenticateToken() is unable to validate the token, it returns a Subject for a principal named Unauthenticated. The code shown above does not properly check for this possibility. Instead, it checks to see if the returned value is null.
So simply by including the following string in the SOAP request:
<LoginMethod>TokenBased</LoginMethod><token>foo</token>
the attacker can bypass authentication. Ultimately, GenericSerializer.unmarshall() is reached:
Within unmarshall(), there are two paths to arbitrary object deserialization.
Please note that various mitigations in the IBM Java SDK make it non-trivial to find a valid gadget to exploit this vulnerability. tint0 provided a gadget capable of bypassing these mitigations. Details of these mitigations and this gadget were explained in a previous blog post.
Here is a demonstration of the exploit in action:
CVE-2020-4448: WebSphere Extended Deployment
The deployment manager runs as a management server on WebSphere. It is created by installing the WebSphere Application Server Network Deployment product and creating a management profile using the deployment manager profile template. In its default deployment, it listens on TCP port 11006. This is the TCP communications port for WebSphere Extended Deployment administrative functions.
This service receives Broadcast messages. For each received message it invokes the processBroadcastMessage method of a corresponding BroadcastMessageProcessor to handle the message. It is possible for the attacker to specify which BroadcastMessageProcessor will be invoked.
One available BroadcastMessageProcessor is UploadFileToAllNodes, which offers a file upload function. A directory traversal vulnerability in this processor allows arbitrary file to be uploaded to an arbitrary location.
Here is the exploit in action:
Conclusion
IBM fixed the SOAP deserialization vulnerability in July and assigned it CVE-2020-4464. The fix ensures the returned Subject within authSOAPRequest() is in fact authenticated by calling SubjectHelper.getWSCredentialFromSubject(subject).isUnauthenticated()
IBM corrected the vulnerability in Network Deployment in June and assigned it CVE-2020-4448. For this bug, they addressed the issue by fully deprecating the file upload functionality.
If you’re curious about other deserialization vulnerabilities, the aforementioned blog from Foxglove Security is a great place to start, as is this overview from the Center for Internet Security. These types of cases are being submitted to our program more often, and we look forward to receiving more deserialization bugs in the future.
You can find me on Twitter at @zebasquared, and follow the team for the latest in exploit techniques and security patches.