Both SMTP and IMAP have several built-in security features that help Exchange organizations that rely on the protocols...
to communicate securely. However, both protocols are also quite vulnerable. SMTP can be easily manipulated to send large amounts of spam and the authentication process in IMAP can be circumvented to steal passwords.
The biggest problem with the SMTP protocol is that it was not designed with security in mind. It was initially assumed that all mail servers could be trusted and that users would not abuse the system. Because of this, SMTP was designed to send mail using a series of commands that were all sent in clear text.
When you use an application like Microsoft Outlook to send SMTP mail, you don’t see the commands that are processed behind the scenes. However, this is only because the mail client processes the commands internally and obscures them from view. It’s actually possible to connect to an SMTP server and send a message using a series of commands.
You can actually do this by telnetting to your SMTP server. To do so, open a Command Prompt window and enter the Telnet command, followed by your server’s IP address and the number 25 (because SMTP uses Port 25). For example, your command might look like this:
Telnet 192.168.0.1 25
After setting this up, you must enter a series of commands. Your SMTP server should issue a response after each command. You can use these commands to take on any identity you like. For example, suppose you want to pose as [email protected] and send a message to [email protected].
First, you must convince the SMTP server that you’re using a computer in an SMTP domain. To do so, you would issue the HELO command, along with the fully qualified domain name of your computer. The name that you enter doesn’t matter, as long as it ends in Contoso.com. For example, you could use:
Next, you must tell the SMTP server who the message is from. Do this by using the Mail From: command. If you still want the message to look like it came from [email protected], the command would look like this:
MAIL FROM: [email protected]
The other commands used to manually send SMTP mail are fairly self-explanatory. Below, you can see an example of an SMTP conversation. In this conversation, you can see the commands that were issued, as well as the server’s responses:
220 mirage.production.com Microsoft ESMTP MAIL Service ready at Sun, 8 Aug
2010 22:44:59 -0400
250 mirage.production.com HELLO [220.127.116.11]
MAIL FROM: [email protected]
250 2.1.0 Sender OK
RCPT TO: [email protected] 250 2.1.5 Recipient OK
354 Start mail input; end with <CRLF>.<CRLF>
this is a test over SMTP
250 2.6.0 <[email protected]>
Queued mail for delivery
221 2.0.0 Service closing transmission channel
Connection to host lost.
This illustrates that SMTP can be easily manipulated. In this case, the commands shown above worked because I was already authenticated into Exchange. Remember that there is nothing stopping someone from setting up his own mail server and scripting a variation of the commands shown above in an effort to send mass quantities of spam.
The primary IMAP security flaw is that the client’s username and password are sent across the wire using clear text. Even though IMAP has an authentication mechanism, the authentication process can easily be circumvented by anyone who knows how to use a protocol analyzer to steal a password.
In an Exchange Server environment, you can fight this problem by using SSL encryption for IMAP. First acquire an X.508 certificate. Next, enable SSL encryption for IMAP by using the Enable-ExchangeCertificate cmdlet. When using this cmdlet, you’ll have to use the following parameter:
Remember that you can’t use the Enable-ExchangeCertificates command to implement SSL encryption for IMAP if you’re using a wildcard certificate. If you have a wildcard certificate, you have to use the Set-ImapSettings cmdlet instead.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, is a seven-time Microsoft MVP for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. For more information visit www.brienposey.com.