RE: Microsoft Security Bulletin MS01-047

From: Mark Parry (Mark@psi-cu-software.com)
Date: 09/10/01


From: "Mark Parry" <Mark@psi-cu-software.com>
To: <craig@wmhza.gank.org>, <focus-ms@securityfocus.com>
Subject: RE: Microsoft Security Bulletin MS01-047
Date: Mon, 10 Sep 2001 08:55:15 -0600
Message-ID: <000301c13a08$9a6a4650$dc00a8c0@psicusoftware.com>

as long as we're reviewing situations that are going to make exchange code
not a problem...

I'm running my Exchange OWA with IIS authentication, so if you don't have
domain credentials, you never even access that possibly buggy OWA code. I'm
running my OWA over SSL only, which is why I'm okay with using domain
credentials... Also, I have turned on Account lockout polices for a certain
amount of tries on the accounts to stop brute forcing the accounts.

This is my suggestion for others where OWA is required. Any suggestions and
comments are welcome.

Thanks,
Mark

-----Original Message-----
From: Craig Boston [mailto:craig@wmhza.gank.org]
Sent: Friday, September 07, 2001 1:56 PM
To: H D Moore
Cc: bugtraq@securityfocus.com
Subject: Re: Microsoft Security Bulletin MS01-047

On Thu, 6 Sep 2001 19:54:58 -0500 H D Moore <hdm@secureaustin.com> wrote:

> I thought this was a feature ;)
>
> To dump the complete GAL:
> http://exchangesvr/exchange/finduser/fumsg.asp

I tried this on my 5.5 SP4 server with OWA. I replaced http with https as
I have IIS configured to only allow encrypted access to the /exchange tree
and got redirected back to the logon screen since I didn't have a session
cookie.

> If you get redirected back to the logon page immediately, it means that
you
> must establish a session with your browser first. To do that, just browse
to:
>
> http://exchangesvr/exchange/LogonFrm.asp?mailbox=&isnewwindow=0

This request gets me a blank page with a javascript popup saying "This page
has been disabled, please see your administrator." I got an ASPSESSIONID
cookie, however the first URL still redirects me back to the logon page. I
encountered similar results with Aviram Jenik's method.

My guess is this is because I have disabled anonymous access to public
folders. I'm not 100% sure but it would appear at first glance that this
provides some protection against the GAL enumeration exploit.

Exchange Administrator, Site/Configuration/Protocols/HTTP and uncheck both
boxes about anonymous access. Probably a good idea anyway if you have no
public folders that need to be accessed anonymously.

--
Craig Boston, CCNA
Network Administrator
Owen Oil Tools, Inc.