VSR Security Advisory
http://www.vsecurity.com/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Advisory Name: 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 >
Contributors: George D. Gal < ggal {at} vsecurity (dot) com >
Vendor Status: Patch Released [4]
CVE Candidate: CVE-2010-2375
Reference: http://www.vsecurity.com/resources/advisory/20100713-1/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 [5] 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 at [2]) 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 [4]
Recommendation
--------------
It is recommended that WebLogic Plugin users apply the Oracle July 2010
Critical Patch Update (CPU)[4] 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:
http://www.vsecurity.com/company/disclosure
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Copyright 2010 Virtual Security Research, LLC. All rights reserved.
To view the advisory as a txt. click here.
Editor’s note: This work was originally published by VSR on their website at https://www.vsecurity.com/resources/advisories.html. VSR is now a part of NCC Group, so we have migrated this content to research.nccgroup.com. The advisory text as above has been copy-pasted to this blog for historical reference.
