Introduction

This article is the first of a two-part series that will to provide a technical look at some of the fundamental requirements for securing Microsoft Exchange Server 2000 and Outlook Web Access (OWA) running in a Windows 2000 Active Directory environment. I will start by looking at some exploits for Exchange server to give readers an idea of areas that need protection. Then I’ll get right into the Exchange application and discuss some of its inherent security features, as well as some secure network designs for Exchange/OWA deployments.

One concept that will be echoed throughout this two-part series is that you should always consider Windows OS security. However, while things like Auditing, Group Policy, IPSec, NTFS ACL’s, and remote access are crucial to Exchange server security, they are beyond this article.

Another point I want to mention up front is that although IIS needs to be installed for Exchange 2000, this doesn’t mean that the World Wide Web Publishing Service needs to be running. You only need to have the Web Service running when you are using OWA, otherwise, disable it – more on this in a bit.

What is Not Covered?

Unfortunately, I don't look at all of the Exchange server functionality. Topics like replication, backups, monitoring and status notifications, and PKI are a bit beyond this article.

Replication is a process by which multiple Exchange servers in the same Organization will communicate and update each other’s schema and databases. This is extremely similar to the concepts of replication between Domain Controllers in a Windows 2000 network.

For your Internet clients, you should enable TLS when using POP3 and SMTP to talk to the Exchange server. Enough said there.

Backups are of course crucial to every Exchange organization, and there are lots of good products available to online backups/restores of the entire information store and even individual mailboxes and messages.

Secure Network Diagram

This diagram is put here just to illustrate a typical Exchange/OWA deployment scenario. You have several options for deploying an Internet-facing Exchange system. To name a few, you can:

Place the Exchange server itself directly in your DMZ and open up RPC ports to the Internet;
Set up a VPN for your remote clients to authenticate with before connecting to your Exchange server; and,
Set up a front-end/back-end topology.
The following network diagram is built on the front-end/back-end topology, where the OWA server is placed in the DMZ as the Internet-facing front-end, and the core back-end Exchange server is placed in the corporate LAN, serving up mail to the folks using OWA from the Internet and those using MAPI (Outlook) clients from your local intranet.

Figure 1: Network diagram

Dependence on Internet Information Server

When you mention the term IIS today, most people immediately think of HTTP and the World Wide Web Publishing Service. The two terms have become synonymous with each other, when in fact they are not. Internet Information Services (IIS) provides a framework for Internet services such as Web Service (HTTP), Network News Transport Protocol (NNTP), and Simple Mail Transport Protocol (SMTP). When IIS is installed, it provides:

The IIS Admin Service – the core framework process;
Administrative snap-ins for the MMC;
The IIS metabase (a configuration repository for all IIS services); and,
Common files and shared libraries for socket connection pooling, service control manager registration and management.
Exchange Server 2000 requires that IIS be installed with the Web Service, SMTP service, and NNTP service. These services provide necessary components, and as we shall see, they are not always needed after installation. The SMTP service is dependent only upon the IIS Admin service.

The Web Service is the questionable aspect. Many people cannot decide whether or not Exchange server depends on Web Service to be running. The fact is that unless you are running OWA, you do not need the Web Service to be running. You need to have it installed, but you can safely stop and disabled the service if not running OWA.

That doesn't mean you shouldn't lock it down though. Approach it as if your Web Service may one day be accidentally, or even intentionally, started on an Exchange server on which it was never intended to run. That is to say, you should still lock down the Web Service by running the IIS lockdown wizard or manually following the checklist, removing unnecessary virtual directories and script mappings, and enhancing file security with NTFS ACL’s. It is recommended that the lockdown wizard be deployed on every Exchange server and Domain Controller to increase its protection in the unlikely event that the Web Service is started in error.

Exploiting Exchange

The greatest fear of most administrators is that the Exchange Information Store will become compromised or corrupt beyond repair. For the purposes of this discussion, we will look primarily at security from an internal perspective, with a specific focus on what the disgruntled employee might try.

Why hack Exchange? If you are doing a security penetration test, Exchange is probably not a typical target of choice like a Domain Controller (DC). However, if you find an Exchange server, you can definitely start poking at it to learn some configuration information, naming schemes, and user names that will be useful to expand your influence on the network. A malicious hacker might have similar desires, and may actually be after something more.

Just remember, most of the strength of the Exchange server will come from the way you manage User and Administrator accounts. If a hacker learns a user's password, they will own their e-mail. If a hacker learns an Administrator password, they will own the entire information store. If you are not Auditing, or effectively spreading out your roles and responsibilities, then you may never know that this has occurred. To prevent this, limit the number of admin accounts to only what you need, and test their password strength often. Remember, your Administrator accounts are top targets!

Network Port Scan

TCP/UDP port scans of the network, or a particular host, are a typical way by which an attacker will begin mapping out a network to plan an attack. The Exchange server is typically easy to spot because it is often installed by default with something like 30 listening ports!

