Dangers Associated with Mail Service Attacks
Some of the dangers associated with mail service attacks are not outwardly evident. Mail service attacks differ greatly in their approach just as they differ in their motivations. Using mail service attacks to fuel malicious intent, attackers are often able to use e-mail as their vehicle for crimes such as identity theft and fraud. Other attacks use e-mail in order to prorogate information, possibly about a service or a product. Pornography and male enhancement drugs are a common theme among spam propagators.
Scams such as phishing allow attackers to collect personal and even financial information about your users. Phishing is a tactic that can only be partially protected against with technology solutions. System users should also assist in protecting against phishing attacks by becoming educated and understanding a phishing attack when they see one. Without the willingness on the part of the user to submit and offer up the sought after data, attackers would come up empty handed even if the phishing e-mail were to pass any e-mail system security screening measures put into place.
alt2 Epic Fail
Recently, the well-known social networking site Facebook was a victim to repeated phishing attacks (www.msnbc.msn.com/id/30749501/ns/technology_and_science-security). The targeted users were sent an e-mail message that contained links which would redirect users to a fake Facebook page requesting them to login again, feeding their passwords straight to the malicious assailants. The intent of the attackers is likely to collect user's personal information for identity theft or other fraudulent activity. Facebook took defensive measures by blocking the links in the e-mail messages and also by cleaning up the spam messages on user's walls and in user's mailboxes.
Since no form of protection against mail service attacks is completely bullet proof, a portion of the responsibility falls with the system users to behave in a responsible manner. Unfortunately, since the users interacting with the messaging system are the principal component involved in mail service attacks that connect cannot be configured or modified by administrators if a malicious message does make its way to a user's mailbox, the results in behavior are often varied. Understanding what message types are legitimate and which are apparently fraudulent or malicious is something that can be taught through training and awareness programs.
alt1 Note
As administrators, we interface primarily with the technology. We deploy it, maintain it, and replace it when necessary. We are its keepers. However, one thing we sometimes fail to do is to educate users on the best practices associated with it. By taking the time to assist with the development of training courses as well as defining a written policy focused on technology usage in an organization, we can help to better protect the organization.
Also, misconfiguration of Exchange Server can lead to successful mail service attacks. Understanding how to properly configure Exchange in a defensive manner is critical to protecting your organization from these malevolent attempts. In the following sections, we will review a few types of mail services attacks. Once we understand more about how these attacks may be carried out, we can begin to discuss what measures may be taken to defend against them.
Scenario 1: Directory Harvest Attacks
Directory harvest attacks occur when an attempt is made to collect data from the AD services, which is where Exchange stores most of its user-related messaging specific information. The purpose of a directory harvest attack is to collect a key piece of information from your directory services, namely valid e-mail addresses. By knowing which e-mail addresses in an organization are valid, spammers can target messages at legitimate user accounts without generating as much negative attention.
Directory harvest attacks are often performed by submitting large numbers of e-mail addresses with very little content to an organization. The e-mail messages are randomly generated, but commonly used e-mail aliases. The concept is that if the e-mail message is not returned in an NDR, then the message must have been delivered, making it a valid address.
Individuals or entities that specialize in generating and propagating spam may collect these directory harvest lists as a precursor to launching a spam attack. With a listing of valid e-mail addresses, the penetration rate of the attacks will be much higher amongst the target audience for the spam message. Also, it is possible that once an attack has collected a directory harvest list, selling of the list for unethical and possibly even illegal purposes may occur.
One feature of Exchange Server, which specifically combats against directory harvest attacks, is called tarpitting. Tarpitting is the practice that involves delaying the response back to a connected SMTP server. In order to understand how tarpitting works, we must first describe the communications exchange between two servers attempting to communicate via SMTP.
When an SMTP server connects to deliver an e-mail message, the communication involves establishing the language the two machines will use. SMTP is the protocol that will be used, but it comes in two flavors: regular old vanilla standard SMTP and the newer and improved chocolate chip variety, Enhanced SMTP. The connecting server will specify which of the two it prefers at the beginning of the communications session by beginning with either a helo command for standard SMTP, or an ehlo command for Enhanced SMTP. Today, many servers are configured to open with ehlo, especially since Enhanced SMTP is more feature rich and therefore is preferred, but if the case arises where the opposite server does not understand the ehlo command and an error is generated, then helo will be attempted instead so that communication can proceed.
After the protocol negotiations are completed, the next step is to provide recipient information. First, the sender is specified using the “mail from:” command and second, the recipient is specified using the “rcpt to:” command. If the server is an Exchange server, or a server configured to perform recipient lookup functions, a directory lookup is then executed to determine the validity of the recipient and the results are returned.
If the recipient is successfully located in the directory, the response from the Microsoft Exchange server will consist of a “250 2.1.5 Recipient OK,” letting the connected SMTP server know that the address submitted is valid. If the address does not exist in the directory, then the response will be an SMTP session error of “550 5.1.1 User unknown.” These are desired behaviors since valid addresses should pass through to be received, whereas unknown users should be rejected. One thing to consider is that unknown users may be the result of a simple typo error in the e-mail address on the part of the sender, so the response of “user unknown” is important because it allows the e-mail system the opportunity to send the message back to its originator along with the reason for rejection, giving the user the opportunity to correct the mistake and resend.
Now let's introduce a directory harvest attack attempt into this communications interchange. The purpose of the attack is to discern functional addresses from fictional addresses. Therefore, the default behavior of the server to perform directory lookups and respond with the validity of a particular address is exactly what the attacker needs and anticipates will occur. By a submitted battery of addresses for inspection, the attackers can easily and efficiently sort their attempted addresses into two piles: valid and invalid address. So how can administrators combat against this type of attack while still allowing valid directory lookups to occur?
Tarpitting is one method of deterrent build directly into Exchange 2007. Tarpitting forces a delay between the time a recipient is submitted for acceptance to the SMTP server and the time when the response is sent back. The time delay has nothing at all to do with the responsiveness of the directory server. Regardless of the time that it takes to receive the response back from the directory server, the SMTP server will impose a preconfigured delay before delivering the “250 2.1.5 Recipient OK” or the “550 5.1.1 User unknown” response. This delay does cause a directory harvest attack to become cumbersome to execute due to the shear duration required to extract information.
Think about how many combinations of John Smith are possible in an e-mail address: jsmith, johns, josmith, johnsm, jbsmith, jcsmith, john_smith, john.smith, j.smith, j_b_smith, etc. Even with few John Smiths working in the organization, there are numerous combinations that may be valid, so the purpose of the directory harvest attack becomes to determine which combination is accepted. By throwing as many combinations at the system in rapid succession as it takes in order to receive a successful response, the attacker is able to abuse the default directory lookup behavior and obtain directory information.
With tarpitting in place, let's say that each one of those possibly takes 5 seconds or more for a piece to be processed and returned. The return of the attack diminished greatly because the time taken to determine John Smith's actual e-mail address, which was a matter of seconds earlier, may now take many minutes or even hours to obtain even a single valid address.
alt1 Tip
In order to minimize the chances of a successful directory harvest attack, you should take the time to perform some market research. Many applications, such as Symantec Brightmail Gateway (www.symantec.com) and Cisco Ironport (www.ironport.com), exist today that have the capability to recognize a directory harvest attack and stop it in its tracks. Since in most cases directory harvest attacks originate from the Internet, as the administrator you can be proactive by deploying an application or appliance in your perimeter network that has the capability to detect and stop directory harvest attacks. Most of these appliances are intended to be the first point of connection for any inbound messaging traffic and in addition to detecting directory harvest attacks, should also be equipped to run antivirus and spam checking, as well as be able to recognize and react to other attack types such as DoS attacks.
Scenario 2: SMTP Auth Attacks
Secure-by-default has been mentioned on more than one occasion here, and in the world of Exchange Server each new version introduces changes that continue to revamp the security by default landscape. One of the Exchange 2007 security modifications came as a result of the SMTP Auth attack, which became common and quite successful when used against Internet facing Exchange 2003 servers.
By default, with an out-of-the-box configuration, Exchange 2003 was configured to deny relay attempts. This was a step in the right direction, with one small caveat: Exchange 2003 would allow relay for any authenticated user. So, enter the SMTP Auth attack. By connecting to an Exchange server and launching a password attack against any of the built-in user accounts, an attacker would eventually obtain authenticated user credentials. Since authenticated users were allowed to relay, the attacker now had the ability to send as many e-mail messages as desired to the Internet through the compromised Exchange server.
SMTP Auth attacks depend on two different factors falling into place. The first factor is that Exchange must allow for authenticated relay to occur. Since this is the default configuration in Exchange 2003 unless an administrator has altered the settings by unchecking the box on the SMTP Virtual server that allows for this, then authenticated relay will be allowed on Exchange Server 2003. The best way to reduce your attack surface against SMTP Auth attacks is simply not to allow for authenticated relay. By only accepting anonymous connections, attackers will never have the opportunity to present the password attack on built-in user accounts. The Exchange server can utilize other means to validate a connecting entity, such as an IP access control lists, to determine if the requested relay is to be accepted or rejected.
The second factor required for an SMTP Auth attack to be successful is related to the user names and passwords that the attacker will attempt to exploit. When launching an SMTP Auth attack, an attempt will be made to authenticate, often by utilizing well-known accounts. By renaming well-known accounts, you can help to protect against their abuse. Also, since a password is required for successful SMTP Auth, a brute force password attack may be used to attempt to ascertain the password of the well-known account. In general, it is always a good idea to secure all accounts with complex passwords. Using a combination of uppercase, lowercase, numbers, and symbols in your passwords makes them more difficult to attack. Also, by choosing a password with a length of 15 characters or greater, you increase the security by preventing the local system from storing the password in a usable LMHash.
An SMTP Auth attack occurs when an attacker connects to a mail server and begins an SMTP conversation. A classic method for making this connection is by using the Telnet Protocol and by specifying port 25. The following is an example of a Telnet command that may be used to connect to an Exchange 2003 or Exchange 2007 Hub Transport server:
telnet mailserver1.smeekers.com 25
By adding the port number 25 at the end of the telnet command, the telnet client will connect to the Exchange SMTP services on port 25 instead of using the default telnet port 23 during the connection attempt. Once the connection is successful, the SMTP Auth attack can begin. By beginning the SMTP conversation with an ehlo[A] command, the target server will respond with its SMTP banner and the attack is now ready to proceed.
Ahttp://tools.ietf.org/html/rfc1869
By specifying the command auth login, the Exchange server will understand that an authentication request has been made and will return a prompt requesting the username and then once a valid username has been entered, the server will prompt for the matching password. One thing to be aware of is that once the auth login command has been issued, the remainder of the conversation is held in base64 encoding, so providing a username and password requires a tool to translate the plain text information into base64 encoding so that the server will understand the input. There are plenty of freeware and shareware tools available on the Internet for download that will allow you to perform this function. Some examples include Base64 Encoder/Decoder by Elcro (available at www.elcro.com/software.aspx) and EB64 (available at www.dlcsistemas.com). An example of a telnet-based SMTP authentication is displayed in Figure 4.2.
FIGURE 4.2. Sample SMTP Auth Attempt
With the release of Exchange 2007, Microsoft responded to the concerns around SMTP Auth attacks by providing administrators more options for relay control than those that existed in Exchange 2003. With Exchange 2003, you could either manually specify, which users or computers were allowed to relay, or retain the default value that allowed all authenticated users to relay mail traffic. Any account granted relay capabilities was still required to authenticate. Available authentication mechanisms included anonymous (no username or password required), basic authentication, and integrated windows authentication. The introduction of Exchange 2007 changed the way Exchange mail systems handled mail relay connectivity by introducing a component called a receive connector.
Receive connectors in Exchange 2007 exist individually on a per-server basis and allow external mail systems to connect inbound to Exchange. In order to use a receive connector, two things are required: successful authentication and permissions on the receive connector. By allowing additional authentication controls such as Transport Layer Security (TLS), Mutual TLS, and Exchange Server Authentication, receive connectors help administrators adhere to a higher security standard while still broadening the scope of accepted connections. Figure 4.3 displays the Authentication tab from a receive connector with Externally Secured (for example, with IPsec) selected. This option is utilized when security is to be provided by an outside source, such as IPsec, which cannot be verified by Exchange. Receive connectors that are intended to be used by a disparate e-mail infrastructure or by an Internet facing appliance may be configured in this way.
FIGURE 4.3. Exchange 2007 Receive Connector – Authentication Tab
By default, permissions to use the default receive connectors are already granted to Exchange Users and Exchange Servers in the enterprise. In addition, you may indicate which of the predefined groups are able to access and utilize the receive connector. Without proper permissions to utilize the connector, even with successful authentication, access will be denied. Figure 4.4 displays the Permission Groups tab of a receive connector.
FIGURE 4.4. Exchange 2007 Receive Connector – Permission Groups Tab
Scenario 3: Mail Relay Attacks
One of the most common attack a scenario attempted today is the mail relay attack. Mail relay attacks allow your mail servers to be utilized to deliver mail traffic originating from some other location, which usually consists of spam and other unwanted, unsolicited, or even illegal mail.
Mail relay attacks can impact your environment in multiple ways. The first obvious impact is on the performance of your mail servers. Often times, once a malicious attacker has discovered this vulnerability or misconfiguration in your mail systems, your servers may be used to transmit millions of additional e-mail messages a day. When designing your messaging infrastructure and allowing for message load, considerations would not have been given to such an additional burden and the probability is that the performance of your messaging systems will be drastically impacted by the additional mail relay traffic.
alt1 Warning
Often time, if an unauthorized mail relay is targeting your Exchange servers, the occurrence may go unnoticed. It is important to include a monitoring solution that allows for Exchange- specific configuration so that scenarios such as authorized mail relay can be identified and addressed.
SMTP Auth attacks as discussed in the SMTP Auth Attacks section earlier in this chapter are a method of obtaining access into a mail server infrastructure in order to execute mail relay attacks. Typically, the primary purpose behind mail relay attack executions is to disperse spam messages out onto Internet servers and into unsuspecting user mailboxes. Many defensive systems today track trends over time, and many of them use metrics based on source IP address in order to determine the probability of spam when screening e-mail traffic. Since the malicious attacker is utilizing your servers to send out spam e-mail, the systems that utilize tracking mechanisms based on IP address will start to document a spam trend originating from your source IP addresses. This can lead to your systems becoming blacklisted and your servers will no longer be trusted, which would potentially cause legitimate e-mail messages from your environment to be rejected or dropped. Some common rating systems include SenderBase by Cisco Ironport (www.senderbase.org) and the Sender ID Framework, which has been adopted by Microsoft as well as by many other industry partners.
In order to assist with combating the gargantuan amounts of spam that are forwarded around on the Internet each and every day (see Table 4.1 for some common mail service spam tools), administrators should consider implementing the usage of Sender Policy Framework (SPF) records in DNS. SPF records in DNS are a method used for validating that only authorized servers are senders of e-mail messages from a particular domain. By utilizing SPF records as a verification mechanism, administrators can reduce the amount of spam messages they process since only trusted entities would be allowed to submit mail for delivery. Implementation is a two-step process, including configuring your system's Internet facing services to utilize SPF records in order to validate the source of received messages, and the second part consists of configuring your organization's SPF records so that other enterprises can validate your e-mail stream.
Table 4.1. Common mail service spam tools
| Product | Reference Web site (if applicable) | Comments |
|---|---|---|
| Advanced Mass Sender | N/A | Originally designed as a mass e-mail marketing tool |
| Send Safe | www.send-safe.com/send-safe.html | |
| Dark Mailer | www.theregister.co.uk/2008/07/23/soloway_sentenced/print.html | One of the Internet's largest spammers, Robert Soloway utilized this tool in many of his spam attacks |
| Reactor Mailer | www.darkreading.com/security/encryption/showArticle.jhtml?articleID=211201479 | Exists as the server side component to one of the largest spam sending botnets in the world |
Mail relay attacks were commonly successful in earlier versions of Exchange Server, primarily because Exchange was not configured to deny this behavior by default. Exchange 5.5 specifically would allow you to enable “Reroute incoming SMTP mail,” which would create an open-mail relay scenario. Even though the product offered the capability to additionally select “Routing Restrictions,” which would allow the administrator to lock down and limit relaying, many messaging administrators either weren't aware of how to configure the restrictions or would end up misconfiguring the settings, resulting in an open-relay configuration.
With the inception of Exchange Server 2007, Microsoft introduced new ways to help administrators control and protect against the possibility of unwanted and unauthorized mail relay. In scenario 2 of the section “SMTP Auth attacks,” we discussed the concept of receive connectors, which covers one aspect of managing mail relay. Another feature intended to simplify how Exchange deals with mail relay is called the Accepted domain. Accepted domains are the administrator's tool to identify and categorize domain names in order to dictate specific relay behavior. If a domain name is not listed as an Accepted domain in the Exchange environment, then mail traffic for that domain name space will not be accepted by the Exchange servers. There are three configurable types of Accepted Domains:
If a domain name is configured as Authoritative, then Exchange will assume ownership of the domain and all inbound mail messages matching the namespace will be accepted. They will be compared against the AD infrastructure for deliverability, and if the destination address is not configured on a mailbox with the Exchange organization, then an NDR will be generated. If the mailbox does not exist within Exchange for an Authoritative namespace, then the mail message is considered undeliverable.
Internal relay domains allow Exchange to first attempt delivery within the Exchange organization, and if a mailbox does not exist, then the mail message may be routed to a separate mail system. Internal relay domains require a Send connector to allow outbound delivery. Internal relay domains are often used when namespace sharing exists in an environment, such as when a company is migrating from Lotus Notes (www-01.ibm.com/software/lotus/notesanddomino) or Novell GroupWise (www.novell.com/products/groupwise) to Microsoft Exchange and both the source and target domain namespaces are the same. External relay domains are intended to be used to deliver mail messages to domains external to the Exchange organization via the Exchange Edge servers. Figure 4.5 displays the New Accepted Domain wizard, showing the three configurable options when adding a new Accepted domain.
FIGURE 4.5. Exchange 2007 New Accepted Domain Wizard
The Future of Mail Service Attacks
As Microsoft continues to develop their products to follow a secure-by-default model, we shall continue to see the attack surface for mail attacks on Exchange Server reduced. This will continue to make many of the mail service attacks in existence today become more difficult to execute and therefore less common. However, other things also contribute to the future of mail service attacks such as trends in the industry, product vulnerabilities, and just the overall creative nature of users with malicious intent.
Product vulnerabilities are typically patched as they are discovered, and even though it is inevitable that new bugs will be discovered in the future, which may be exploited, Microsoft will continue to release patches for supported products as they are found. One of the larger things that will always allow for mail service attacks to continue evolving is related to messaging systems administration. Even though Exchange Server installs in a secure-by-default configuration, in order to continue to be adaptable to different customer scenarios, Microsoft must allow the messaging administrator the flexibility of adjusting or bypassing many of the default configurations. This will continue to result in attacks that are able to successfully take advantage of systems that are left exposed based on misconfigurations or unsecure deployments. Since there is still a messaging administrator involved in the configuration of most corporate systems, it is important that education be sought out by system administrators and product awareness be driven within administrative circles.
One noted shift in messaging in the enterprise that will continue to change the landscape of how mail service attacks are carried out is the industry trending toward hosted e-mail services. More companies are looking to move their messaging infrastructure into the cloud to be hosted by Microsoft or other third-party vendors in order to reduce their internal costs and complexity. As more systems are moved into this cloud-based hosted service model, the nature and composition of mail service attacks is destined to change in order to adjust the newly formed attack surfaces presented in a hosted model.