Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
- From: Jason <not@xxxxxxxx>
- Date: Tue, 22 Jul 2008 21:09:50 +0000 (UTC)
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.
.
- Follow-Ups:
- Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
- From: Gregg Hill
- Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
- References:
- Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
- From: Gregg Hill
- Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
- Prev by Date: OWA works from client but not from server
- Next by Date: Re: Open TCP/UDP Ports
- Previous by thread: Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
- Next by thread: Re: Fixing URL redirect exploit at /exchweb/bin/auth/owaauth.dll
- Index(es):
Relevant Pages
|
