MS exchange/service user problems

Date: Wed, 15 Oct 1997 15:14:19 -0400
From: Russ <Russ.Cooper@RC.ON.CA>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
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;

http://premium.microsoft.com/support/kb/articles/q147/3/54.asp
http://premium.microsoft.com/support/kb/articles/Q147/3/62.asp

However, the problem arises with the fact that service accounts are
normally set;

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
password attempts.

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
group).

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
- http://premium.microsoft.com/support/kb/articles/q147/7/01.asp

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 -
http://premium.microsoft.com/support/kb/articles/q157/7/80.asp

7. Use the PASSFILT.DLL or one of your own to enforce strong passwords
as described in KB article Q161990 -
http://premium.microsoft.com/support/kb/articles/q161/9/90.asp

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.

Cheers,
Russ Cooper
R.C. Consulting, Inc. - NT/Internet Security