You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/07/18 21:30:20 UTC
Fwd: NTLM HTTP Authentication is insecure by design - a new
writeup by Amit Klein
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)" <ak...@hotpop.com>
>Subject: NTLM HTTP Authentication is insecure by design - a new writeup by Amit Klein
>To: bugTraq <bu...@securityfocus.com>
>Message-id: <42...@localhost>
>
> 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
Re: NTLM HTTP Authentication is insecure by design - a new
writeup by Amit Klein
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:57 AM 7/19/2005, Roy T. Fielding wrote:
>On Jul 18, 2005, at 12:30 PM, William A. Rowe, Jr. wrote:
>>> NTLM HTTP Authentication
>>> (and possibly other connection-oriented
>>> HTTP authentication and authorization protocols)
>>> is insecure by design
>
>Yep, no shit -- that's what the Microsoft fools were told when
>they introduced it.
That doesn't surprise me :)
>>>*) 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 [...]
>
>Yep.
>
>>>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
>
>WTF? That's a bug.
I'd say. The question is; what's the fix?
Today's syntax is ProxyVia on|off|full|block
The default is off, which is clearly invalid.
A default of full might be overkill, default of on
should be sufficient
Are ProxyVia off and ProxyVia block invalid?
Technically, it's pretty clear that they are.
Realistically, if someone wants an invisible proxy, I guess
that's up to them, but then again it's their own damned fault
if they trip over something like this. But we don't give them
much choice today, I don't think...
The 14.45 Via section defines a pretty clear acceptable flavor,
[...] The
received-by field is normally the host and optional port number of a
recipient server or client that subsequently forwarded the message.
However, if the real host is considered to be sensitive information,
it MAY be replaced by a pseudonym. If the port is not given, it MAY
be assumed to be the default port of the received-protocol.
Sooo... a new alternative, "ProxyVia alias shortname" would seem sane,
and a much better choice for most reverse proxies.
For organizations that have strong privacy requirements for hiding
internal structures, a proxy MAY combine an ordered subsequence of
Via header field entries with identical received-protocol values into
a single such entry. For example,
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Applications SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been
replaced by pseudonyms. Applications MUST NOT combine entries which
have different received-protocol values.
Sooo... "ProxyVia collapse shortname" would be an even terser flavor,
and I can't see a case where we would keep the truename of this via
server while collapsing the rest.
Thoughts?
Bill
Re: NTLM HTTP Authentication is insecure by design - a new writeup by Amit Klein
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 18, 2005, at 12:30 PM, William A. Rowe, Jr. wrote:
>> NTLM HTTP Authentication
>> (and possibly other connection-oriented
>> HTTP authentication and authorization protocols)
>> is insecure by design
Yep, no shit -- that's what the Microsoft fools were told when
they introduced it.
>> *) 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 [...]
Yep.
>> 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
WTF? That's a bug.
>> *) 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.)
We don't really need to get in between their gun and their foot.
> My thinking is that rather than 'revealing' the reverse proxy
> origin server, we should be dumping the auth headers if they are
> NTLM.
I don't think that will work from the browser's perspective.
I would just mark the connection as being in use by a single
client and remove it when the client closes.
....Roy