[WEB SECURITY] "Meanwhile, on the other side of the web server" - a writeup by Amit Klein
Amit Klein (AKsecurity)
aksecurity at hotpop.com
Fri Jun 10 03:30:37 EDT 2005
On 9 Jun 2005 at 21:08, Ryan Barnett wrote:
> This is great stuff! You know, it might be worth mentioning the
> different techniques used to identify intermediary devices such as
> proxies, etc... This would need to be accomplished prior to running
> the attacks that you outline. Here are some examples -
Thanks. Actually, I think that you can pack your response nicely as an independent write-up
(the need to discover the architecture of the site from the HTTP/web perspective may be of
value beyond the context of my write-up). I think your text below definitely lists the
common methods, and as you say, more research should be done here as well.
> 1) Use of the HTTP TRACE Method
> The old traceroute for the web - You can send off the trace request to
> web sites and any intermediate HTTP proxies will add their name to the
> "Via" header. I am still surprised at the number of proxies that are
> still forwarding TRACE requests...
> 2) Inspecting Location Response Headers
> Reverse proxies may leak the back-end host within the location header.
> 3) Hostname disclosures
> DNS lookups and some error pages from proxies may disclose a hostname
> that indicates that it is a proxy. Take a look at the Netcraft
> SearchDNS interface. I put in a search for any domain name that
> starts with "cache.*" and it returned over 300 entries -
> 4) Virtual Hostname Errors
> You might also be able to identify reverse proxies by munging the
> "Host:" request header. You could leave it blank, leave off the
> domian extension or append a dot at the end - such as
> "www.companyx.com." - as different reverse proxies handle the requests
> differently (semantic) and display different status codes and error
> 5) HTTP Fingerprinting
> A tool such as HTTPrint may be able to identify some HTTP devices (the
> current signature set has a few fingerprints that may help such as for
> Cisco-HTTP, etc...).
> Those are all I can think of off the top of my head. Does anyone else
> have any techniques for identifying intermediate proxies, etc...???
> Again, great work with presenting this data. It is certainly an area
> that security professionals need to examine with trying to secure a
> web infrastructure.
> Ryan C. Barnett
> Web Application Security Consortium (WASC) Member
> CIS Apache Benchmark Project Lead
> SANS Instructor: Securing Apache
> GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> On 6/9/05, Amit Klein (AKsecurity) <aksecurity at hotpop.com> wrote:
> > 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 , 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 , p. 4
> > "Special Cases more powerful attacks").
> > 3. Escalation of XSS condition (see ), 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 ).
> > 2. Partial web cache poisoning (through HTTP Request Smuggling see
> > ).
> > 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 , p. 7
> > "Example #4 Request Hijacking").
> > 2. Forceful submission of a request on behalf of a client (see ,
> > p. 9 "Example #5 Request Credential Hijacking").
> > 3. Cross user defacement, if there is an HTTP Response Splitting
> > vulnerability in the web site (see  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  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 ,
> > 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 ,
> > ), 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  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  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
> > ==========
> >  "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 Request Smuggling", Chaim Linhart, Amit Klein, Ronen Heled
> > and Steve Orrin, June 2005
> > http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf
> >  "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
> >  "External Web Application Protection: Impedance Mismatch", Ivan
> > Ristic, March 9, 2005
> > http://www.modsecurity.org/blog/archives/000053.html
> >  "A look at whisker's anti-IDS tactics", Rain Forest Puppy,
> > December 1999
> > http://www.ussrback.com/docs/papers/IDS/whiskerids.html
> > ---------------------------------------------------------------------
> > The Web Security Mailing List
> > http://www.webappsec.org/lists/websecurity/
> > The Web Security Mailing List Archives
> > http://www.webappsec.org/lists/websecurity/archive/
The Web Security Mailing List
The Web Security Mailing List Archives
More information about the websecurity