Re: [Full-disclosure] NTLM HTTP Authentication is insecure by design - a new writeup by Amit Klein

From: 3APA3A (3APA3A_at_SECURITY.NNOV.RU)
Date: 07/19/05

  • Next message: Mike Hoye: "Re: [Full-disclosure] Advice RE Site Exploit" 
    Date: Tue, 19 Jul 2005 13:13:03 +0400
To: "Amit Klein (AKsecurity)" <aksecurity@hotpop.com>

    Dear Amit Klein (AKsecurity),

     NTLM authentication is insecure by design for external authentication,
     because of "single signon" ideology. NTLM authentication can be used
     for NTLM proxy attack. For example, attacker who can hijack or spoof
     server connection with NTLM authentication can use this connection to
     access different Web server, mail server or file server with client's
     privileges. This is known for many years and was discussed for many
     times. Internet Explorer uses NTLM authentication by default only for
     local network zone. Local network zone (by default) are hosts with
     NetBIOS names (for exampel WEBSRV), this hosts are excluded from proxy
     by dafault, and exclusion list for proxy is also part of local network.
     So, in default configuration, NTLM will never be used through proxy
     server.

    --Monday, July 18, 2005, 9:43:02 PM, you wrote to full-disclosure@lists.grok.org.uk:

    AKA> NTLM HTTP Authentication
    AKA> (and possibly other connection-oriented
    AKA> HTTP authentication and authorization protocols)
    AKA> is insecure by design

    AKA> Or

    AKA> NTLM Authentication and HTTP proxies
    AKA> don't mix

    AKA> Amit Klein, July 2005

    AKA> Introduction
    AKA> ============

    AKA> In "Meanwhile on the other side of the webserver"
    AKA> (http://www.securityfocus.com/archive/1/401866) I surveyed some
    AKA> possible attacks against a scenario wherein a proxy server is
    AKA> positioned in front of a web server, and that proxy server shares a
    AKA> single TCP connection to the server among several clients. In that
    AKA> write-up, I mentioned several problems related to HTTP Request
    AKA> Smuggling
    AKA> (http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf) and
    AKA> HTTP Response Splitting
    AKA> (http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf). These
    AKA> are attacks that make use of non-RFC HTTP requests (HTTP Request
    AKA> Smuggling) or inject unexpected data (CRLF) through the application
    AKA> into the HTTP response stream (HTTP Response Splitting). In contrast,
    AKA> this write-up discusses a completely different problem, one which is
    AKA> inherent to the situation of a connection-oriented authentication/
    AKA> authorization protocol (e.g. NTLM authentication) used with a proxy
    AKA> server that shares TCP connections among several clients. Exploiting
    AKA> this vulnerability can be performed with 100% RFC compliant HTTP
    AKA> requests, and without attacking the application (i.e. without sending
    AKA> malicious data to the application).

    AKA> Theory
    AKA> ======

    AKA> In connection oriented security, the authentication is associated
    AKA> with the TCP connection, rather than to the individual HTTP requests
    AKA> it transports. As a result, a proxy server that shares a TCP
    AKA> connection to the server among 2 clients may jeopardize the security
    AKA> of the web application by sending a first request (or a set of
    AKA> requests) with authentication/authorization credentials from the
    AKA> first client, followed by a request with no credentials from the
    AKA> second client, and have the web server associate the privileges of
    AKA> the first request with the second request.

    AKA> NTLM authentication is an example to such connection-oriented
    AKA> security scheme.
    >>From http://curl.haxx.se/rfc/ntlm.html#ntlmHttpAuthentication
    AKA> (lacking official Microsoft specification, this resource is one of
    AKA> the most comprehensive descriptions of NTLM authentication):

    AKA> This [HTTP NTLM authentication] scheme differs from most "normal"
    AKA> HTTP authentication mechanisms, in that subsequent requests over
    AKA> the authenticated connection are not themselves authenticated;
    AKA> NTLM is connection-oriented, rather than request-oriented. So a
    AKA> second request for "/index.html" would not carry any
    AKA> authentication information, and the server would request none.

    AKA> This attack is possible because:

    AKA> 1. Proxy servers share the same TCP connection to the server, among
    AKA> several clients. This enables several attacks (on top of the one
    AKA> described here), as discussed in "Meanwhile, on the other side of
    AKA> the web server".

    AKA> 2. Connection-oriented security is an insecure concept because
    AKA> there's no guarantee in the HTTP RFC that a single connection will
    AKA> be used by a single entity. As can be seen, this simply doesn't
    AKA> hold. Note that SSL is not connection-oriented security since each
    AKA> request is encrypted with a secret, shared key, making this protocol
    AKA> implicitly request-oriented.

    AKA> Results
    AKA> =======

    AKA> I tested this security issue with Microsoft IIS/6.0 (as the web
    AKA> server that requires NTLM authentication – "Integrated Windows
    AKA> Authentication" in Microsoft's IIS GUI terminology) and Sun
    AKA> Microsystems Sun Java System Web Proxy 4 (as the proxy server that
    AKA> shares TCP connections to the same server).

    AKA> There are some tricky points in making this attack work:

    AKA> 1. Microsoft IE 6.0 refuses to conduct NTLM authentication when it
    AKA> is configured to use a forward proxy. Therefore, the setup used was
    AKA> with the Sun Proxy as a reverse proxy.

    AKA> 2. Microsoft IIS/6.0 does not induce the authentication level of a
    AKA> request to the whole connection, if the HTTP request contains the
    AKA> Via header. The Sun Proxy server sends this header by default (is
    AKA> there a way to turn this off?), and so, in order to strip it off, an
    AKA> Apache 2.0.54 reverse proxy server (with ProxyVia Block directive)
    AKA> was introduced between the Sun Proxy server and the IIS server.

    AKA> After these tweaks, both IE 6.0 and Mozilla 1.4 were used to
    AKA> demonstrate the attack:

    AKA> In the first step, a browser was used to authenticate to the IIS/6.0
    AKA> (through the Sun Proxy and the Apache proxy). The authentication was
    AKA> done in NTLM. Since the Apache proxy removed the Via header, the
    AKA> IIS/6.0 induced the authentication credentials on the whole TCP
    AKA> connection.

    AKA> In the second step, a different client was used to access a
    AKA> restricted resource on the IIS/6.0 through the Sun proxy (and the
    AKA> Apache proxy). The Sun Proxy used the same TCP connection to the
    AKA> Apache as it used for the first request, and likewise, the Apache
    AKA> used the same connection to the IIS/6.0 as it used for the first
    AKA> request, and therefore the credentials of the first request were
    AKA> successfully induced onto the second request, although it arrived
    AKA> from a different client on a different TCP connection (from the
    AKA> client to the Sun Proxy).

    AKA> Scope of the attack
    AKA> ===================

    AKA> *) Not all proxy servers honor NTLM authentication. Squid, for one,
    AKA> deliberately doesn't support NTLM
    AKA> (http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.14). Indeed,
    AKA> Squid seems to strip off the WWW-Authenticate header if it contains
    AKA> NTLM or Negotiate, thereby effectively disabling NTLM authentication
    AKA> between the client and the web server. But as mentioned above, there
    AKA> are some proxy servers that do support NTLM authentication, such as
    AKA> Sun Proxy 4.

    AKA> *) Not all proxy servers share TCP connection to the server. Many
    AKA> do,some don't (e.g. Apache 2.0 mod_proxy).

    AKA> *) If IE is to be tricked, then it mustn't be configured with a
    AKA> forward proxy server. That means that the attack is effective for IE
    AKA> (only) with transparent proxy servers (such as ones used by many
    AKA> ISPs), and reverse proxy servers (as demonstrated above). The
    AKA> Mozilla browser has no such inhibitions, and therefore, a Mozilla
    AKA> shop (e.g. some universities and open source organizations) may be
    AKA> more vulnerable.

    AKA> *) The web server (IIS/6.0) must receive a Via-less request. The
    AKA> Microsoft implementation assumes that the Via header is always sent
    AKA> by a proxy server, and this is indeed mandated by the HTTP/1.1 RFC
    AKA> 2616 (http://www.ietf.org/rfc/rfc2616.txt), section 14.45:
    AKA> The Via general-header field MUST be used by gateways and proxies
    AKA> to indicate the intermediate protocols and recipients between the
    AKA> user agent and the server on requests [...]
    AKA> However, it seems that not all servers adhere to this standard. For
    AKA> example, Apache 2.0.54 mod_proxy does not generate a Via header by
    AKA> default (see the ProxyVia directive -
    AKA> http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxyvia, yet
    AKA> the default httpd.conf file contains a commented-out "ProxyVia On"
    AKA> directive, so it's possible that many Apache proxy deployments do
    AKA> send the Via header). That isn't to say that Apache 2.0.54 mod_proxy
    AKA> facilitates this attack – as mentioned above, it does not, because
    AKA> it does not share the connection to the server among several clients.
    AKA> Anyway, there are many "anonymous" proxy servers in the Internet,
    AKA> which deliberately do not send the Via header, ironically with the
    AKA> intention to increase the privacy of their users. And there are many
    AKA> other devices and configurations that may remove the Via header if
    AKA> it exists (in the above example, I introduced the Apache proxy
    AKA> server to do just that).

    AKA> *) Last but not least - NTLM authentication should be used, and over
    AKA> HTTP (not over HTTPS). This is the default configuration of
    AKA> Microsoft Outlook Web Access 2000/2003.

    AKA> Recommendations
    AKA> ===============

    AKA> *) Proxy vendors – do not to share TCP connections to the server
    AKA> among several clients. Yes, it improves performance, but it's also
    AKA> insecure and enables/aids 3 different attacks (the one described
    AKA> here, HTTP Request Smuggling and HTTP Response Splitting).
    AKA> Also, comply to the RFC and send the HTTP Via request header by
    AKA> default (Apache Group - please take note).

    AKA> *) Designers of protocols past, present and future – do not rely on
    AKA> TCP connection being used by a single logical entity. As a special
    AKA> case, NTLM should be withdrawn or redesigned (OK, this won't
    AKA> happen...). Also, do not rely on the Via header (or any other
    AKA> header) to indicate that the client is a proxy server. Design the
    AKA> protocol such that it will be indifferent to whether the client is a
    AKA> proxy server or a browser.

    AKA> *) Site owners – abandon NTLM authentication in favor of other
    AKA> authentication/authorization options (e.g. HTTP digest
    AKA> authentication – see RFC 2617 –
    AKA> http://www.ietf.org/rfc/rfc2617.txt).
    AKA> Alternatively, use NTLM over HTTPS (SSL) to avoid this
    AKA> vulnerability, but make sure that the SSL is terminated on the web
    AKA> server, not some SSL accelerator (which may in itself facilitate the
    AKA> attack, e.g. if it shares a TCP connection to the server among
    AKA> several clients).
    AKA> Another alternative is to configure the web server not to use
    AKA> persistent HTTP connections for resources that are protected by NTLM
    AKA> autnehtication.

    AKA> *) Proxy owners – in order to protect your clients and your clients'
    AKA> privacy: do not turn off generating the "Via" HTTP request header by
    AKA> the proxy server. True, it indicates that the request comes from a
    AKA> proxy server, but in the case of NTLM authentication, it increases
    AKA> the likelihood of the client not to be subject to the attack
    AKA> described here. If possible, turn off TCP connection sharing in your
    AKA> proxy server. If none of this is possible, consider actively
    AKA> disrupting NTLM authentication, in order to force your clients to
    AKA> use other (hopefully more secure) authentication methods.

    AKA> A note about detection/prevention
    AKA> =================================

    AKA> Since the attacker's request is practically identical to the request
    AKA> sent by the authenticated user, it's quite a problem for an external
    AKA> product (such as IDS/IPS/WAF) to detect this attack.

    AKA> Of course, if the IDS/IPS/WAF is between the web-server and the proxy,
    AKA> it stands very little chance to detect that something's wrong, since
    AKA> the attacker's request is practically identical to the valid user's
    AKA> requests. However, it can block the attack simply by (gracefully, if
    AKA> possible) closing the TCP connection after a successful response (i.e.
    AKA> not 401) for a request containing NTLM authentication.

    AKA> If the proxy server is on site, and the IDS/IPS/WAF is in front
    AKA> of it, then protection becomes harder – the IDS/IPS/WAF would have to
    AKA> replace the NTLM authentication of the server with its own, and
    AKA> practically replicate the logic from the web-server to itself, in
    AKA> order to ensure that a request without credentials is made only to a
    AKA> resource which is public.

    AKA> It's also not too trivial to automatically scan for this kind of
    AKA> vulnerability. A scanner would have to be positioned in front of the
    AKA> proxy server (which may be away from the site), and would have to
    AKA> simulate the attack using two TCP connections.

    AKA> A note about basic authentication in IIS/5.0
    AKA> ============================================

    AKA> If memory serves, and peculiarly enough, awhile ago Ronen Heled,
    AKA> Chaim Linhart and me bumped into an implementation quirk of IIS/5.0
    AKA> wherein HTTP basic authentication seems to be also connection
    AKA> oriented, that is, if the TCP connection had already transmitted an
    AKA> HTTP request with valid Authorization header, the credentials are
    AKA> used for the next requests (on this TCP connection) even if these do
    AKA> not contain the Authorization header. Here too, the presence of the
    AKA> Via HTTP request header turns off the connection-orientedness.
    AKA> Again – this is something we noted awhile ago as a byproduct of a
    AKA> research in a different direction, and since I have no solid
    AKA> evidence, I am reluctant to point at it as a vulnerability. If
    AKA> someone can verify this on IIS/5.0 (I didn't manage to replicate it
    AKA> on IIS/6.0), please step foreward...
    AKA> _______________________________________________
    AKA> Full-Disclosure - We believe in it.
    AKA> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
    AKA> Hosted and sponsored by Secunia - http://secunia.com/ 

    -- 
~/ZARAZA
Íåïðèÿòíîñòè íà÷íóòñÿ â âîñåìü.  (Òâåí)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
  • Next message: Mike Hoye: "Re: [Full-disclosure] Advice RE Site Exploit"

    Relevant Pages