A new issue which tangentially affects Apache... >List-Id: <bugtraq.list-id.securityfocus.com> >Date: Mon, 18 Jul 2005 19:40:32 +0200 >From: "Amit Klein (AKsecurity)" <[EMAIL PROTECTED]> >Subject: NTLM HTTP Authentication is insecure by design - a new writeup by >Amit Klein >To: bugTraq <bugtraq@securityfocus.com> >Message-id: <[EMAIL PROTECTED]> > > NTLM HTTP Authentication > (and possibly other connection-oriented > HTTP authentication and authorization protocols) > is insecure by design
Pointing out a few relevant points of this notice as they apply to the Apache mod_proxy... >This attack is possible because: > >1. Proxy servers share the same TCP connection to the server, among >several clients. This enables several attacks (on top of the one >described here), as discussed in "Meanwhile, on the other side of >the web server". > >I tested this security issue with Microsoft IIS/6.0 (as the web >server that requires NTLM authentication "Integrated Windows >Authentication" in Microsoft's IIS GUI terminology) and Sun >Microsystems Sun Java System Web Proxy 4 (as the proxy server that >shares TCP connections to the same server). > >There are some tricky points in making this attack work: > >1. Microsoft IE 6.0 refuses to conduct NTLM authentication when it >is configured to use a forward proxy. Therefore, the setup used was >with the Sun Proxy as a reverse proxy. > >2. Microsoft IIS/6.0 does not induce the authentication level of a >request to the whole connection, if the HTTP request contains the >Via header. The Sun Proxy server sends this header by default (is >there a way to turn this off?), and so, in order to strip it off, an >Apache 2.0.54 reverse proxy server (with ProxyVia Block directive) >was introduced between the Sun Proxy server and the IIS server. And... >*) The web server (IIS/6.0) must receive a Via-less request. The >Microsoft implementation assumes that the Via header is always sent >by a proxy server, and this is indeed mandated by the HTTP/1.1 RFC >2616 (http://www.ietf.org/rfc/rfc2616.txt), section 14.45: > The Via general-header field MUST be used by gateways and proxies > to indicate the intermediate protocols and recipients between the > user agent and the server on requests [...] >However, it seems that not all servers adhere to this standard. For >example, Apache 2.0.54 mod_proxy does not generate a Via header by >default (see the ProxyVia directive - >http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxyvia, yet >the default httpd.conf file contains a commented-out "ProxyVia On" >directive, so it's possible that many Apache proxy deployments do >send the Via header). That isn't to say that Apache 2.0.54 mod_proxy >facilitates this attack as mentioned above, it does not, because >it does not share the connection to the server among several clients. >Anyway, there are many "anonymous" proxy servers in the Internet, >which deliberately do not send the Via header, ironically with the >intention to increase the privacy of their users. And there are many >other devices and configurations that may remove the Via header if >it exists (in the above example, I introduced the Apache proxy >server to do just that). And finally... >Recommendations >=============== > >*) Proxy vendors do not to share TCP connections to the server >among several clients. Yes, it improves performance, but it's also >insecure and enables/aids 3 different attacks (the one described >here, HTTP Request Smuggling and HTTP Response Splitting). >Also, comply to the RFC and send the HTTP Via request header by >default (Apache Group - please take note). As reverse proxy is never enabled without intent, the impact of Apache on this vector is very low (note that Amit deliberately introduced this into his reproduction case) - but anyone who has intentionally used Apache as a reverse proxy to protect sensitive IIS servers behind their DMZ using NTLM auth is vulnerable (as are users of various NTLM Apache auth modules sitting behind Apache reverse proxies.) My thinking is that rather than 'revealing' the reverse proxy origin server, we should be dumping the auth headers if they are NTLM. Note; this is a public disclosure. Apache's security@ lists did not receive advanced notification of this specific vulnerability. Bill
