Unauthenticated Blind SSRF in Oracle EBS

Source: Dev.to

When testing third‑party off‑the‑shelf applications, the goal is often to give the client assurance that the vendor has conducted robust testing and that there are no glaring issues in the deployment.

During a test of Oracle’s off‑the‑shelf software, a low‑risk SSRF was discovered. It allows enumeration of ports on internal and external hosts, which may be of interest to some researchers.

The Exploit

The issue was found while fuzzing an endpoint that had previously been involved in an XXE exploit. A basic DOCTYPE declaration was sent, and a handy collaborator payload revealed that the server attempted to resolve the supplied URL.

The request (with redundant headers/parameters removed and target details redacted) looked like this:

POST /OA_HTML/lcmServiceController.jsp HTTP/1.1
Host: victim.com
Content-Length: 56

The request timed out, but a DNS hit appeared in the Burp issue log, indicating that a firewall was interfering. After testing with TCP/443 (HTTPS) and receiving the same result, a colleague listened for requests across a wide range of ports on an external IP, allowing enumeration of the port number (e.g., “80” in the request above).

Three types of responses were observed:

• Timeout – the firewall dropped the request.
• HTTP 200 with “A remote host refused an attempted connect operation.” – the host/port was reached but not open.
• HTTP 200 with “Unexpected text in DTD.” – the host/port was reached and open.

Using this information, it was possible to enumerate hosts and ports both internally and externally by monitoring the type of response returned. Additionally, the file:// protocol could be used to check for the existence of files. Other protocols were tested in hopes of retrieving a hash, but this was not possible in this instance.

Disclosure Timeline

• April 2018: Issue discovered and reported to Oracle.
• August 2018: Oracle confirmed the issue and fixed the main code line.
• October 2018: Oracle Critical Patch Update released, including the fix – see the Oracle CPU October 2018 advisory.
• February 2018: Blog post detailing the vulnerability was published.