[REVS] Meanwhile - On the Other Side of the Web Server
SecuriTeam <[email protected]>
| Newsgroups | gmane.comp.security.securiteam |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]> 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: [email protected] In order to subscribe to the mailing list, simply forward this email to: [email protected] ==================== ==================== 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.