Unauthenticated Blind SSRF in Oracle EBS

CVE-2018-3167

John M
2 min readFeb 12, 2019

When testing third party off the shelf applications, it typically just to give the client some assurance that the third party has conducted testing robustly and there’s no absolute clangers in either the way it’s been deployed.

The below SSRF was found on one such test of off the shelve third party software in Oracle (so we can be fairly certain it’s been tested by various organisations over the years). It is fairly low risk, only allowing the enumeration of ports on internal/external hosts, but may be of interest to some.

The Exploit

I found this exploit when fuzzing an endpoint involved in a previous XXE exploit, something I often do as in my experience developers will often make mistakes when rushing to patch a vulnerability.

During this fuzzing process I put in a basic DOCTYPE declaration and through some “handy collaborator” shenanigans found that something was trying to resolve the DNS of the supplied URL.

The resultant request looked something like the below request (after removing redundant headers/parameters, and redacting target details).

POST /OA_HTML/lcmServiceController.jsp HTTP/1.1
Host: victim.com
Content-Length: 56
<!DOCTYPE root PUBLIC "-//B/A/EN" "http://burpcollaboratorpayload:80">

To which… my request timed out. However, I got a DNS hit in my Burp issue log indicating something was happening but it was likely a firewall was messing with the request.

After trying TCP/443 (HTTPS) and getting the same result, I enlisted the help of a colleague to listen for requests across a large range of ports on an external IP and enumerated the port number accordingly (“80” in the above request).

This resulted in three types of responses

  • Timeout (indicating that a Firewall dropped the request)
  • A HTTP 200 response containing A remote host refused an attempted connect operation. (indicating the host/port got hit but wasn’t open)
  • A HTTP 200 response containing Unexpected text in DTD. (indicating the host/port got hit and was open)
Example Response (in this case indicating SSH is open on localhost)

So using that information it was possible to enumerate hosts/ports both internally and externally by monitoring the type of response returned.

In addition by using file:// it’s possible to enumerate the existence of files. I did try other protocols/methods in the hopes of catching a hash but unfortunately this proved to not be possible in this specific instance.

Disclosure Timeline

  • April 2018: Issue discovered and reported to Oracle
  • August 2018: Oracle confirm issue and fix in main code line
  • October 2018: Oracle Critical Patch Update released including fix for this vulnerability
  • February 2018: This blog post detailing vulnerability published

--

--