OWA Security Patch

On November 14, the NTBugTraq mailing list carried an announcement of a major security flaw in Outlook Web Access (OWA) 2003. However, the announcement contained little detail about the alleged flaw, reporting that “When you log in with your own credentials you may be logged into another user's mailbox at random and has [sic] full access to this user's mailbox.” Several news sites took this initial report and ran with it, announcing the existence of the flaw without describing it in detail, so many administrators were unclear about whether the problem was real and what caused it.

The vulnerability is real and occurs when you install Windows SharePoint Services (SPS) on an Exchange 2003 back-end server. SPS is a Windows Server 2003 component, so the vulnerability appears only on Windows 2003 servers. Let’s look at the problem in more detail to see how you can fix it--and whether the vulnerability is a serious one.

One of Exchange 2003’s key security changes is its support for end-to-end use of Kerberos authentication. Kerberos is the native authentication protocol for Windows 2003 and Windows 2000 Server and is designed to provide cryptographically secured strong authentication over untrusted networks. Kerberos is designed specifically to protect against attacks that can be mounted against other authentication methods, including man-in-the-middle attacks (in which an attacker sits between client and server, impersonating each to the other) and replay attacks (in which an attacker records credentials and “replays” them to gain access).

Installing SPS turns off Kerberos authentication for Microsoft IIS and enables Integrated Windows Authentication (IWA). This design is reasonable for a standalone SPS server because SPS users probably will use Web browsers to authenticate and because enabling Kerberos for use with IIS requires extra steps (as the Microsoft article “HOW TO: Configure Windows SharePoint Services to Use Kerberos Authentication” at http://support.microsoft.com/?id=832769 explains). However, the design introduces a new problem when you add Exchange to the mix.

As the Microsoft article "How to Disable HTTP Connection Reuse on a Microsoft Exchange Server 2003 Front-End Server" ( http://support.microsoft.com/?id=832749 ) explains, front-end servers can reuse connections to back-end servers. This ability improves the end-user experience by providing better performance but can lead to a situation in which two users, each connecting to the same front-end server, end up with sessions that use the same connection to the back-end server. That situation is fine when Kerberos authentication is in use but can lead to the problem that the NTBugTraq posting described when Kerberos is disabled.

Interestingly, the Exchange front-end code logs event ID 1000 from the ExProx service when it detects that Kerberos isn’t working properly. You might want to add that event to your monitoring regime to help you catch other circumstances in which Kerberos stops functioning (e.g., when an administrator explicitly disables it).

Is the vulnerability a huge threat? No. The flaw is worrisome in the sense that it arises from an unexpected (and, presumably, untested-for) interaction between two supported Microsoft products. However, Microsoft recommends that you keep running Exchange on dedicated servers on which you’ve disabled all services that aren’t necessary to Exchange, so sites that follow that recommendation have nothing to fear from this flaw. Moving forward, it’s probably safe to say that the executives who oversee the Windows and Exchange teams have vigorously reminded those teams of the importance of testing procedures--hopefully avoiding similar situations in the future.