Understanding Microsoft Exchange
by PayLay (paylay666@yahoo.com)
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 a lot of know-nothing jackasses are becoming Exchange administrators overnight. Typically, these mail servers are not very secure and often misconfigured. Whether you are a hacker or an Exchange administrator, there is one golden rule of security: Windows 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 NT; volumes could be written on it's exploits.
Understanding Exchange Server
Microsoft Exchange Server is a groupware and messaging tool, built for medium to large corporations.
A lot of smaller companies also use it because of the 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 many protocols, including these: 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 other article. Internally, it supports connectivity to other mail systems, such as Microsoft Mail, Notes, cc:Mail, GroupWise, and SNADS. For Internet connectivity, it has a built in SMTP server.
Connection and Authentication
Exchange Server supports four ways to connect to it:
1.) 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, meaning you have to have an NT account on the server/domain with appropriate permissions in order to connect. Recently, HP announced that HP OpenMail for HP-UX and Linux supports Exchange Server 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.
2.) HTTP Starting with Exchange version 5.0, Exchange has a feature called Outlook Web Access. A server equipped with IIS 3/4, Active Server Pages, and Exchange 5.0 and above can present the Outlook interface through a web browser so users can access their mail. Challenge/Response authentication is the default, but it requires Internet Explorer. Most administrators step the authentication down to cleartext so Netscape users can access their mail. This is a common mistake a lot of admins make, sacrificing security for usability.
The default path to Exchange's OWA is: .
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 (GAL). If you can access OWA from the Internet, chances are they have anonymous LDAP enabled. 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.
3.) 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 than hassle with upgrading mail clients.
4.) IMAP4 See POP3. Same authentication.
Now that I have laid out various protocols, it's obvious there are various ways to connect to Exchange from the Internet. Microsoft has had their share of security problems with Exchange, which were subsequently fixed by an Exchange Service pack or hot fix. I have been working with Exchange for years now, and I have not once been to a site that had the latest service pack or hot fix. So, the first step in understanding Exchange's vulnerability is understanding what build you are working with.
Two ways to get this info; look at the mail headers:
or Telnet into Exchange on port 25:
Exploits
Obviously, if you come across a server that is using a very early build, chances are they haven't bothered to install any NT or IIS service packs.
This is a sad fact I find completely laughable. Give me my Palm and Palm modem and 10 minutes on an Exchange build 2232 on NT SP3 and IIS out of the box, and I will be perusing payroll, tax, or bribe information or just looking at some jerk's 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.
Some common, open holes in an Exchange Server:
1.) A lot of dumbass VPs want to check their e-mail from their Palm and cell phone from a desert island using their own ISP. Because a lot of admins are dumb, lazy, or scared of their boss, they have allowed anonymous access into the SMTP portion of Exchange. Check this first.
2.) Exchange's SMTP connector has a feature that disables mail relaying. A lot of companies have this feature turned off because they probably don't understand what mail relaying is. Heh, they probably think it's a good thing. So check into this next.
3.) If the build is 5.5.2448 or below and they have mail relaying disabled, there's still a way around it. If the e-mail is sent using what's called "Encapsulated SMTP," a way for Exchange to send mail to another Exchange Server via SMTP, you can relay mail because it allows relaying if the mail appears to be coming from another Exchange Server. Microsoft has a hot-fix for it, but most companies run NT Service Pack Nothing, so check this out.
4.) Exchange uses NT authentication for mailboxes, so exploits used for NT passwords can be applied to Exchange. Hack the Administrator password and you just hacked the Administrator mailbox.
5.) Any mail standard Exchange uses (IMAP4, POP3, SMTP, etc.) is, well, standard. So the general rules when dealing with these protocols also apply to Exchange.
Under the Hood
Exchange has what's called a Service Account.
This is the NT account that Exchange uses to send/receive mail, stop and start services, and perform other Exchange-related duties. This account should be the most secure account on your mail server. So, let's find out what the Service Account username is:
Click on Organization -> Site -> Configuration -> Server and bring up the properties for the current server, then click on Permissions.
There is a box titled 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 have a dedicated account that is never used to log in with, and this account would have a very, very strong password. Why, you ask? Because an account with this set of permissions is GOD.
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: which is the Exchange Service Account in the user list?
Good question - a jack-hole administrator would make it the default NT account - "Administrator" or he thinks 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.
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.