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

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

Hi Cyrill,

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

-Amit

On 20 Jul 2005 at 11:35, Cyrill Osterwalder wrote:

> I understand your remark. AirLock can provide an NTLM proxy in its Login
> Service component. So that would be the "Unless AirLock performs the NTLM
> authentication itself" option of your remark. The NTLM authentication itself
> is not done by AirLock, the Login Service can do "normal" NTLM to the
> back-end NTLM server. Between AirLock as reverse proxy and the NTLM proxy
> component the binding from the TCP connection to the AirLock session is
> implemented. So client to reverse proxy has one TCP connection (must-have so
> the client performs NTLM) and the NTLM proxy component has one TCP connection
> to the back-end NTLM server. The second one however is bound to the user's
> AirLock session an will not be pooled between sessions.

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 [...]").

> I'm aware of the HRS paper and I should admit that HRS cannot be fully
> prevented by an ASG. Depending on the components behind AirLock HRS is
> theoretically possible. However, AirLock provides tools like encrypted URLs
> or signed request assertions to establish a trust association on HTTP
> requests identified and checked by AirLock. Using these tools defeat most HRS
> attempts as far as I can see it but it involves a little integration work, of
> course. 

I am not familiar with the technologies you implemented in your product. 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?