full-disclosure - OWA login redirection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <BAY19-DAV8FCD826B8F9FA1D30923BD9D60@phx.gbl>
Date: Thu Jul 21 21:41:52 2005
From: se_cur_ity at hotmail.com (Morning Wood)
Subject: OWA login redirection - Mitigation

 I have recieved the following from MSRC ( Microsoft Security Response
Center )
regarding my Advisory (
http://exploitlabs.com/files/advisories/EXPL-A-2005-001-owa.txt )
Exploitlabs is releasing this information to the public to help users
protect their systems until the next version of Exchange Server is released.

----------------------------------- 

The Microsoft Security Response Center would like to clarify the OWA URL
Redirection issue a little further, discussing both the severity and how
to protect against the threat if you feel that it is relevant to your
implementation.

Issue Severity -  For credentials to be stolen a number of factors must
be in play for a successful attack. This includes enticing the user to
click on a URL that contains a malicious address appended to their
normal OWA URL, bypassing a security alert message displayed by the
browser and then enticing the user to re-enter their credentials at the
malicious site.

With those factors in mind combined with the technical workaround
detailed below, this issue has been triaged for remediation in the next
version of Exchange Server.

Workaround - If you feel that your OWA system is or will be affected the
following workaround can be employed:

The following workaround can be used by the Exchange administrator to
remove the capability of users to provide a redirect URL via the FBA
QueryString.  The steps to do this are listed below:

1. Navigate to 'C:\Program Files\Exchsrvr\exchweb\bin\auth\usa' (*usa*
or which locale you are using)

2. Make a backup copy of logon.asp

3. Edit logon.asp

4. Go to line 54 of logon.asp

5. Hardcode the redirectPath variable to the path you are passing in to
the URL, in the case of Microsoft's OWA servers, line 54 of logon.asp
should look like:
     redirectPath = "http://mail.yourcompany.com/exchange/"

6. Close and save logon.asp

7. Click the URL below and logon to verify the reported issue no longer
works (ie. users are not redirected to the malicioussite.net domain):

http://mail.yourcompany.com/exchweb/bin/auth/owalogon.asp?url=http://mal
icioussite.net/phisher.asp

Hard-coding the destination/redirect URL prevents users from being able
to navigate directly to mapped virtual directories on the OWA server,
but if this functionality is required, step 5 could be modified to only
allow a virtual directory to be passed (ie. hard-code the protocol and
host name before allowing the 'url' parameter to be concatenated).

As always this workaround should be thoroughly tested on a
non-production system before being promoted to a live production system.

User education plays a major role in not only this specific phishing
attack but phishing in general. By educating end users about not
clicking on web links from questionable sources, combined with the
technical workaround will reduce risk of this OWA issue to a level that
is manageable for most organizations.

----------------------------------- 

Donnie Werner
wood at exploitlabs.com
http://exploitlabs.com