Export (0) Print
Expand All

Microsoft Security Bulletin MS01-047 - Critical

OWA Function Allows Unauthenticated User to Enumerate Global Address List

Published: September 06, 2001 | Updated: May 09, 2003

Version: 1.2

Originally posted: September 06, 2001
Updated: May 09, 2003

Summary

Who should read this bulletin: 
System administrators using Microsoft® Exchange 5.5.

Impact of vulnerability: 
Information disclosure

Recommendation: 
Administrators offering mail service through Outlook Web Access should apply the patch.

Affected Software:

  • Microsoft Exchange 5.5

General Information

Technical description:

Among the functions Outlook Web Access (OWA) in Exchange 5.5 offers is the ability to search the global address list (GAL). By design, this is an authenticated function, implemented as a two-tier architecture - a front tier that provides a user interface and a back-end tier that actually performs the search. However, only the front tier actually checks authentication. An attacker who sent a properly formatted request to the back-end function that actually performs the search could enumerate the GAL without authenticating.

Mitigating factors:

  • The vulnerability would only allow the attacker to learn users' email aliases. It would not provide any other capabilities. Specifically, it would not give the attacker any way to create or send mail as a user; to read, change or delete mail; or to perform any other functions on the server.
  • The vulnerability is only exploitable via OWA. Exchange servers that are not configured to offer OWA are not affected by the vulnerability.
  • The vulnerability does not affect Exchange 2000, even when offering OWA.

Vulnerability identifier: CAN-2001-0660

Tested Versions:

Microsoft tested Exchange 5.5 and Exchange 2000 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

What's the scope of the vulnerability?
This is an information disclosure vulnerability. An Internet-based attacker could use it to learn the email addresses of users on a corporate Exchange 5.5 server, if the server was configured to offer Outlook Web Access (OWA).
The vulnerability would not allow the attacker to read, write or change any of the users' email, or to take any other action against the users. Likewise, it wouldn't allow the attacker to gain any privileges on the server. Its sole effect would be to allow the attacker to learn email names of users on the server. The vulnerability does not affect Exchange 2000.

What causes the vulnerability?
The vulnerability results because a function in OWA that interrogates the global address list (GAL) doesn't require authentication. Unauthenticated users could call the function and enumerate the mail addresses of users on the server.

What's OWA?
OWA is a feature in Exchange 5.5 and 2000 that allows users to access their email via a web browser instead of a mail client. Essentially, OWA makes an Exchange server also function as a web site that lets authorized users read or send mail, manage their calendar, or perform other mail functions via the Internet.

What's wrong with OWA?
The problem results because of the way a feature is implemented in the Exchange 5.5 version of OWA, that lets users look up other users' email addresses in the GAL. The feature at issue has a two-tier architecture: a user-interface (UI) web page that gathers information from the user such as the email address to search for, and a back-end function that the UI page calls to perform the actual search.
Although the UI page requires the user to have previously authenticated to the server, the back-end function doesn't. The problem this raises is that an attacker with no credentials on the server could send a search request directly to the back-end function in order to learn the email address for any or all users on the server.

Why does the back-end function accept unauthenticated requests?
The back-end function assumes that it will only receive requests from the UI page. Since the UI page always checks the user's authentication status, the back-end function assumes that any requests have already been authenticated. But this is a flawed assumption, because it's possible for a user to send a request directly to the back-end function.

What would this vulnerability allow the attacker to do?
An attacker who connected to an affected serve and sent a request directly to the back-end function would be able to search the GAL and learn the email addresses of users on the server.

Would this allow the attacker to do anything other than learn users' email addresses?
No. All of the other functions on OWA require authentication as designed. The only thing the attacker could do through this vulnerability would be to look up email addresses. The vulnerability provides no way to create, send, read, change, or delete mail, nor would it allow an attacker to perform any other functions on the server.

What's the harm in letting someone learn users' email addresses?
On the surface, it wouldn't appear that there's any harm here. Simply knowing someone's email address wouldn't let a person do anything except send email to them - and that is, after all, the reason why people have email addresses.
However, this information could be valuable reconnaissance information to someone who was planning to attack a network using other vulnerabilities. For instance, having a list of users on a network might give an attacker a sense of its size, or provide information about its structure and topology.

I run an Exchange server, but I don't offer OWA. Should I install the patch?
The vulnerability is only exposed via OWA, so if you don't offer OWA, you don't need the patch. You may, however, choose to install it anyway, as a precaution in case you decide to offer OWA services at some future point.

I'm offering OWA via Exchange 2000. Should I install the patch?
No. The vulnerability only affects OWA in Exchange 5.5.

What does the patch do?
The patch eliminates the vulnerability by changing the back-end function to only accept requests from authenticated users.

Download locations for this patch

Additional information about this patch

Installation platforms:

The patch can be installed on systems running Exchange 5.5 Service Pack 4.

Inclusion in future service packs:

The fix for this issue will be included in Exchange 5.5 Service Pack 5.

Reboot needed: No

Superseded patches: None.

Verifying patch installation:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Exchange Server 5.5\SP5\Q307195.

  • To verify the individual files, consult the file manifest provided in Knowledge Base article Q307195.

Caveats:

None

Localization:

The patch can be applied to any language version.

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site.

Other information:

Acknowledgments

Microsoft thanks Noam Rathaus from SecuriTeam.com (http://www.SecuriTeam.com), and Joseph Steinberg and Ophir Polotsky of Whale Communications (http://www.whalecommunications.com) for reporting this issue to us and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q307195 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
  • Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

Revisions:

  • V1.0 (September 06, 2001): Bulletin Created.
  • V1.1 (September 10, 2001): Acknowledgment section updated.
  • V1.2 (May 09, 2003): Updated download links to Windows Update.

Built at 2014-04-18T13:49:36Z-07:00

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2015 Microsoft