Re: NTLM and man-in-the-middle proxies not working

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

On 14 Sep 2005 at 18:41, raymond_b_jimenez () yahoo com wrote:

> While doing an application evaluation using  man-in-the-midle proxies (Odysseus, then Paros, Achilles) I've found an 
> internal site that doesn't work. Since it seems to be independent of the proxies used and really protects the 
> aplication from fuzzing with parameters, it seems appropriate to seek help here.
>
> Normal Scenario is the following:
> -IIS6 servers with IWA
> -Application validates users through IWA
>
> Internal Browser configured with man-in-the-middle proxy scenario is:
> -Access to the site gives an 401 HTTP error, which also occurs above, but here IWA information is not sent by the 
> browser
> -No object is visible on the site
> -HTTP Headers and code are the same in both circunstances
> -Advanced Internet Options in IE were explored, with no result, including "Use HTTP/1.1 through proxy connections" 
> and "Enable Integrated Windows AUthentication"
> -Changing Security zones in IE were also tried, but also with no result
>
> External Browser configured with man-in-the-middle proxy scenario is:
> -Access to the application is possible, after authentication information is inserted
> -Application denies access to the same user that works in the normal scenario
> -GIF objects are visible though

It's a bit unclear to me what "external brwoser" vs. "internal browser" are. 

Anyway, I think I know why a browser may fail to do IWA through a forward proxy server - 
that is, if this browser happens to be IE. As I mentioned in an earlier submission to this 
list ("NTLM HTTP Authentication is insecure by design" - 
http://www.securityfocus.com/archive/107/405587), IE doesn't send IWA (NTLM) credentials if 
it is configured to use a proxy. Under "Scope of the attack" you can find the following 
text:
*) If IE is to be tricked, then it mustn't be configured with a
forward proxy server. That means that the attack is effective for IE
(only) with transparent proxy servers (such as ones used by many
ISPs), and reverse proxy servers (as demonstrated above). The
Mozilla browser has no such inhibitions, and therefore, a Mozilla
shop (e.g. some universities and open source organizations) may be
more vulnerable.