When assessing enterprise perimeters, legacy subdomains often hide complex architectural flaws. During a recent engagement targeting a single subdomain running an End-of-Life (EOL) stack — Oracle BI Discoverer 11.1.1.7.0 and Apache 2.2.22 — I uncovered two distinct, high-impact vulnerabilities.

Instead of relying on automated scanners, which often miss the nuances of legacy protocols, I performed a deep-dive manual analysis. This led to the discovery of an unauthenticated Server-Side Request Forgery (SSRF) utilizing CRLF protocol smuggling , alongside a Reflected Cross-Site Scripting (XSS) vulnerability that I escalated into silent database exfiltration.

Here is the technical breakdown of both independent findings.

Vulnerability 1: Unauthenticated SSRF and CRLF Protocol Smuggling

The first major discovery occurred at the /discoverer/app/directPartialConnect endpoint. The application allowed users to specify a database connection string via the databaseIdentifier parameter.

Due to a lack of input validation and the server being configured with Oracle "Easy Connect" (EZConnect) enabled, the backend attempted to resolve and connect to any provided IP or hostname.

Internal Reconnaissance via Error Analysis

By utilizing an out-of-band testing payload (YOUR_ID.oast.me:1523/ORCL), I forced the server to initiate an outbound DNS and TCP connection, confirming the SSRF capability. I then pivoted to mapping the internal network. By targeting specific internal IP addresses and observing the differential Oracle Database error messages returned, I could accurately fingerprint internal services:

• Targeting Port 7001 (127.0.0.1:7001/ORCL): Returned ORA-12537: TNS:connection closed.
• Targeting Port 1521 (127.0.0.1:1521/ORCL): Returned ORA-12541: TNS:no listener.
• Conclusion: This confirmed that Port 7001 — which traditionally hosts the WebLogic Administration Console — was open and reachable internally.

The Protocol Smuggling Bypass

While reaching an internal port is critical, the strict Oracle TNS wrapper prevented direct HTTP exploitation by enforcing character validation and strict length limits (returning ORA-12169 for over-length payloads).

To bypass this, I discovered the parameter was vulnerable to CRLF injection (%0d%0a). By injecting CRLF characters, I successfully bypassed the local parser. The backend socket hung significantly longer, requiring 9 progress polling requests before returning an error, compared to a baseline of 4. This timing anomaly proved the injected payload successfully interacted with the internal WebLogic service.

Impact: Exposing the WebLogic Admin Console on an EOL server provides a primary vector for critical unpatched RCE vulnerabilities, such as CVE-2020–14882. This SSRF successfully bypassed the perimeter firewall to manipulate socket connection states on hidden management services.

Vulnerability 2: Reflected XSS Escalated to Session Riding

While auditing the URL path routing mechanism at the /discoverer/app/ endpoint, I identified a Reflected XSS vulnerability.

When requesting an invalid path containing malicious JavaScript, the Oracle 11g backend attempted to handle the error by echoing the unsanitized path back to the user in a 400 Bad Request response body. By injecting a URL-encoded <script> tag directly into the path, the payload executed immediately, as modern browsers still parse and render the text/html response body of 400 status codes.

Escalation: Weaponizing DOM State Tokens

Initially, I noted that the application failed to set the HttpOnly flag on its JSESSIONID cookies, allowing standard session hijacking via document.cookie. However, I wanted to maximize the business impact.

Following a deep analysis of the Oracle UIX framework's state management, I discovered that the application heavily relies on hidden DOM tokens (stateStr and stateID) to authorize critical actions, such as querying the database or exporting workbooks.

Because the XSS payload executes within the document's context, I built an exploit chain that allowed for complete Session Riding and Data Exfiltration:

1. Extraction: When an authenticated internal user clicks the malicious link, the JavaScript instantly extracts the active stateStr and stateID tokens directly from the hidden <input> fields in the victim's DOM.
2. Session Riding: The script silently forges a POST request to the /discoverer/app/exportdata endpoint using the stolen tokens.
3. Exfiltration: This forces the application to generate an export of the current sensitive database worksheet, which the script then reads and exfiltrates to an attacker-controlled server via a standard fetch() or XMLHttpRequest.

Impact: This escalation elevates a standard phishing vector into a High-severity risk, compromising confidentiality via the silent extraction of internal database reports, and integrity via unauthorized session riding.

Defensive Takeaways

Securing legacy infrastructure requires rigorous attention to fundamental security controls. To remediate these vulnerabilities, I recommended:

• For the SSRF: Update sqlnet.ora to explicitly remove EZCONNECT, restrict the databaseIdentifier to a whitelist of approved TNS aliases, and implement strict egress filtering on the BI server.
• For the XSS: Rigorously apply context-aware HTML entity encoding to all user-controlled data (including URL paths) before reflection, and configure the application server to flag all session cookies with the HttpOnly attribute.