When evaluating third-party off-the-shelf applications, security assessments often aim to provide clients with assurance regarding the vendor’s testing rigor and the application’s deployment.
An unauthenticated blind Server-Side Request Forgery (SSRF) vulnerability was identified during an assessment of Oracle’s off-the-shelf software. Given the widespread use of Oracle products, it is likely that this software has undergone extensive testing by numerous organizations over time. This particular SSRF is considered low-risk, as its primary capability is limited to enumerating open ports on both internal and external hosts. However, the details of its discovery may still be valuable to security professionals.
The Exploit
This exploit was discovered while fuzzing an endpoint that had been previously associated with an XXE vulnerability. It is a common practice to re-test patched endpoints, as developers may inadvertently introduce new issues when hastily addressing security flaws.
During the fuzzing process, a basic DOCTYPE declaration was inserted. Using a collaborator tool, it was observed that the system attempted to resolve the DNS of the provided URL, indicating a potential vulnerability. The collaborator tool used can be found here.
The resulting request, after removing redundant headers and parameters and redacting target specifics, resembled the following:
POST /OA_HTML/lcmServiceController.jsp HTTP/1.1
Host: victim.com
Content-Length: 56
<!DOCTYPE root PUBLIC "-//B/A/EN" "http://**burpcollaboratorpayload:80**">
The initial request timed out. However, a DNS hit was recorded in the Burp issue log, suggesting that an interaction occurred, but a firewall likely interfered with the full request.
Subsequent attempts using TCP/443 (HTTPS) yielded similar results. To further investigate, a colleague assisted by monitoring for requests across a wide range of ports on an external IP address, which allowed for the enumeration of the specific port number (e.g., ’80’ as seen in the example request).
This process revealed three distinct types of responses:
- Timeout: This indicated that a firewall likely dropped the request.
- HTTP 200 response with “A remote host refused an attempted connect operation.”: This suggested that the request reached the target host and port, but the port was not open.
- HTTP 200 response with “Unexpected text in DTD.”: This confirmed that the request successfully reached an open host and port.
Leveraging this information, it became possible to enumerate open hosts and ports, both internal and external, by observing the nature of the returned responses.
Furthermore, by utilizing the file:// protocol, the existence of local files could be enumerated. Attempts were made to employ other protocols and methods, hoping to capture sensitive data like hashes, but these efforts were unsuccessful in this particular scenario.
Disclosure Timeline
- April 2018: The vulnerability was discovered and reported to Oracle.
- August 2018: Oracle confirmed the issue and implemented a fix in their main codebase.
- October 2018: An Oracle Critical Patch Update was released, which included the fix for this vulnerability.
- February 2019: A blog post detailing the vulnerability was published.
