‘Exchange Public Folders Information Leakage’


‘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 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. ‘


‘The information has been provided by Microsoft Product Security and SecuriTeam Experts.’


Vulnerable systems:
 * Microsoft Exchange 5.5

Immune systems:
 * Microsoft Exchange 2000

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.

Patch availability:
Download locations for this patch
 * Microsoft Exchange 5.5:

Steps to recreate:
1) Send the following request:
GET /exchange/root.asp?acs=anon HTTP/1.1
Host: hostname

2) Use the provided cookie to generate the following request (and those that follow):
GET /exchange/logonfrm.asp HTTP/1.1
Host: hostname

3) Access the redirected page, and resend the issued cookie:
GET /exchange/root.asp?acs=anon HTTP/1.1
Host: hostname

4) Issue this request to obtain a list of users with the letter ‘a’ in their name (e.g. Administrator)
POST /exchange/finduser/fumsg.asp HTTP/1.1
Host: hostname
Accept: */*
Content-Type: application/x-www-form-urlencoded
Content-Length: 44


What is 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 would not 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) does not require authentication. Unauthenticated users could call the function and enumerate the mail addresses of users on the server.

What is 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 is 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 does not. 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. However, this is a flawed assumption, because it is 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 is the harm in letting someone learn users’ email addresses?
On the surface, it would not appear that there is 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 do not offer OWA. Should I install the patch?
The vulnerability is only exposed via OWA, so if you do not offer OWA, you do not 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 am 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.’

Categories: Windows