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

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

On 9 Aug 2005 at 9:08, Cyrill Osterwalder wrote:

> > 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 think I understand. So you say that NTLM connections are, in essence, not pooled. Which 
is good for security, but less good for performance. In other words, an NTLM intensive site 
(think Microsoft Outlook Web Access) will not enjoy the performance benefit of connection 
pooling. Or did I get it wrong? 

> > 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. 

Ah, much better. I didn't understand this from your previous response.
 
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.

The problem of defending against HRS is deeper than what a certain WAF (Web Application 
Firewall) does, it has a lot to do with where the WAF is positioned (with respect to the 
other devices). See my earlier submission to this mailing list, titled "Can HTTP Request 
Smuggling be blocked by Web Application Firewalls?"

http://www.securityfocus.com/archive/107/402974

Basically, a WAF stands a chance of blocking HRS if the attacked devices are behind it. If 
the WAF is located between the devices (e.g. firewall - WAF - web server), then it is less 
likely to stop HRS, and if the devices are somehow in front of the WAF (e.g. two 
proxy/cache servers) then the WAF stands very very little chance of preventing the attack. 
It's not something particular to any WAF, it's just that the concept of "web application" 
stretches beyond the permieter of the organization, and likewise, the concept of web 
application security should follow suit. So whether we like it or not, web application 
security is no longer an issue that is contained (and can be handled) within the IT bounds 
of the organization. I wrote about this earlier to BugTraq, in a submission titled 
"Meanwhile, on the Other Side of the Web Server"

http://www.securityfocus.com/archive/1/401866

Thanks,
-Amit