WebLogic Plugin HTTP Injection Via Encoded URLs

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
  
  
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.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1.4.10 (GNU/Linux)  
  
iD8DBQFMPOckQ1RSUNR+T+gRAh4LAKCEjvU7fBsrYqM0wWwLKB1cPY/q2ACfRxuB  
5aP10A9ZRuFbP31Hj/Fo1/I=  
=uJId  
-----END PGP SIGNATURE-----  
  
`