|
|
|
|
| |
Credit:
The information has been provided by Timothy D. Morgan.
The original article can be found at: http://www.vsecurity.com/resources/advisory/20100713-1/
|
| |
Vulnerable Systems:
* WebLogic 7.0 SP7 on Apache, Sun and IIS web servers
* WebLogic 8.1 SP6 on Apache, Sun and IIS web servers
* WebLogic 9.0 on Apache, Sun and IIS web servers
* WebLogic 9.1 on Apache, Sun and IIS web servers
* WebLogic 9.2 MP3 on Apache, Sun and IIS web servers
* WebLogic 10.0 MP2 on Apache, Sun and IIS web servers
* WebLogic 10.3.2 on Apache, Sun and IIS web servers
* WebLogic 10.3.3 on Apache, Sun and IIS web servers
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.
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.
Patch Availability:
It is recommended that WebLogic Plugin users apply the Oracle July 2010 Critical Patch Update (CPU) as soon as possible:
http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2010.html
Workaround:
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.
CVE Information:
CVE-2010-2375
Disclosure Timeline:
2010-05-04 Oracle was provided a draft advisory.
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
|
|
|
|
|
