Exposing Weaknesses: E-mail Abuse

As with many aspects of an Information Technology (IT) infrastructure, e-mail has been a target for crackers and abusers since its inception. Though some crackers still attempt to infiltrate organizations' mail systems through their MTAs (often to perform a type of industrial espionage), this has largely been curtailed by MTA software improvements and more responsible IT workers. Generally, the purpose of attacking MTAs is to provide the attacker with the capability to send unsolicited commercial e-mail (UCE), or spam. Reports vary widely on the ratio of spam compared to total e-mail across the Internet; however, one trend holds true regardless of the source: spam is increasing in volume and complexity. However, spam is also decreasing in its overall effectiveness as a result of anti-spam mechanisms put in place by Internet service providers and other organizations. Regardless, studies suggest that offers enclosed in spam messages have a commercially viable success rate and, therefore, spam is a business that won't be going away quickly or without a fight. Explanations of several spam transmission mechanisms are included herein. These methods include open relay use, open proxy use, use of compromised MTAs, and finally, spamming through systems controlled by some sort of semiautonomous Trojan deposited in advance by viruses or worms (bots and botnets ).

Open Relays and Proxies

One of the earliest and easiest methods for spammers to send UCE or spam was to find an MTA that allowed unauthenticated relaying. MTA servers allowing this to occur are referred to as open relays. If an MTA was an open relay, spammers found they were able to send e-mail through the MTA and could often spoof the source (From:) address to be from any address desired. In order to find these open relays, scripts were developed to automate the process. A spammer could easily find several open relays across the Internet with the simple execution of a script.

Administrators at the enterprise and Internet service provider level began using a series of filters and SMTP authentication on MTAs. Authentication helps to ensure clients sending outgoing e-mail are properly authorized and authenticated for MTA use. In addition, port TCP/25 is often filtered by large Internet service providers, forcing clients to use the providers' MTAs. These MTAs require authentication and the spammers had to find alternative means to send spam.

As administrators became wise to the tactics of open relay abuse and began taking steps to protect against it, spammers went a step further. As long as a system was capable of sending e-mail, a spammer didn't care whether the system was the organization's actual MTA or not. As long as the system was capable of sending SMTP traffic, it suited the need. Spammers began looking at other publicly available services and found proxies to be a viable and available solution. Many of these proxies allowed not only simple web (HTTP) services but also proxy access for SMTP. Spammers now had a completely new technology source for sending spam.

Compromised MTAs

Compromised MTAs are possible because even the best-written software will have bugs. These bugs sometimes manifest themselves as security vulnerabilities, often because of predictable and common software defects (for more information, see Chapter 18). Attackers customarily create scripts to test systems for security vulnerabilities after an exploit is published. If a server is not patched or properly secured, attackers using these scripts may find it possible to attack and subsequently compromise a system. Spammers find this to be a method to gain access to an MTA even if the MTA does not allow unauthenticated relaying, and so on. Once an MTA is compromised, a spammer can use the system for whatever purpose he or she feels is necessary, including sending spam.

For an MTA compromise example, we will look at Sendmail, one of the most popular MTAs available (both commercially and through open source licensing). In late 2003, a buffer overflow vulnerability in various Sendmail versions was published (one of many in Sendmail's tenured service as one of the most popular MTAs available). This vulnerability allowed remote attackers to execute code with privileges equivalent to the Sendmail daemon (which may be running with the effective privileges of "root," the superuser). By sending an e-mail with specially crafted message contents, an attacker could exploit a buffer overflow in the prescan( ) function of Sendmail. (Depending on the platform and operating system, this could lead to code execution with escalated privileges.) In this example, the attack vector was an actual e-mail message sent to e-mail servers. The e-mail message may be sent directly to a Sendmail MTA or pass through a "non-Sendmail" system without issue and be sent on to a Sendmail system, thereby exploiting the vulnerability.

Once this vulnerability was exploited, the proper circumstances could provide attackers with escalated privileges on the vulnerable system. These escalated privileges could be used to install backdoors, making further compromise possible or any number of other possibilities. At this point, the compromised server should not be trusted and should be cleaned (oftentimes meaning rebuilt), causing lost time for administrators and possibly downtime for organizations' users. (For more information regarding this example of compromise, please see CERT Advisory CA-2003-25 at http://www.cert.org/advisories/CA-2003-25.html.)

Infected Systems

Many viruses and worms use the same mechanisms for compromising a system as manual attackers. The worms are used as the mechanism to find and exploit security vulnerabilities. One difference with viruses and worms is that MTAs are not the only target. In today's world, worms are used to exploit a system through any vulnerability that will allow privilege escalation. Once infected, the worm delivers a payload compromising the system and in many cases installing a Trojan horse-like program, effectively converting the system to a bot acting as part of a larger bot network (botnet). A system acting as part of a botnet receives instructions from a command and control host to which it reports. These instructions can include a number of items, but for the focus of this chapter, the instructions may include sending spam. (For more information on bots and botnets, please see Chapter 17). Many times these botnets include instructions for using native embedded MTAs, which will allow the very host to send the spam, not requiring spam to funnel through an organization's MTA. Now, instead of worrying solely about MTAs from a spam protection perspective, an administrator must defend against any system capable of being infected by a worm or virus, which ultimately is every system connected to the organization's network.

Now that we have discussed various methods of attacks and how attackers and spammers can compromise organizations' resources to send spam, the remainder of the chapter will focus on how to minimize an organization's chances of becoming compromised as well as the ability to reduce the amount of incoming spam.