Apparently many people use service accounts for Exchange. Apparently, those also generally don't have auto-account-disabling or password expiration, which makes exchange a great target for brute-force password guessing
Russ <Russ.Cooper@RC.ON.CA> and Geremy Cohen
Hack a Windoze box
Windoze NT running Exchange 5.0 as a service account
15 October 1997
Date: Wed, 15 Oct 1997 15:14:19 -0400
From: Russ <Russ.Cooper@RC.ON.CA>
Subject: Re: Exchange 5.0 Web Connector Fun / Security Hole
Geremy Cohen wrote...
>With MS Exchange 5.0, and all the SPs installed, and Exchange SPs, I
>have found a security leak . . . (at least I think I have)
>Logon to the local machine running X5.0 Server, as admin. Then,
>connect to the web connector, locally. It [Web Browser, IIS] should be
>running on the same machine as the X5.0 server. At the Web Access
>Page, type in the user name of any of your X5.0 accounts. When the
>authentication prompt appears, type the admin username/pw.
>This can get you into the mailboxes of any account on the X5.0 system.
This *IS* a security problem, and IMO, a big one. Let me explain.
Several people have pointed out that the Exchange Service Account (SA)
is inherited by all mailboxes on an Exchange Server (MSX) by default,
and therefore, logging in as that user will allow you to access any
Exchange mailbox or resource. See KB articles Q147354 and Q147362 for
more details about this "by design" feature of MSX;
However, the problem arises with the fact that service accounts are
1. To not allow the passwords to expire, thereby preventing the need to
remember to change the password in several locations.
2. To not disable the accounts upon failed logons, which if enabled
would permit a Denial of Service attack on the service by incorrect
Also, the SA has to have "Log on as a Service" and "Restore files and
directories" rights (more often than not, however, it ends up being
either the Administrator account or a member of the Administrators
Therefore, when you combine the above you have a situation where the SA
can be attacked by brute force password cracking and will likely yield
the attacker a logon as a member of the Administrators group.
To minimize the risks associated with such a compromise, the following
should be considered as a starting point (please note this has not been
tested and may very well break or prevent some functionality);
1. Make sure the SA is not the Administrator, or a member of the
Administrators group. See KB article Q147701 for SA permissions details
2. Disable the SA from being able to access the MSX from the network
(this may cause problems if multiple sites are involved).
3. Make sure that permissions to other resources preclude the SA.
4. Make sure the SA is set to be disabled upon failed logon attempt.
5. Closely monitor for failed logons.
6. Make regular changes to the password account as described in KB
article Q157780 -
7. Use the PASSFILT.DLL or one of your own to enforce strong passwords
as described in KB article Q161990 -
This problem needs to be corrected by Microsoft. Its continued presence
makes it impossible to properly manage an Exchange Server as enabling
the workarounds makes them subject to Denial of Service attacks.
Employing the GETADMIN Hot Fix should make discovery of the Exchange
Service Account name more difficult, although certainly not impossible.
The problem will exist regardless of whether or not Web Access is
permitted to the MSX mailboxes. On machines without Web Access, it would
be possible to attempt a connection using an Exchange Client. One would
assume that both POP3 and IMAP function similarly.
R.C. Consulting, Inc. - NT/Internet Security
The master index of all exploits is available
here (Very large file)
Or you can pick your favorite operating system:
This page is part of Fyodor's exploit
For a free program to automate scanning your network for vulnerable
hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resouces: