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

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/adv...05-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.

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/...4653&siteid=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/adv...05-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.
>
>
>

I thought Forms Based Authentication was the default in SBS. Why would you
think it is not a good solution?

Gregg Hill



"Chris" <Chris@discussions.microsoft.com> wrote in message
news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
> 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/...4653&siteid=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/adv...05-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.
>>
>>
>>

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.../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@discussions.microsoft.com> wrote in message
news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
> 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/...4653&siteid=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/adv...05-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.
>>
>>
>>

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...sp?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@discussions.microsoft.com> wrote in message
> news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
>
>> 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/...d=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/adv...05-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.
>>>

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@here.com> wrote in message
news:d1a3f41b1d10e8caba1bbda94926@news.microsoft.com...
>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...sp?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@discussions.microsoft.com> wrote in message
>> news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
>>
>>> 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/...d=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/adv...05-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.
>>>>
>
>

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@here.com> wrote in message
> news:d1a3f41b1d10e8caba1bbda94926@news.microsoft.com...
> >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...sp?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@discussions.microsoft.com> wrote in message
> >> news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
> >>
> >>> 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/...d=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/adv...05-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.
> >>>>
> >
> >
>
>
>

Chris,

Thank you for the information. When you say that using FBA resolves the
problem, do you mean that if you have FBA enabled, the exploit cannot be
used?

I do not know what loss of functionality you mean in reference to using FBA.

Gregg Hill


"Chris" <Chris@discussions.microsoft.com> wrote in message
news:AE5BCC4C-3A1B-43D3-8667-2E9C54736F0E@microsoft.com...
> 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@here.com> wrote in message
>> news:d1a3f41b1d10e8caba1bbda94926@news.microsoft.com...
>> >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...sp?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@discussions.microsoft.com> wrote in message
>> >> news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
>> >>
>> >>> 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/...d=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/adv...05-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.
>> >>>>
>> >
>> >
>>
>>
>>

Hi Gregg,

Don't know what I was thinking when I wrote that bit...sorry!

By disabling FBA the vulnerability is resolved and the owaauth.dll file is
not directly accessible from the internet, the user gets the Windows popup
domain login box which prevents the redirect. However, disabling FBA loses
the security of the authentication cookies which manage OWA sessions on
public computers. If this is acceptable then disabling FBA is the way around
it.

Apologies again for misleading you previously, I hope this clears it up.

Regards

Chris


"Gregg Hill" wrote:

> Chris,
>
> Thank you for the information. When you say that using FBA resolves the
> problem, do you mean that if you have FBA enabled, the exploit cannot be
> used?
>
> I do not know what loss of functionality you mean in reference to using FBA.
>
> Gregg Hill
>
>
> "Chris" <Chris@discussions.microsoft.com> wrote in message
> news:AE5BCC4C-3A1B-43D3-8667-2E9C54736F0E@microsoft.com...
> > 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@here.com> wrote in message
> >> news:d1a3f41b1d10e8caba1bbda94926@news.microsoft.com...
> >> >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...sp?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@discussions.microsoft.com> wrote in message
> >> >> news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
> >> >>
> >> >>> 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/...d=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/adv...05-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.
> >> >>>>
> >> >
> >> >
> >>
> >>
> >>
>
>
>

Chris,

So in your original post, when you said, "...or use FBA," you actually meant
or **not use** FBA, correct?

When I have FBA enabled, I get the pretty little OWA login screen. Only if
FBA is DISabled do I get the Windows login prompt popup.

I thought I was going nuts (and oddly enough, so does my wife!).

Gregg Hill


"Chris" <Chris@discussions.microsoft.com> wrote in message
news:4C261A0D-76BB-4FA6-9335-9D5753B9BA1D@microsoft.com...
> Hi Gregg,
>
> Don't know what I was thinking when I wrote that bit...sorry!
>
> By disabling FBA the vulnerability is resolved and the owaauth.dll file is
> not directly accessible from the internet, the user gets the Windows popup
> domain login box which prevents the redirect. However, disabling FBA
> loses
> the security of the authentication cookies which manage OWA sessions on
> public computers. If this is acceptable then disabling FBA is the way
> around
> it.
>
> Apologies again for misleading you previously, I hope this clears it up.
>
> Regards
>
> Chris
>
>
> "Gregg Hill" wrote:
>
>> Chris,
>>
>> Thank you for the information. When you say that using FBA resolves the
>> problem, do you mean that if you have FBA enabled, the exploit cannot be
>> used?
>>
>> I do not know what loss of functionality you mean in reference to using
>> FBA.
>>
>> Gregg Hill
>>
>>
>> "Chris" <Chris@discussions.microsoft.com> wrote in message
>> news:AE5BCC4C-3A1B-43D3-8667-2E9C54736F0E@microsoft.com...
>> > 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@here.com> wrote in message
>> >> news:d1a3f41b1d10e8caba1bbda94926@news.microsoft.com...
>> >> >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...sp?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@discussions.microsoft.com> wrote in message
>> >> >> news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
>> >> >>
>> >> >>> 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/...d=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/adv...05-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.
>> >> >>>>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

Hi Gregg,

Exactly right, to stop the vulnerability being detected and being
'exploited' you can disable FBA, which is the solution suggested by
Microsoft. It's been a while since I looked at this and when I first replied
I got it the wrong way round. Sorry again for the confusion.

The other solution I thought of was to use a VPN solution to the network and
then access OWA locally by using IP restrictions on the 'Exchange' IIS
folder. If an SSL-VPN is available then all the better but this is still a
pain compared to the easy access using OWA.

I think PCI need to look at the vulnerability in more depth because I don't
think it is as serious as they think.

Regards

Chris


"Gregg Hill" wrote:

> Chris,
>
> So in your original post, when you said, "...or use FBA," you actually meant
> or **not use** FBA, correct?
>
> When I have FBA enabled, I get the pretty little OWA login screen. Only if
> FBA is DISabled do I get the Windows login prompt popup.
>
> I thought I was going nuts (and oddly enough, so does my wife!).
>
> Gregg Hill
>
>
> "Chris" <Chris@discussions.microsoft.com> wrote in message
> news:4C261A0D-76BB-4FA6-9335-9D5753B9BA1D@microsoft.com...
> > Hi Gregg,
> >
> > Don't know what I was thinking when I wrote that bit...sorry!
> >
> > By disabling FBA the vulnerability is resolved and the owaauth.dll file is
> > not directly accessible from the internet, the user gets the Windows popup
> > domain login box which prevents the redirect. However, disabling FBA
> > loses
> > the security of the authentication cookies which manage OWA sessions on
> > public computers. If this is acceptable then disabling FBA is the way
> > around
> > it.
> >
> > Apologies again for misleading you previously, I hope this clears it up.
> >
> > Regards
> >
> > Chris
> >
> >
> > "Gregg Hill" wrote:
> >
> >> Chris,
> >>
> >> Thank you for the information. When you say that using FBA resolves the
> >> problem, do you mean that if you have FBA enabled, the exploit cannot be
> >> used?
> >>
> >> I do not know what loss of functionality you mean in reference to using
> >> FBA.
> >>
> >> Gregg Hill
> >>
> >>
> >> "Chris" <Chris@discussions.microsoft.com> wrote in message
> >> news:AE5BCC4C-3A1B-43D3-8667-2E9C54736F0E@microsoft.com...
> >> > 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@here.com> wrote in message
> >> >> news:d1a3f41b1d10e8caba1bbda94926@news.microsoft.com...
> >> >> >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...sp?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@discussions.microsoft.com> wrote in message
> >> >> >> news:B459EFD6-1C7A-4939-B382-39C285DCA3FD@microsoft.com...
> >> >> >>
> >> >> >>> 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/...d=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/adv...05-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.
> >> >> >>>>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>