Server Enumeration

I'm not going to discuss NetBIOS enumeration in too much depth, because it is a function of the Windows OS, not the Exchange application. It’s basically the same old story that if you allow anonymous or null sessions to be established, an attacker can glean a ton of useful configuration and user information from your system. Make sure you set the RestrictAnonymous registry key manually, or set it through the Local Security Policy MMC snap-in (secpol.msc).

LDAP functionality provides some interesting hacks with Exchange. LDP.exe is one of the tools installed with the Windows 2000 Support Tools package, located in the Support directory of the install CD. It will connect to any LDAP-compliant computer, not just Exchange and AD, and let you enumerate a massive amount of information. In figure 2 (below), there is a screenshot of some information gleaned via an authenticated connection with a normal domain User account.

Pilfering Shares

Exchange 2000 sets shares by default to allow EVERYONE, or Authenticated Users with Read access. Hopefully you are not allowing ANONYMOUS access as well to these shares. The Tracking Logs are probably of most interest here. Many folks enable Message Tracking in order to get statistics and run reports on their servers. If you have turned on Message Tracking, then tracked messages will be stored in this shared folder using a name scheme of %COMPUTERNAME%.log. In this folder the System Attendant will keep track of who is sending e-mail to whom. This file contains principal names and e-mail addresses, which can be useful to an attacker searching for clues.

LDAP Enumeration

LDAP exposes Users and Public Folders hidden from the Exchange Address Lists. Figure 2 is a screenshot from the LDP.exe tool, showing the LDAP information we have gathered.

Figure 2: Output from LDP.exe

As you can see, a normal user can by default, enumerate all users in the Active Directory from a DC. You can even see which ones the administrator has set to "Hide from Exchange Address Book". The highlighted text in the screenshot is the msExchHideFromAddressLists property value for my user account – “Chris Weber”. It is set to "true", indicating that my e-mail address, listed closer to the top as “mail,” is to be hidden from the Global Address List. Obviously that setting doesn’t help too much for someone determined to find hidden GAL entries.

A simple script could automate the process of searching for the msExchHideFromAddressLists property.

This is true for Users and for Public Folders, including the special “System Folders” used by Exchange. If you don’t like this happening, you need to adjust the Read permissions for these objects in Active Directory. This is not a difficult task; however, it is a bit beyond the scope of this article.

Port Scan

You should take the time to understand the TCP and UDP ports your Exchange server is listening on, as shown in Figure 3. With this knowledge you can properly secure the server based on its role. Check out the MS knowledgebase article describing common TCP/UDP ports used by Exchange: XGEN: TCP/UDP Ports Used By Exchange 2000 Server (Q278339). Say, for example, that you are running an Exchange server just as an SMTP relay host. You shouldn’t need NNTP/SSL running over TCP/563 then. This is yet another reminder to disable most of the unused protocols and services running on your server, before it goes into production.

Figure 3 shows the results of a network TCP port scan using a fast port scanner called FSCAN.EXE, available from Foundstone.

XGEN: TCP/UDP Ports Used By Exchange 2000 Server (Q278339)
D:\tools>fscan -p 1-65535 -z 128 exchange
FScan v1.12 - Command line port scanner.
Copyright 2000 (c) by Foundstone, Inc.
http://www.foundstone.com

Scan started at Fri Feb 22 00:50:30 2002

172.16.2.10 25/tcp - SMTP
172.16.2.10 80/tcp - HTTP
172.16.2.10 119/tcp - NNTP
172.16.2.10 135/tcp - RPC/DCE endpoint mapper
172.16.2.10 139/tcp - NetBIOS session service
172.16.2.10 143/tcp - IMAP
172.16.2.10 443/tcp - HTTPS
172.16.2.10 445/tcp - Microsoft SMB/CIFS
172.16.2.10 563/tcp - NNTP/SSL
172.16.2.10 593/tcp - HTTP RPC endpoint mapper
172.16.2.10 691/tcp - SMTP/LSA 172.16.2.10 993/tcp
172.16.2.10 995/tcp - POP/SSL
172.16.2.10 1048/tcp
172.16.2.10 1049/tcp
172.16.2.10 1053/tcp
172.16.2.10 1055/tcp
172.16.2.10 1089/tcp
172.16.2.10 1104/tcp
172.16.2.10 1107/tcp
172.16.2.10 1198/tcp
172.16.2.10 1200/tcp
172.16.2.10 1247/tcp
172.16.2.10 1249/tcp
172.16.2.10 3372/tcp
172.16.2.10 3389/tcp - MS Terminal Server
172.16.2.10 4277/tcp

Scan finished at Fri Feb 22 00:55:48 2002
Time taken: 65535 ports in 318.138 secs (206.00 ports/sec)

Figure 3: Network port scan of Exchange 2000

