Message-ID: <42A8D81F.15969.1AF498B@localhost>
Date: Fri, 10 Jun 2005 00:00:31 +0200
From: "Amit Klein (AKsecurity)" <aksecurity@...pop.com>
To: bugtraq@...urityfocus.com
Subject: "Meanwhile, on the other side of the web server" - a new write-up by
 Amit Klein


          Meanwhile, on the other side of the web server

        A survey of new attacks on the less explored parts
                    of the web application

                    Amit Klein, June 2005


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.


The known problems
==================

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 [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 [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 [1]).
2. Partial web cache poisoning (through HTTP Request Smuggling – see
   [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 [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 [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 [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 [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 [4],
   [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 [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 [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

[2] "HTTP Request Smuggling", Chaim Linhart, Amit Klein, Ronen Heled
    and Steve Orrin, June 2005
    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

[4] "External Web Application Protection: Impedance Mismatch", Ivan
    Ristic, March 9, 2005
    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

Powered by blists - more mailing lists