Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll

Hi Gregg,

Sounds like I had the same issue as Jason. The problem isn't with the
owalogon.asp page which your link references. The problem in owalogon.asp
can be fixed by hard-coding the redirect to your server external IP/domain
name, but the issue with McAfee remains as they have picked up on owaauth.dll
which actually does the redirecting (behind the scene's of owalogon.asp and
logon.asp) and can be accessed directly from the internet of an OWA server.

Using FBA does resolve the issue but the way OWA uses cookies to manage
security is IMO better than using FBA so you are losing functionality in
enabling FBA.

Jason, McAfee (or Hackersafe as they used to be) said to me that they can't
change the classification on the vulnerability because they are guidelines
from PCI which categorises it as level 3 high. Trying to get anything from
PCI is virtually impossible.

Regards

Chris


"Gregg Hill" wrote:

Yikes!

From what I read, killing OWA also kills ActiveSync and Outlook RPC over
HTTP. I don't know why, but supposedly it does.

From your post, I assume you do not use Forms Based Authentication, and I am
curious what happens if you do attempt just the URL redirect noted below.

Gregg Hill



"Jason" <not@xxxxxxxx> wrote in message
news:d1a3f41b1d10e8caba1bbda94926@xxxxxxxxxxxxxxxxxxxxx
I tried the fix you mentioned below but it does not work in our case. This
is because the McAfee ScanAlert PCI scanner uses a form builder that is
directly POSTing to https://<myserver>/exchweb/bin/auth/owaauth.dll using,
among others, a parameter 'destination' pointing to the redirected URL. So
changing logon.asp does nothing in that case since this exploit is directly
hitting owaauth.dll.

Based on what I've read here and the link posted by Chris, there appears
to be no fix except to restrict by IP. In my case I'll just turn off OWA
since nobody is using it currently. That's a luxury that other companies
can't afford.

At this poing I'm appealing to ScanAlert to mark this as a false positive
as I read that others had success with that route.
Hello!

What happens if you make up your own redirect and test it against your
client's server?

Thinking that I actually understand the exploit, I did this test:

https://mail.mySBSserver.net/exchweb/bin/auth/owalogon.asp?url=http://
www.yahoo.com

I expected it to end up at www.yahoo.com, but it just went to my OWA
on my server.

I have Forms Based Authentication enabled on my SBS and on my clients'
systems, and attempting to use the exploit does NOT redirect. It goes
to OWA on the appropriate servers.

I also found this workaround in a Google search.

http://osvdb.org/show/osvdb/13621

Does that help?

Gregg Hill

"Chris" <Chris@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@xxxxxxxxxxxxxxxx

Hi,
I had the same issue with the same company a few months ago. I
didn't
resolve it either even after a support case with microsoft. Their
verdict
was that the file was doing it's job and was not a vulnerability.
The
only
technical soltuions are to disable OWA or use Forms Based
Authentication
but
the latter is not a good solution.
I opened a forum post when I had the issue:
http://forums.microsoft.com/TechNet/showpost.aspx?postid=3304653&site
id=17
Otherwise, maybe move SQL databases (assuming SBS Premium) to another
server
and this can help with PCI, however, strictly speaking (4.2 I think)
says
you
can't have multiple roles on the server which kinda rules out SBS
anyway!!!
Hope you have more success.
Regards
"Jason" wrote:

We recently migrated to SBS 2003 and over the weekend we ran our
McAfee
ScanAlert
PCI compliance scan on the server. The scan picked up the "User
specified
URL redirection (Open Redirect)" vulnerability in OWA which I'm sure
some
of you know about. Details on it are here
http://www.exploitlabs.com/files/advisories/EXPL-A-2005-001-owa.txt.
I'm very worried since this has been reported since 2005 and there
appears
to be no fix. As a retail company we must maintain PCI compliance.
This
vulnerability
is a level 3 (HIGH) and must be fixed by next quarter or we will
fail PCI
compliance and face potentially huge fines. Does anyone know of a
fix to
this issue?
I was thinking we could rename the exchweb path to something obscure
but that does not appear to be an option.






.

Relevant Pages

  • Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
    ... When you say that using FBA resolves the ... can be fixed by hard-coding the redirect to your server external IP/domain ... Using FBA does resolve the issue but the way OWA uses cookies to manage ...
    (microsoft.public.windows.server.sbs)
  • Re: problem with OWA redirection Exch 2k7
    ... This is loaded on Win2k3 server and I allow SSL ... through the firewall to this exchange 2007 server for OWA, ... The problem is when I implement the first proceedure listed, the redirect ...
    (microsoft.public.exchange.admin)
  • Re: Urgent! OWA /Exchange redirect problem
    ... it looks like the redirect rule is still missing ... authentication" is enabled on the OWA listener. ... The ISA server is a unihome setup as a standalone server, ... internal server name: internalserver ...
    (microsoft.public.isa.configuration)
  • Re: OWA could not access email after moving mailbox
    ... IIS doesn't redirect persay - it accesses DS on 5.5 Server A via RPC calls ... > access through OWA. ... > OWA giges the message "unable to get in Mailbox". ...
    (microsoft.public.exchange.admin)
  • Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
    ... This is because the McAfee ScanAlert PCI scanner uses a form builder that is directly ... Based on what I've read here and the link posted by Chris, there appears to be no fix except to restrict by IP. ... In my case I'll just turn off OWA since nobody is using it currently. ... on my server. ...
    (microsoft.public.windows.server.sbs)