Port and Process Mappings

So just what are all of those other listening ports? Two useful tools for determining this are FPORT.EXE and TLIST.EXE /S which is available from the Windows 2000 installation CD Support directory. Fport.exe maps all of your computer’s listening ports to a running process. This will surely answer some questions for you. Make sure you use the correct version of Tlist.exe. The RK version will not work the same as the Support tools version. Tlist /s maps services to running processes. Tlist /t displays the process tree list as parent and child processes.

Figure 4 is just a partial list of FPORT’s output. You can see how each TCP and UDP port is mapped to its running process. You will see a lot more than this if you run it, however, because I have trimmed down the output for simple illustration.

FPort v1.31 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com
Securing the dot com world
Pid Process Port Proto Path
1028 inetinfo -> 25 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1028 inetinfo -> 80 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1028 inetinfo -> 110 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1028 inetinfo -> 119 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
512 svchost -> 135 TCP C:\WINNT\system32\svchost.exe
8 System -> 139 TCP
1028 inetinfo -> 143 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1028 inetinfo -> 443 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
8 System -> 445 TCP
1028 inetinfo -> 563 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
512 svchost -> 593 TCP C:\WINNT\system32\svchost.exe
1028 inetinfo -> 691 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1028 inetinfo -> 993 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
1028 inetinfo -> 995 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
264 lsass -> 1032 TCP C:\WINNT\system32\lsass.exe
264 lsass -> 1033 TCP C:\WINNT\system32\lsass.exe
600 msdtc -> 1048 TCP C:\WINNT\System32\msdtc.exe
860 MSTask -> 1049 TCP C:\WINNT\system32\MSTask.exe
1044 mad -> 1053 TCP C:\Program Files\Exchsrvr\bin\mad.exe
1044 mad -> 1055 TCP C:\Program Files\Exchsrvr\bin\mad.exe

Figure 4: Output from fport.exe

Figure 5 is output from the Support Tools version of tlist.exe. You can see how each process is expanded to show the running service. For example, the inetinfo.exe process hosts the following services: IISADMIN,IMAP4Svc,NntpSvc,POP3Svc,RESvc,SMTPSVC,W3SVC. This is a very useful investigatory tool.

0 System Process
8 System
172 SMSS.EXE
200 CSRSS.EXE
224 WINLOGON.EXE
252 SERVICES.EXE Svcs: Alerter,Browser,Dhcp,dmserver,Dnscache,Eventlog,lanmanserver,lanmanworkstation,LmHosts,Messenger,PlugPlay,ProtectedStorage,seclogon, TrkWks,W32Time,Wmi
264 LSASS.EXE Svcs: Netlogon,NtLmSsp,PolicyAgent,SamSs
368 termsrv.exe Svcs: TermService
512 svchost.exe Svcs: RpcSs
540 SPOOLSV.EXE Svcs: Spooler
600 msdtc.exe Svcs: MSDTC
748 svchost.exe Svcs: EventSystem,Netman,NtmsSvc,SENS
764 LLSSRV.EXE Svcs: LicenseService
808 regsvc.exe Svcs: RemoteRegistry
840 LOCATOR.EXE Svcs: RpcLocator
860 mstask.exe Svcs: Schedule
944 WinMgmt.exe Svcs: WinMgmt
1000 dfssvc.exe Svcs: Dfs
1028 inetinfo.exe Svcs: IISADMIN,IMAP4Svc,NntpSvc,POP3Svc,RESvc,SMTPSVC,W3SVC
1044 MAD.EXE Svcs: MSExchangeSA
1076 mssearch.exe Svcs: MSSEARCH
1524 STORE.EXE Svcs: MSExchangeIS
1556 EMSMTA.EXE Svcs: MSExchangeMTA
2360 CSRSS.EXE Title:
2384 WINLOGON.EXE Title: NetDDE Agent
2464 rdpclip.exe Title: CB Monitor Window
2508 explorer.exe Title: Program Manager
2560 mshta.exe Title: Windows 2000 Configure Your Server
2580 svchost.exe Svcs: TapiSrv
2652 mdm.exe Title: OleMainThreadWndName
2736 CMD.EXE Title: C:\WINNT\System32\cmd.exe - tlist /s
976 notepad.exe Title: fport - Notepad
768 TLIST.EXE

Figure 5: Output from tlist.exe /s

Conclusion

This concludes the first installment in the two-part series on securing Exchange 2000. This article has focussed primarily on a brief overview of implementing Exchange 2000, along with some exploits that sys admins need to be aware of. The second article in this series will focus on secure configuration and administration of Exchange 2000, including locking down Exchange, and an analysis of some publicized vulnerabilities.

Chris Weber has spent many years working various positions in the IT industry, including systems administrator and network architect. Today Chris is a security engineer for Foundstone, where he enjoys pen-testing, network architecture reviews, and application security testing.