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

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

Hi Cyrill,

On 19 Jul 2005 at 13:46, Cyrill Osterwalder wrote:

> That is basically correct. But SSL may be vulnerable to the same kind of
> attack in the following scenario that we have seen in reality: A web
> application server uses the SSL session ID to implement the session tracking.
> Some clients connect through a SSL forward proxy that pools outgoing SSL
> sessions. Of course, that is not the proper way to handle SSL in a forward
> proxy. However it can happen in this scenario that other clients jump on
> another SSL (and therefore application) session.

I'm not sure I follow. You say SSL is handled in a *forward* SSL proxy? But that proxy 
typically does *not* have the SSL server side certificate. So if it terminates the SSL 
connection from the client (and establishes a new SSL connection to the server, pooling 
this connection among several clients), then the client will see a nasty certificate 
warning. Do people actually do this?
 
> > *) 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).
>
> We are developing a secure reverse proxy server with a strong focus on
> security AND performance. 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
> (product name is AirLock, technology paper available here:
> http://www.seclutions.com/en/downloads/AirLock_Whitepaper.pdf ) by binding
> the NTLM authentication not only to the TCP connection on the client side but
> also to the secure session management on AirLock. Just for the completeness
> of your request to proxy server vendors I think you should cover this
> possibility as well. By using our method of NTLM authentication through a
> secure reverse proxy you do not make your system vulnerable to this attack,
> even if back-end connections are pooled for performance. 

I suppose you're talking about a scenario wherein AirLock (which is a kind of Web 
Application Firewall - WAF, as far as I understand) sits in front of a web server. Now, 
suppose the root page (/) of the application is protected by NTLM authentication. Client 1 
goes through AirLock, authenticates to the webserver (NTLM) and acquires a session token 
from AirLock. A second client arrives (no session token, since this is his first request), 
requesting the root page (/). Unless AirLock performs the NTLM authentication itself, I 
don't understand (from your description) how it can prevent this request from arriving at 
the web server (and assuming AirLock pools connections, it will do so on the connection of 
the first client).


Also the other two
> attack methods can be prevented using URL protection and filtering
> techniques.

As for HTTP Response Splitting, yes, this can be prevented by WAFs, provided they also look 
at POST requests (whose parameters are found in the body of the HTTP request, rather than 
in the URL).
As for HTTP Request Smuggling, kindly refer to 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

> > 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).
>
> That is a valid request regarding this specific type of attack. However,
> terminating SSL on the Web server (instead of a separate device in front of
> it) introduces many other risks and vulnerabilities. If SSL is terminated on
> the Web server, it is not possible to recognize any other attack methods
> (e.g. application or Web server specific attacks) before they get to the Web
> server. 

I think you mean "block"/"defend", rather than "recognize". There are several passive and 
semi-passive IDS products that can decrypt SSL traffic (given the server's private key, of 
course).

This may be too late! More information on such attack methods and why
> SSL should always be terminated in front of a Web server is illustrated in
> our technology whitepaper already mentioned above:
> (http://www.seclutions.com/en/downloads/AirLock_Whitepaper.pdf).

There's a trade-off, true. It also assumes that the WAF itself isn't vulnerable...

Thanks for your comments and your interest in the writeup,
-Amit