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
- - - - - - - - -
NTLM HTTP Authentication is Insecure By Design
------------------------------------------------------------------------
SUMMARY
In "Meanwhile on the other side of the webserver" Amit surveyed some
possible attacks against a scenario wherein a proxy server is positioned
in front of a web server, and that proxy server shares a single TCP
connection to the server among several clients. In that write-up, Amit
mentioned several problems related to HTTP Request Smuggling (
<http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf>
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf) and HTTP
Response Splitting (
<http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf>
http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf).
These are attacks that make use of non-RFC HTTP requests (HTTP Request
Smuggling) or inject unexpected data (CRLF) through the application into
the HTTP response stream (HTTP Response Splitting). In contrast, this
write-up discusses a completely different problem, one which is inherent
to the situation of a connection-oriented authentication/authorization
protocol (e.g. NTLM authentication) used with a proxy server that shares
TCP connections among several clients. Exploiting this vulnerability can
be performed with 100% RFC compliant HTTP requests, and without attacking
the application (i.e. without sending malicious data to the application).
DETAILS
Theory
In connection oriented security, the authentication is associated with the
TCP connection, rather than to the individual HTTP requests it transports.
As a result, a proxy server that shares a TCP connection to the server
among 2 clients may jeopardize the security of the web application by
sending a first request (or a set of requests) with authentication /
authorization credentials from the first client, followed by a request
with no credentials from the second client, and have the web server
associate the privileges of the first request with the second request.
NTLM authentication is an example to such connection-oriented security
scheme.
From <http://curl.haxx.se/rfc/ntlm.html#ntlmHttpAuthentication>
http://curl.haxx.se/rfc/ntlm.html#ntlmHttpAuthentication (lacking official
Microsoft specification, this resource is one of the most comprehensive
descriptions of NTLM authentication):
This [HTTP NTLM authentication] scheme differs from most "normal" HTTP
authentication mechanisms, in that subsequent requests over the
authenticated connection are not themselves authenticated; NTLM is
connection-oriented, rather than request-oriented. So a second request for
"/index.html" would not carry any authentication information, and the
server would request none.
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".
2. Connection-oriented security is an insecure concept because there's no
guarantee in the HTTP RFC that a single connection will be used by a
single entity. As can be seen, this simply doesn't hold. Note that SSL is
not connection-oriented security since each request is encrypted with a
secret, shared key, making this protocol implicitly request-oriented.
Results:
Amit 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.
After these tweaks, both IE 6.0 and Mozilla 1.4 were used to demonstrate
the attack:
* In the first step, a browser was used to authenticate to the IIS/6.0
(through the Sun Proxy and the Apache proxy). The authentication was done
in NTLM. Since the Apache proxy removed the Via header, the IIS/6.0
induced the authentication credentials on the whole TCP connection.
* In the second step, a different client was used to access a restricted
resource on the IIS/6.0 through the Sun proxy (and the Apache proxy). The
Sun Proxy used the same TCP connection to the Apache as it used for the
first request, and likewise, the Apache used the same connection to the
IIS/6.0 as it used for the first request, and therefore the credentials of
the first request were successfully induced onto the second request,
although it arrived from a different client on a different TCP connection
(from the client to the Sun Proxy).
Scope of the attack:
* Not all proxy servers honor NTLM authentication. Squid, for one,
deliberately doesn't support NTLM (
<http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.14>
http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.14). Indeed, Squid
seems to strip off the WWW-Authenticate header if it contains NTLM or
Negotiate, thereby effectively disabling NTLM authentication between the
client and the web server. But as mentioned above, there are some proxy
servers that do support NTLM authentication, such as Sun Proxy 4.
* Not all proxy servers share TCP connection to the server. Many do,some
don't (e.g. Apache 2.0 mod_proxy).
* If IE is to be tricked, then it mustn't be configured with a forward
proxy server. That means that the attack is effective for IE (only) with
transparent proxy servers (such as ones used by many ISPs), and reverse
proxy servers (as demonstrated above). The Mozilla browser has no such
inhibitions, and therefore, a Mozilla shop (e.g. some universities and
open source organizations) may be more vulnerable.
* 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>
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>
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, Amit introduced the Apache proxy server to do just that).
* Last but not least - NTLM authentication should be used, and over HTTP
(not over HTTPS). This is the default configuration of Microsoft Outlook
Web Access 2000/2003.
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).
* Designers of protocols past, present and future - do not rely on TCP
connection being used by a single logical entity. As a special case, NTLM
should be withdrawn or redesigned (OK, this won't happen...). Also, do not
rely on the Via header (or any other header) to indicate that the client
is a proxy server. Design the protocol such that it will be indifferent to
whether the client is a proxy server or a browser.
* Site owners - abandon NTLM authentication in favor of other
authentication/authorization options (e.g. HTTP digest authentication -
see RFC 2617 -
<http://www.ietf.org/rfc/rfc2617.txt>
http://www.ietf.org/rfc/rfc2617.txt).
Alternatively, use NTLM over HTTPS (SSL) to avoid this vulnerability, but
make sure that the SSL is terminated on the web server, not some SSL
accelerator (which may in itself facilitate the attack, e.g. if it shares
a TCP connection to the server among several clients). Another alternative
is to configure the web server not to use persistent HTTP connections for
resources that are protected by NTLM authentication.
* Proxy owners - in order to protect your clients and your clients'
privacy: do not turn off generating the "Via" HTTP request header by the
proxy server. True, it indicates that the request comes from a proxy
server, but in the case of NTLM authentication, it increases the
likelihood of the client not to be subject to the attack described here.
If possible, turn off TCP connection sharing in your proxy server. If none
of this is possible, consider actively disrupting NTLM authentication, in
order to force your clients to use other (hopefully more secure)
authentication methods.
A note about detection/prevention:
Since the attacker's request is practically identical to the request sent
by the authenticated user, it's quite a problem for an external product
(such as IDS/IPS/WAF) to detect this attack.
Of course, if the IDS/IPS/WAF is between the web-server and the proxy, it
stands very little chance to detect that somethings wrong, since the
attacker's request is practically identical to the valid user's requests.
However, it can block the attack simply by (gracefully, if possible)
closing the TCP connection after a successful response (i.e. not 401) for
a request containing NTLM authentication.
If the proxy server is on site, and the IDS/IPS/WAF is in front of it,
then protection becomes harder - the IDS/IPS/WAF would have to replace the
NTLM authentication of the server with its own, and practically replicate
the logic from the web-server to itself, in order to ensure that a request
without credentials is made only to a resource which is public.
It's also not too trivial to automatically scan for this kind of
vulnerability. A scanner would have to be positioned in front of the proxy
server (which may be away from the site), and would have to simulate the
attack using two TCP connections.
A note about basic authentication in IIS/5.0:
If memory serves, and peculiarly enough, awhile ago Ronen Heled, Chaim
Linhart and me bumped into an implementation quirk of IIS/5.0 wherein HTTP
basic authentication seems to be also connection oriented, that is, if the
TCP connection had already transmitted an HTTP request with valid
Authorization header, the credentials are used for the next requests (on
this TCP connection) even if these do not contain the Authorization
header. Here too, the presence of the Via HTTP request header turns off
the connection-orientedness.
Again - this is something we noted awhile ago as a byproduct of a research
in a different direction, and since Amit has no solid evidence, his is
reluctant to point at it as a vulnerability. If someone can verify this on
IIS/5.0 (Amit didn't manage to replicate it on IIS/6.0), please step
forward.
ADDITIONAL INFORMATION
The information has been provided by <mailto:aksecurity@hotpop.com> 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:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
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.
