Lazy Exchange Admins
by ddShelby
Security in Microsoft Exchange Server is or should be a concern for many admins out there because of its fairly widespread use in many small to mid-sized organizations.
It does have some worthy features but also has some serious security concerns (like everything from Redmond) that need to be attended to. And that is the purpose of this article.
To inform and educate those who read it and maybe expose a few Exchange admins to some information they might find useful. So let's get started.
As an admin you have the ability to create an account during install that is not the same as the default administrator account in the OS. But not many elect to do this because of the log on/log off hassle to administer the OS along with a separate account to administer Exchange.
If a separate Exchange admin account was not created at the time of install (which is almost always the case) and it's a Windows NT 4.0 server, then it's almost guaranteed that administrator@whoever.com exists, because you can't rename the administrator account for the OS in NT.
If it's a Windows 2000 server with Exchange 5.5 or Exchange 2000, the same is also true. But with the ability to rename the default administrator account in the OS, there is a chance it was renamed at the time of setup.
In both cases (assuming default) the administrator account for the OS has an SMTP address that follows the convention: administrator@whoever.com
If the OS is NT4, then it's a shoe-in unless the SMTP settings were edited by the admin. This is the problem.
Some Basics of Exchange
The standard version of Exchange 5.5 and Exchange 2000 both have a limit on the size of either the public or private database (PRIV.EDB and PUB.EDB).
They cannot exceed 16 GB each. The Enterprise versions of 5.5 and 2000 are not limited to anything except available drive space. With server drive space still somewhat costly (assuming the server runs with some form of SCSI and RAID), reaching this limit is not difficult for most organizations of a dozen users or more.
Two reasons why it's so easy to get to 16 GB or reach the server's available drive space limit is the disregard of most admins towards limiting users' mailbox size and the users' habit of using Outlook deleted items folder as an archive folder.
The admin has the ability to force notification limits on users' mailbox size on either a global or per user basis. The spam issue is also partly to blame since everyone just deletes it, but the mentality of using the deleted items folder as an archive comes back to haunt again, only adding to the total size of the database.
So the 16 GB limit is in many cases closer than one might think. This is especially true if none of the limits were ever put in place and the server has been in use for a year or longer. It's made worse by the fact that small organizations don't need a monster server to run Exchange 5.5 and with the hardware requirements set forth by Windows 2000 server, many have elected to stay with Windows NT 4.0 and Exchange 5.5.
An NT4/Exchange 5.5 server could easily serve a dozen users on a 200 MHz Pentium with 32 MB of RAM and a single 10 GB IDE drive. Don't laugh, I've seen it.
Getting back to the point.
Any Exchange server is vulnerable to getting swamped and not by some new hack. You can crash Exchange by simply knowing any e-mail address of any recipient on any given server.
The ugly part is this could potentially happen over days or weeks or even months before it's even noticed or it's just too late. Since Exchange by default has an account assigned to the Administrator of the OS, an SMTP address exists for it.
If you assume that the administrator account is not actually in use but still exists, one could theoretically swamp an Exchange server by sending numerous e-mails with large bogus attachments. Or if the sender's ISP does not impose limits on the size of outgoing mail, one large attachment could do the same.
To use any general user's address is slightly more difficult since users usually read their mail. But the administrator account is almost never used since admins set up an address for themselves and use it instead.
As drive space comes close to zero available, the Exchange service that handles SMTP (Internet Mail Service [IMS]) shuts down and all incoming mail is rejected. But since the information store service (the database) usually continues to run, and if the admin is smart enough to check the private information store listed in Exchange Admin, he would see the tremendous size of the mailbox and then just log into it and clean it out.
An easy fix for this is to just edit the SMTP address of the administrator account to something obscure. In addition, you could disable any unused SMTP addresses to help prevent getting swamped.
A periodic check of available drive space or the size of the .EDB files would be useful, but seems to escape many admins.
But Wait, It Gets Worse
As opposed to reaching the drive space limit, if the 16 GB database limit is reached instead, it becomes a whole different story.
If the Enterprise version is installed before the 16 GB limit is reached, then disaster can be avoided. However, if the 16 GB limit is reached before upgrading, the information store service is shut down automatically and can't be restarted.
The result from this is all incoming SMTP messages are rejected at the server and no user can log in to their respective mailbox. And the admin can't get the service started to log in and delete the offending content.
As an admin you can purchase the Enterprise edition for two grand, but installing it on top of the standard edition doesn't quite solve the problem. All is not lost - there is a workaround for this listed in the Knowledge Base that explains how to copy the database into the active folder (usually EXCHSRVR\MDBDATA) after you install the Enterprise version.
But if the database has reached the 16 GB limit you'll be copying for a while. If the admin is savvy enough, he could play the game of just renaming folders instead of copying. But with so many Windows admins who changed careers from grocery bagging, it's unlikely they're smart enough to figure that out.
And as the Knowledge Base article suggests to copy the .EDB file, it seems to me that at least one employee at Redmond didn't figure it out either. Admins could also defrag the database with a utility included with Exchange in the EXCHSRVR\BID folder called ESUTIL (both 5.5 and 2000).
This would buy enough time to delete enough and recover. But if the SMTP service IMS is running and email is still incoming, it could be a race to delete before it reaches its limit again.
In addition, the defrag needs drive space equal to or greater than the size of the database. But this inevitably brings me back to admins who were bagging groceries six months ago.
Another safety net would be to implement a second MX record for the domain with a higher cost route, so any incoming mail rejected by Exchange would be collected on another machine. Then with ETRN you could dequeue the mail from the higher cost server and no mail would be lost.
Discovery of a Server
Regardless of the presence of a firewall, by using one of the many port scanners an Exchange server is easy to find.
I use SuperScan on my Windows 2000 laptop but many others work just the same. A scan of a range of addresses to port 25 will eventually reveal an open port.
If it's an Exchange server it will identify itself as such, as well as the version and build. For example:
In this example it's a 5.5 SP4 server.
With that, the domain is known, the administrator address can be correctly assumed 95 percent of the time or better, and the rest is up to any delinquent with nothing better to do. Or at some point some worm will make its way to the Internet and play this same game, only faster.