20 Years Ago...
The very first security related item I authored was a piece for "2600: The Hacker Quarterly." I was a very young, angry Microsoft Exchange 5.5 sysadmin (who wouldn't be angry working on that tech all day) and put together an article on all the ways Exchange can be misconfigured to allow an attacker to exploit the system. It showed up in the Winter 1999 issue. When I gave it a re-read nearly 20 years later, I was surprisingly proud of it. I got many security concepts and core fundamentals right.
In retrospect, I was a little surprised how angry I seemed. I wasn’t then, and am not, a now, an angry person by any measurement. I think I using faux anger to be funny. I later learned that I don’t have to do that to be funny - just being myself, talking about interesting things and being a really good listener are naturally endearing to people.
You may be amused to read about the olden days of sysadmin.
The full, unedited text I submitted is below. The version edited down by 2600 staff and published is here: 2600: The Hacker Quarterly / "Understanding Microsoft Exchange" (page 53
Understanding Microsoft Exchange
Microsoft Exchange Server is one of the most popular and widely deployed groupware and messaging servers around. It’s also very easy to install and configure, so you have a lot of jackasses becoming overnight Exchange administrators. These mail servers are typically not very secure and misconfigured. Whether you are a hacker, cracker, or an Exchange administrator, there is one golden rule of security. NT is only as secure as the infrastructure; Exchange is only as secure as NT. Both rely on an informed and competent system administrator.
The purpose of this article is to introduce the curious to Microsoft Exchange, how it works, and its vulnerabilities. I am not going to teach you how to hack into it or into NT; volumes could be written on it’s exploits.
Understanding Exchange Sever
Microsoft Exchange server is agroupware and messaging tool, built for medium to large corporations. A lot of smaller companies use it also because of it’s ease of installation and native support for Outlook mail reader. Like all Microsoft products, it uses proprietary protocols and mail transfer methods. But, it also supports most major standards of mail transfer and the like. “Out of the box” Exchange supports the following protocols; X.400, X.500, LDAP, SMTP, POP3 and IMAP4. The X.400 and X.500 connectors can be quite fun, but that is a whole another article. Internally, it supports connectivity to other mail like MS Mail, Notes, CC:Mail, Groupwise, and SNADS. For Internet connectivity, it has a built in SMTP server.
Connection and Authentication
Exchange Server supports for ways to connect to it:
Exchange Client. “Exchange” client is a MAPI program that can natively connect to an Exchange server. For a long time it was only the Exchange Client which shipped with early versions of Exchange and Microsoft Outlook 97/98/2000. These clients use NT Authentication to connect, meaning you have to have an NT account on the server/domain with appropriate permissions in order to connect. Recently, HP announced that OpenMail for HP-UX and Linux supports Exchange client connectivity. I haven’t seen it so I can’t tell you how it works, but the Linux version sounds like something fun to hack around with.
HTTP. Starting with Exchange version 5.0, Exchange has a feature called Outlook Web Access. A server equipped with IIS3/4, Active Server Pages and Exchange 5.0 and above can present the Outlook interface through a web browser so users can get their mail. Challenge/Response authentication is the default, but it requires IE. Most administrators step the authentication down to clear-text to Netscape users can get their mail. This is a common mistake a lot of admins make. They sacrifice security for usability. The default path to Exchange’s OWA is www.servername.com/exchange. A lot of companies allow anonymous access to public folders. If you poke around long enough, a lot of information can be gained from reading public folders. A side note;OWA uses LDAP to do queries on the Global Address List. If you can access OWA from the Internnet, chances are they have anonymous LDAP turned on. With a LDAP-enabled mail reader, you are browsing their corporate email list in no time. In most Exchange sites email address = NT username. ‘nuff said.
POP3. Exchange allows POP3 clients to connect to the mail server. If an administrator enables this, they usually enable clear-text authentication. I have noticed most admins would rather just enable clear text then hassle with upgrading mail clients.
IMAP4. See POP3. Same authentication.
Now that you know the various protocols, you know there are various ways to connect to it from the Internet. Microsoft has had it’s share of security problems with Exchange, which were subsequently fixed by an Exchange Service pack. I have been working with Exchange for years and I have not once been into a site that had the latest service pack or hot fix. So, the first step in understanding exploits is understanding what build you are working with.
Two ways to get this info; look at the mail headers:
<snip> with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
or telnet into Exchange on port 25:
<snip> 220 mail.paylay.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2232.9) ready
Build Exchange Version
4.0.837 Exchange 4.0
4.0.838 Exchange 4.0 SP1
4.0.993 Exchange 4.0 SP2 (also referred to as Exchange 4.0a)
4.0.994 Exchange 4.0 SP3
4.0.995 Exchange 4.0 SP4
5.0.1457 Exchange 5.0
5.0.1458 Exchange 5.0 SP1
5.5.1960 Exchange 5.5
5.5.2232 Exchange 5.5 SP1
5.5.2448 Exchange 5.5 SP2
Obviously, if you come across a server that is using a very early build, chances are they haven’t installed ant NT or IIS service packs either. This is a sad fact I find completely laughable. Give me my Palm and Palm modem and 10 minutes on a Exchange build 2232 on NT SP3 and IIS out of the box, and I will be looking payroll, tax, or bribe information or just looking at their corporate sales contacts or whatever. If you are interested, do a little homework on general NT and more specifically, IIS exploits and you will find a lot of useful information.
A lot of dumb-ass VP’s want to check their email from their Palm on a cell phone on a desert island from their OWN ISP. Because a lot of admins or dumb, lazy or scared of their boss, they have allowed anonymous access into the SMTP portion of Exchange. Check this first.
Exchange’s SMTP connector has a feature that disables mail relaying. A LOT of companies have this feature disabled because they probably don’t understand what mail relaying is. Heh they probably think it’s a GOOD thing. So check into this second.
If the build is 5.5.2448 or below, and they have mail relaying disabled, there’s still a way around it. If the email is sent using what’s called “Encapsulated SMTP”, a way for Exchange to send mail to another Exchange Server via SMTP, you can replay using this because it doesn’t check for this. Microsoft has a hot-fix for it, but most companies run NT Service Pack Nothing, so check into this.
Exchange uses NT authentication for mailboxes, so exploits used for NT passwords can be applied to Exchange. Hack the Administrator password, you just hacked the Administrator mailbox.
Any mail standard Exchange uses (IMAP4, POP3, SMTP, etc) is, well, standard. So the general rules when dealing with these protocols are applied to Exchange.
Under the Hood
Exchanges uses what’s called a Service Account. This is the NT account that Exchange uses. Among other thing, to send/receive mail, stop and start services, and other Exchange-related duties. This account should be the most secure account on your mail server. So, lets find out what it is:
Click on Organization \Site\Configuration\Server, and bring up the properties for the current server and click on Permissions. There is a box titles “Windows NT Accounts With Inherited Permissions.” Scrolling through the permissions list, there is a set of permissions called “Service Account Admin.” A smart NT administrator would only have a dedicated account that is NEVER used to log in with a VERY, VERY strong password have this permission. Why, you ask? Because a person with this set of permissions is GOD. You only need to be a “Admin.” Role to administer the Exchange server. A Service Account Admin can do anything; read anyone’s mail, contacts, calendar, journal, tasks, and public folders. You can send mail AS them, receive mail, set incoming mail rules, forward mail, filter mail to another mailbox, anything. You can set up a filter and rule on the CFO’s Inbox that will copy all mail with the words “Confidential” or “Finances” in the body, and have it automatically delete out of Sent Items so he never knows. With Service Account access, the possibilities are endless.
Now, your next question is, in the user list, which is the Exchange Service Account? Good question – a jack-hole administrator would make it the default NT account -- “Administrator” think he is gonna fool the hackers and name it “QzG6fW1”. I usually call mine “Joe Rodriguez” with the username “joer.” Something obviously NOT a service account. Another good place to start is if you have access to the NT user list and the Exchange Global Address List, start cross-referencing names. Some admins may have created a Service Account mailbox, but hidden it from the address list. So, figure out what NT accounts don’t have mailboxes, are you may be looking at some kind of service admin account, Exchange or otherwise. Of course if you have weaseled yourself into some kind of admin access in the NT domain, but you don’t have access to the Exchange server, see what services are running on Exchange. With some crafty NT Resource Kit tools and some NET commands, you will be able to bring up properties for services. With the “Start Up” properties for ANY Exchange service, who has “Log On As” permissions? You have just discovered one Exchange Service Account username. It may not be the only one, but it is a start.
This is a good basic introduction to Exchange. It is just as much a hacking tutorial as it is a how-to guide for Exchange admins on how a network ought NOT to be designed.