[REVS] Meanwhile - On the Other Side of the Web Server
From: SecuriTeam (support_at_securiteam.com)
Date: 06/15/05
- Previous message: SecuriTeam: "[NEWS] Bluetooth SIG DoS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 15 Jun 2005 10:39:21 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Meanwhile - On the Other Side of the Web Server
------------------------------------------------------------------------
SUMMARY
The short whitepaper below is intended to highlight security issues of
devices that exist in the path between the client browser and the web
server, namely: Cache servers, Load balancer, IDSs, Web Application
Firewall, etc.
DETAILS
Introduction:
In the beginning, there were the web servers, and they were attacked (e.g.
CodeRed, Nimda), and people learned how to configure web servers and patch
them, and it was good. Then the dynamic pages and application servers were
added, and they were attacked (XSS, file inclusion/retrieval, price
mutation, cookie poisoning, etc.), and people learned how to sanitize
input, and encode output, and it was good. Then the backend SQL databases
and mainframes and backend servers were "discovered", and they were
attacked, and people learned how to build parameterized SQL queries, and
to avoid various injection scenarios, and it was good. Meanwhile, on the
other side of the server, servers, devices and appliances were silently
added to the "web presence" of the application, and these were studied and
understood very little. The other side of the web server, all those
web/network "stuff" between (or alongside) the web-server and the client
(browser), and their impact on security, is the subject of this write-up.
The major claim of this write-up is that we should start looking at the
communication between the web server and the client.
Specifically, we should take a good hard look at the HTTP-aware entities
that process the HTTP requests and responses passing to and fro between
the client and the server.
Of course, oftentimes adding a component to a system increases the overall
insecurity, since this component may be directly broken into. But the more
interesting thing about these entities is that there's an additional risk
here: a security problem that materializes in a combination of entities,
or (specifically) in the interaction between an entity and the web
application. It is these problems that we're going to focus on.
Below is a list of such HTTP-aware entities:
* Cache server (on-site)
* Cache server (client side)
* SSL accelerator (SSL termination)
* Load balancer
* Reverse proxy server (on-site)
* Forward/transparent proxy server (client side)
* IDS/HTTP-aware firewall
* Web Application Firewall (WAF)
* (and there are probably more )
There are also issues with web-sites that are virtually hosted, i.e. the
same physical web server hosts several sites not in the same domain (or
ownership). We can think of this case as an interaction between entities
such as the web server software and the two virtual sites.
Virtual hosts:
Running a web site as a virtual host, alongside with other, untrusted
virtual hosts, on the same physical server, sharing the same port (as is
usually the case - this would be port 80), can result in the following
conditions:
1. If there's also a cache server that shares a TCP connection from a
client to two
virtual hosts with the same IP address - Complete web cache poisoning
through HTTP Response Splitting (see
<http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf> [1], p. 26 - "Cross-host web cache poisoning attack").
2. If there's also a cache server that shares a TCP connection from a
client to two virtual hosts with the same IP address - Complete web cache
poisoning through HTTP Request Smuggling (see
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf> [2], p. 4
- "Special Cases - more powerful attacks").
3. Escalation of XSS condition (see [3]), if such exists in the site.
Cache servers (which are proxy servers by definition):
Having the HTTP traffic pass through cache servers can result in:
1. Complete web cache poisoning (if there's an HTTP Response Splitting
vulnerability in the web application - see
<http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf> [1]).
2. Partial web cache poisoning (through HTTP Request Smuggling - see
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf> [2]).
Proxy servers (not necessarily caching):
Having the HTTP traffic pass through proxy server that shares a TCP
connection to the same host between different clients can result in:
1. Escalating of XSS condition into request hijacking (see
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf> [2], p. 7
- "Example #4 - Request Hijacking").
2. Forceful submission of a request on behalf of a client (see [2], p. 9 -
"Example #5 - Request Credential Hijacking").
3. Cross user defacement, if there is an HTTP Response Splitting
vulnerability in the web site (see
<http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf> [1] p. 22 - "Cross User
Attacks - The Theory").
4. Hijacking a user response page, if there is an HTTP Response Splitting
vulnerability in the web site (see
<http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf> [1] p. 23 - "Hijacking a Page (HTTP Response) with User Sensitive Information").
HTTP-Aware firewalls (including Web Application Firewalls):
While these entities are put in place to protect the application, in some
cases they can be completely or partially bypassed. This in itself does
not mean that the application becomes vulnerable. However, these "attacks"
are listed because they have to do with how various web-server behaviors
enable some attacks (especially in HTTP Request Smuggling). These
"attacks" are:
1. Smuggling a complete request via HTTP Request Smuggling (see
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf> [2],
especially p. 4 - "Example #2: Firewall/IPS/IDS evasion"), that is, the
firewall/IDS won't block/detect a request (an attack) it should have.
2. Bypassing some firewall/IDS protection/detection schemes (see
<http://www.modsecurity.org/blog/archives/000053.html> [4],
<http://www.ussrback.com/docs/papers/IDS/whiskerids.html> [5]), that is,
the firewall/IDS won't block/detect a request (an attack) it should have.
So the net effect in this case is that the security of the overall system
is affected by the combination of entities. The only difference between
this item and the previous ones is that in this item, a security tier (the
firewall/IDS) was bypassed, thus potentially exposing system
vulnerabilities, while in the previous items, the system was shown to be
directly vulnerable to attacks.
Web Application Firewalls:
Some WAFs employ a technique in which the HTML responses of the
application are used to create a dynamic, per-user policy of allowed
links/forms/actions. In such case, an attack against the WAF's security
policy would be to inject a link (which represents an attack against the
web server, e.g. a Nimda URL) somehow into the HTML response. This link
would in turn be allowed by the WAF for the user (the attacker, in this
case), who will happily request this link immediately thereafter. Just
like the previous item, this "attack" simply punctures through the
protection suite of the WAF, it is not a vulnerability in the application.
Yet just as the previous item, the "interaction" between the application
and the WAF may weaken the WAF protection and thus expose vulnerabilities
in the system.
Load balancers and SSL accelerators:
While no specific attack was reported for these products (other than
attacks that target the devices themselves), it is expected that the
techniques outlined in
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf> [2] are
applicable to load balancers and to SSL accelerators, since these devices
typically look at the HTTP requests and route them to their final
destination according to the parsed requests. In that sense, the
techniques in
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf> [2] may be
used to fool these devices into routing requests to other servers instead.
Summary:
The web application, or rather, the web application security, extends
beyond the web server (or the virtual web server), not only in the
backend's direction, but also in the browser's direction - to the site's
cache/proxy server, SSL accelerator, load balancer, IDS, firewall and web
application firewall, and beyond that, to the client's ISP cache/proxy
server. It also extends to the neighboring virtual web servers. More
research and understanding is needed in these areas, in order to
comprehend all possible risks and develop appropriate solutions for them.
References:
[1] "Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning
Attacks, and Related Topics", Amit Klein, March 2004.
<http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf> http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
[2] "HTTP Request Smuggling", Chaim Linhart, Amit Klein, Ronen Heled and
Steve Orrin, June 2005
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf>
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
[3] "XS(T) attach variants which can, in some cases, eliminate the need
for TRACE", Amit Klein, WebAppsec mailing list posting, January 26th, 2003
<http://www.securityfocus.com/archive/107/308433>
http://www.securityfocus.com/archive/107/308433
[4] "External Web Application Protection: Impedance Mismatch", Ivan
Ristic, March 9, 2005
<http://www.modsecurity.org/blog/archives/000053.html>
http://www.modsecurity.org/blog/archives/000053.html
[5] "A look at whisker's anti-IDS tactics", Rain Forest Puppy, December
1999
<http://www.ussrback.com/docs/papers/IDS/whiskerids.html>
http://www.ussrback.com/docs/papers/IDS/whiskerids.html
ADDITIONAL INFORMATION
The information has been provided by <mailto:aksecurity@hotpop.com> Amit
Klein (AKsecurity).
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[NEWS] Bluetooth SIG DoS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
