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.
