Exchange Server SMTP AUTH Attacks
If you run Microsoft Exchange Server to process incoming Internet email, spammers might be using your mail server as a relay even though your server isn't an open relay. How is this possible? Spammers authenticate to your email server, then use your server to send mail. Paul Robichaux wrote about this attack in "A New Kind of Attack," ( http://www.winnetmag.com/article/articleid/40507/40507.html ). The following discussion outlines how you can determine whether someone is using your system as a mail relay, how to close the hole, and how to test the measures you've taken to prevent such attacks.
Is Your System Under Attack?
To determine whether your system is a victim of such an attack, check the SMTP mail queues to see whether a spammer is using your mail server for relaying. To do so, start the Exchange System Manager (ESM) and go to Organization, Administrative Groups, Organizational Unit , Servers, ServerName Protocols, SMTP, Default SMTP Virtual Server, Queues. To list the messages in the queue, right-click the name of the queue for which you want to view the messages, select Enumerate 100 Messages, and double-click the queue to view the messages. Check the sender and recipient in several active queues. If the sender or recipient isn't a user from your local domain, the mail server is probably used as a mail relay. By default, Exchange 2000 and later allows relaying if a mail sender can successfully authenticate to the mail server. Don’t be alarmed if you have a lot of messages that are sent from postmaster@your_domain or administrator@your_domain because these are typically non-deliverable messages sent by the server.
How did the spammer get a username and password? Spammers can get a valid username and password in several ways. They can repeatedly guess the guest or other user's password until they stumble upon it, or they can launch an attack to obtain a valid username and password. Refer to my articles Malicious Hackers and Spam, Parts 1 and 2 at http://www.winnetmag.com/article/articleid/41094/41094.html, and http://www.winnetmag.com/article/articleid/41456/41456.html, respectively, for more information about how hackers can compromise your network. The hacker needs only one username and password combination to relay mail using your server.
Which account is the spammer using? To determine which account the spammer is using to relay email, you first need to turn up logging on your Exchange Server. Open ESM and go to Organization, Administrative Groups, Organizational Unit, Servers and right-click Server Name, Properties, and click the Diagnostics Logging tab. In the Services window, select MSExchangeTransport, and in the Categories window increase the logging level to maximum for all of the categories: Routing Engine, Categorizer, Connection Manager, Queuing Engine, Exchange Store Driver, SMTP protocol, and NTFS store driver. Check the event log; you should see an event with the Auth command and User ID when anyone authenticates to the mail server. Of course if you have multiple Exchange mail servers in your organization, you'll see many authentications to this mail server from other Exchange servers in your company. Specifically, you’re looking for an authentication from an external or unknown mail server that isn't in your organization. The logon ID that the spammer is using will show up as event 1708 in the Application event log. To track unsuccessful login attempts to the server, enable Successful/failure Account Login Attempts. Unsuccessful login attempts will show up in the security log with event ID 680.
Plugging the Hole
Change passwords. Change the password for the account the spammer uses. In fact, you might want to change the passwords for all users on the network in case the spammer has more than one valid user ID and password. Also, make sure the Guest account is disabled, and don’t forget about the accounts that are used to start services on the server: If you haven’t already done so, now is a good time to set up individual accounts that are used to start services on the server. Disable authentication on the outfacing Exchange Server. To disable authentication on these servers, start ESM, and go to Organization, Administrative Groups, Organizational Unit, Servers, ServerName, Protocols, SMTP, and right-click the Default SMTP Virtual Server. Select Properties, open the Access tab, and click Authentication. Leave Anonymous access enabled, but clear the Basic authentication and Integrated Windows Authentication checkboxes. Clearing these checkboxes essentially disables the Auth command on the SMTP server. Enable relaying for other internal Exchange Servers. If you have other internal Exchange Servers, make sure to enable relaying for these servers. On the Access tab, click Relay, select Only the List Below, and explicitly list the internal mail servers that are allowed to relay to this mail server. This action ensures that the internal mail servers can send mail to this server.
After making these changes, thoroughly test the configuration. Test mail flow to and from the Internet and to and from all mail servers in your organization. These changes have the potential to break mail flow between servers, so you might want to wait until the weekend to make these changes. Better yet, test these changes in a lab environment before implementing them in production. I strongly suggest that you take these steps and make these changes. If a hacker ever gets a valid user ID and password and is able to relay mail, your mail server will get put on various email blacklists; you'll spend significantly less time preventing these attacks than troubleshooting mail delivery problems, getting removed from blacklists, and fixing the vulnerability.
Running any VPNs? Make sure to use at least 3DES or Advanced Encryption Standard (AES) to encrypt your data. DES encryption keys can be broken in less than 1 day using a network of 100,000 PCs on the Internet. As of this date, 3DES has not been cracked and AES is even more difficult to crack than 3DES. See http://www.eff.org/privacy/crypto_misc/descracker/html/19990119_deschallenge3.html for more information.