RE: NTLM HTTP Authentication is insecure by design - a new writeup by Amit Klein

["Cyrill Osterwalder" <cyrill.osterwalder () seclutions com>]

Hi Amit 

> Hope you're not vexed with my follow-ups... Please see below.

Not at all. At some point we might want to move the detailed discussion away
from the list.

> I'm not sure I follow, but anyway, it does seem that in this 
> case, you don't pool the 
> connection to the backend server after all (in your original 
> submission, you said 
> "It is indeed possible to handle NTLM authentication in a 
> reverse proxy and pooling server 
> connections WITHOUT being vulnerable to your described 
> attacks. We are able to do this with 
> our reverse proxy [...]").

This is where it gets detailed I guess ;-) 

Yes, the back-end connections are pooled but the NTLM connections are bound
to a user's session on the reverse proxy server. Basically you can look at it
as a special treatment of NTLM connections through the proxy. The NTLM
authentication handshake will be performed on a back-end connection that is
strictly bound to a session in the first place. Therefore it is not subject
to be mixed with other clients. The reverse proxy server still pools back-end
connections (especially important if using back-end SSL with mutual machine
certificate authentication) for the Web requests. Once the NTLM
authentication is successful the gateway authorizes the session to access the
corresponding resources.

I hope this clarifies my statements. If not, I suggest we exchange a more
detailed discussion off the list or talk on the phone :-) Did you attend
BlackHat? Too bad we did not meet there...

> It does seem to me 
> that they do not address the problem, which is 
> incompatibility in HTTP parsing. Basically, 
> HRS can be used for cache poisoning by sending a seemingly 
> innocent request for a resource 
> (say the root page - "/"), followed by a request for another 
> resource (the poison), e.g. to 
> an application error page, or any other VALID page in the 
> system. The two requests are 
> valid from the URL point of view, so offhandedly I don't see 
> how URL encryption and request 
> assertions would prevent the attack. A more strict parsing 
> will block some of the attacks 
> (not all), but how would looking at the URL do any good?

I understand your point. However, our proxy does not only take the URL into
account. It performs a complete protocol conversion and rebuilding of HTTP
for the outgoing request. The way you are combining requests does not pass
our gateway. This is not achieved by filtering the URL but by completely
analyzing and interpreting the incoming HTTP request on the gateway. The
whole HTTP deconstruction/conversion/rebuilding is the feature that is built
to guarantee clean HTTP to back-end servers at all times.

Without further detailed analysis I cannot 100% guarantee that there is no
HTTP smuggling possible (as already admitted in earlier posts). However,
quite some examples will not pass the gateway I'm sure.

Best regards

Cyrill Osterwalder

Chief Technology Officer
Seclutions AG

http://www.seclutions.com