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
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.
