|
WebApp Sec
mailing list archives
Re: NTLM and man-in-the-middle proxies not working
From: "Amit Klein (AKsecurity)" <aksecurity () hotpop com>
Date: Thu, 15 Sep 2005 08:38:07 +0200
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.
By Date
By Thread
Current thread:
|