WebLogic Plugin
HTTP Injection via Encoded URLs

Release Date 2010-07-13
Application WebLogic Plugin
Versions All known versions
Severity High
Discovered by Timothy D. Morgan < tmorgan (at) vsecurity {dot} com >
Contributor George D. Gal < ggal {at} vsecurity (dot) com >
Vendor Status CPU Released
CVE Candidate CVE-2010-2375
Reference Original Advisory

Product Description

The product is best described by Oracle marketing literature in:

"Oracle WebLogic Server Enterprise Edition offers enterprises the ability to consolidate their applications on a pool of shared servers for both high efficiency and superior performance. No other application server has the proven performance on industry benchmarks across the most varied chip types and operating systems. Sophisticated High Availability (HA) features built on clustered instances ensure uptime. Easy-to-use yet substantial management tools keep systems going without hassle or expense. By coalescing applications and services onto Oracle WebLogic Server, IT is in position to react swiftly to change and help the enterprise outperform the competition." -- [1]

And

"Oracle WebLogic Server Web Server Plugins provide load balancing across WebLogic Server Clusters by acting as front-end proxies. While WebLogic Server Web Server Plugins 1.0 are bundled with WebLogic Server, these new WebLogic Server Web Server Plugins 1.1 are downloadable separately outside of WebLogic Server and deliver enhanced functionality and improved security." -- [2]

Vulnerability Overview

Over the last several years, VSR analysts had observed unusual behavior in multiple WebLogic deployments when certain special characters were URL encoded and appended to URLs. In late April, 2010 VSR began researching this more in depth and found that the issue could allow for HTTP header injection and HTTP request smuggling attacks.

Product Background

WebLogic application server is commonly deployed in a three-tier architecture where the application server resides behind a public-facing web server. Oracle provides proprietary web server plugin modules for multiple web server software packages on various platforms in order to allow these services to act as reverse proxies and in some cases, load balancers for multiple middle-tier WebLogic application servers.

Vulnerability Overview

The vulnerability stems from the web server plugin's processing of URLs submitted by users. When a URL is received, it is URL decoded at some point, but is not re-encoded prior to inclusion in requests to the middle-tier WebLogic server. This allows for special characters, such as new lines, to be injected into requests directed at application servers.

For instance, if an attacker were to send the following simple request:

GET /logo.gif%20HTTP/1.1%0d%0aX-hdr:%20x HTTP/1.1
Host: vulnerable.example.com
Connection: close

The web server proxy module would instead send a request on to the application server which looks more like:

GET /logo.gif HTTP/1.1
X-hdr: x HTTP/1.1
Host: vulnerable.example.com
Connection: close

This behavior allows for a wide variety of attacks, including trusted header injection and HTTP request smuggling.

Attack Scenarios

In the simplest scenarios, an attacker could use this flaw to inject malicious versions of headers which are considered trusted. In certain situations, headers are added to requests by the web server proxy module which may be used to make decisions about authentication or access control.

For instance, the WL-Proxy-Client-IP header is added to requests to indicate to the application server which IP address the client used. If the application server uses this to enforce IP-based access control restrictions, then clearly this injection vulnerability could be used to bypass this restriction.

Another example would be the injection of a WL-Proxy-Client-Cert header. This header is used in deployments where clients are provided SSL/TLS client certificates for authentication. Since web servers would typically terminate this encrypted communication, application servers need a way of identifying the user who was authenticated. The WL-Proxy-Client-Cert header is used to communicate this information between the web server plugin and application servers. By injecting a false version of this header, it would be possible to impersonate other users and perhaps avoid presenting a client certificate at all.

More complex attacks are also possible by using request smuggling, where a full secondary request is injected into the TCP stream sent to the application server. This class of attacks was well described in [3], but we will outline some of the interesting cases here.

Once an attacker completely controls a secondary request submitted directly to the application server, it is clearly possible to access URLs on the application server which may not be accessible externally. Depending on the application server and web server configuration, this could be used to bypass security controls implemented on the web server.

In addition, by injecting secondary requests which are unseen by the web server, this causes the pairings of requests and responses to lose correct synchronization. When attacking web servers that are configured using simple proxy pairings (for instance, under Apache HTTPD with WebLogicHost and WebLogicPort settings), this does not appear to create many avenues of attack since web server TCP connections appear to be directly paired with TCP connections to the application server. However, if a the web server plugin is configured in clustered mode, TCP connections to the application servers are shared between different clients. For this reason, it is possible to force other users to see incorrect HTTP responses and to view other users' HTTP responses.

For instance, if an attacker submitted an HTTP request which looked like the following:

GET /logo.gif%20HTTP/1.1%0d%0aHost:%20vulnerable.example.com%0d%0a%0d%0aGET%20/inject.gif HTTP/1.1
Host: vulnerable.example.com

Then the following two requests (approximately) would appear in the TCP stream between the web server and application server:

GET /logo.gif HTTP/1.1
Host: vulnerable.example.com

GET /inject.gif HTTP/1.1
Host: vulnerable.example.com

The attacker would receive the response to the first request containing the logo.gif image, but a second response would be generated by the application server and returned to the web server. Since the web server did not know two requests were submitted, it will not process this response immediately. Instead, the next request which is received (and is intended for the same application server) will be incorrectly paired with the response containing the inject.gif image.

If, after this initial injection, a victim user were to submit a request for a document containing sensitive information, they would instead receive the inject.gif image and the response to their request would remain queued up between the application server and the web server. At this point, if an attacker were able to submit another request at just the right time (before anyone else's requests to this application server), then he would receive the response containing the sensitive information. VSR has implemented a proof of concept script which exploits this condition and records responses intended for other users.

In variations of this scenario, an attacker could also pair the request smuggling attack with cross-site scripting (XSS) or cross-site request forgery attacks to make them more devastating. For instance, if a reflected XSS flaw were identified in the targeted WebLogic application, then instead of requesting "/inject.gif", an attacker could submit an injected request which exploits the flaw. Later, when a user requests any page, they would instead receive the malicious script. In effect, this allows the attacker to turn a reflected XSS flaw into a powerful persistent one.

Versions Affected

Testing was conducted on the Apache variants of web server plugin modules distributed with WebLogic 9.2, and 10.3. Version 1.1 of the plugin modules (distributed separately) were also tested and found to be vulnerable. In previous testing, the flaw appeared to exist in the Sun ONE web server versions of the plugin as well.

Oracle has indicated that WebLogic web server plugins shipped with WebLogic 7.0 SP7, 8.1 SP6, 9.0, 9.1, 9.2 MP3, 10.0 MP2, 10.3.2, and 10.3.3 are affected by this issue for Apache, Sun and IIS web servers.

Vendor Response

The following timeline details Oracle's response to the reported issue:

2010-05-04 Oracle was provided a draft advisory.
2010-05-05 Oracle acknowledged the notice and subsequently confirmed the vulnerability. Issue #17254767 assigned.
2010-06-16 Continued communication with Oracle; July CPU targeted for release of fix.
2010-07-09 Oracle notified VSR that a patch would be included in the July 13th CPU.
2010-07-13 Oracle CPU and VSR advisory released.

See also: Oracle's advisory

Recommendation

It is recommended that WebLogic Plugin users apply the Oracle July 2010 Critical Patch Update (CPU) as soon as possible.

If this is not immediately possible, a partial work-around may be achieved by blocking certain encoded special characters in requested URLs. It is recommended that the following be blocked (in a case-insensitive manner):

  %0d
  %0a

These characters must be blocked in URLs at the perimeter prior to processing by the WebLogic plugin. The following Apache mod_security rules can be used, in the top-level configuration context, to mitigate this threat in most cases:

SecRule REQUEST_URI "%0d" "phase:1,t:none,t:removeNulls,t:lowercase,deny,status:403"
SecRule REQUEST_URI "%0a" "phase:1,t:none,t:removeNulls,t:lowercase,deny,status:403"

Note that in practice it may be difficult to fully mitigate this flaw with URL filtering due to complexities introduced by various character encodings, fragmentation attacks, and inconsistencies in HTTP processing between platforms.

Common Vulnerabilities and Exposures (CVE) Information

The Common Vulnerabilities and Exposures (CVE) project has assigned the number CVE-2010-2375 to this issue. This is a candidates for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems.

Acknowledgements

Thanks to George Gal for assistance in testing and to Oracle for its cooperation throughout the disclosure process.


References

1. http://www.oracle.com/appserver/docs/weblogic-suite-datasheet.pdf
2. http://www.oracle.com/technology/software/products/ias/htdocs/wls_plugins.html
3. http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
4. http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2010.html
5. http://www.vsecurity.com/download/tools/WebLogicPlugin-HRS-PoC.sh

This advisory is distributed for educational purposes only with the sincere hope that it will help promote public safety. This advisory comes with absolutely NO WARRANTY; not even the implied warranty of merchantability or fitness for a particular purpose. Virtual Security Research, LLC nor the author accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.

See the VSR disclosure policy for more information on our responsible disclosure practices.


Copyright 2010 Virtual Security Research, LLC. All rights reserved.

2013-06-19
IBM WebSphere Commerce: Encrypted URL Parameter Vulnerable to POA

2012-10-23
Timothy D. Morgan presents No Crack Required: Cryptanalysis in Real-World Applications at OWASP AppSecUSA 2012.

2012-07-29
Michael Coppola presents Owning the Network: Adventures in Router Rootkits at DEF CON 20 [slides].

2012-04-20
HTC IQRD Android Permission Leakage

more...

Contact us by phone,
fax or e-mail:

Phone: 617.933.8919
Fax: 617.933.8920
Email: inquiry@vsecurity.com