COMMAND

    Microsoft Exchange 5.0

SYSTEMS AFFECTED

    Win NT running Microsoft Exchange 5.0

PROBLEM

    Geremy Cohen found following security leak that works with all the
    SPs  installed  (SP3  while  this  writing),  and  Exchange   SPs.
    Additional info comes from Russ Cooper.

    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  seemingly  cannot  be  done  remotely,  only  locally on the
    machine running IIS and X5.0.

    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.

SOLUTION

    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.