6.1. Mail Server Attacks

Mail servers are juicy targets just like DNS and web servers, and for similar reasons. These servers all provide important functionality for individuals outside of the organization. They are widely publicized, which makes them easy to find and attack.

Mail servers may be attacked to establish a foothold in an organization's network or merely to acquire a staging ground for other, unrelated attacks. Such attacks aren't specific to mail servers alone, and attackers in this case are generally seeking an exploitable condition that will provide access to the operating system. These attacks are typically the first thing system administrators worry about when deploying any service. A compromised operating system means a system rebuild and subsequent analysis. If the system was a staging ground for other attacks, other systems may need rebuilding as well.

Mail servers are also subject to attacks by individuals who wish to exploit the mail service itself. The most obvious example is the use of an organization's mail server to deliver unsolicited commercial email. This kind of attack can succeed when a mail server accepts all incoming messages and sends them to any destination an "open relay" configuration. In this case, the operating system is not under direct threat, but being an open relay may lead to a denial of service (DoS) attack due to the volume of incoming mail or being blacklisted by other organizations. The side effects of being blacklisted may include angry customers, lost productivity, lost sales, and negative publicity.

Finally mail servers sometimes play the role of oblivious accomplice. Despite operating properly, mail servers assist in the delivery of computer viruses and worms that can wreak havoc on an organization's network, infrastructure, and client systems. "Experts" often quote dollar figures in the billions when referring to damages caused by viruses. This may or may not be accurate, but viruses have certainly brought massive organizations to a standstill for days. The Melissa virus in 1999 infected several Fortune 500 companies causing major damage. Hundreds of other companies disconnected from the Internet in fear. Building a virus-resistant mail infrastructure that allows for rapid response, even before antivirus vendors publish updates, should be a requirement for any security-minded system administrator.

Viruses and Worms

The terms virus and worm are often used interchangeably. While they both refer to malicious code, or malware, there is one key difference. Worms do not require any user action in order to propagate, whereas viruses often require that a user execute some program. RFC 1135, The Helminthiasis of the Internet, discusses the propagation of the Internet Worm of 1988 (The Morris Internet Worm). It defines the terms virus and worm as follows:

"A `worm' is a program that can run independently, will consume the resources of its host from within in order to maintain itself, and can propagate a complete working version of itself on to other machines."

"A `virus' is a piece of code that inserts itself into a host, including operating systems, to propagate. It cannot run independently. It requires that its host program be run to activate it."

6.1.1. Operating System Level Attacks

One of the most notorious operating system level exploits in networked computing came as a result of an SMTP-initiated debug mode built into an early version of sendmail. The Morris Internet worm was released on November 2, 1988 and proceeded to exploit sendmail and fingerd to gain access to systems. Sendmail has been the target of several other OS-level attacks for one key reason: it runs as root. Exploiting a vulnerability in the sendmail daemon listening on port 25 of any mail server may eventually lead to a root shell on a system.

While the debug code was stripped from sendmail, vulnerabilities continued to be published for years. A quick survey of the Bugtraq SecurityFocus mailing list turns up a variety of local privilege escalation, remote compromise, and denial of service attacks possible against Sendmail over the years. The techniques used fill the entire spectrum: buffer overflows, removing or hard linking to key files, exploiting poor configuration, passing in illegal arguments, and so on.

Of course Sendmail is not the only piece of mail software with vulnerabilities. A search on http://www.securityfocus.com/ will quickly turn up a few Postfix and qmail advisories. Fortunately these are remote denial of service vulnerabilities and less severe than remote root compromises.

The good news is that the vulnerabilities in mail software that give rise to operating system level attacks can often be mitigated by small configuration changes, software patches, and/or upgrades.

6.1.2. Illegitimate Mail Relaying

Mail administrators appear to be particularly prone to deploying open relays, judging from the sheer volume of servers that match this description in blacklists. This is often due to uninformed, lazy, or sloppy configuration, but even conscientious administrators can accidentally create an open relay configuration.

In a multiple-server site in which one external mail server is responsible for communicating with the outside world and additional internal servers house mailboxes, the external server often implicitly trusts all internal hosts. The internal hosts for their part pay little attention to mail routing and merely pass all mail to the external server. If the internal servers also allow connections from external sources, anonymous external users may pass messages to an internal server that forwards the message to the external server, and the mail will be delivered. Despite diligence during server configuration, sloppy architecture can lead to open relays.

In 1995, Matt Wright wrote a small Perl script to be used as a backend for "contact us" pages on the Web. The script received certain variables from a web page in the form of an HTTP POST or GET request as shown in Example 6-1, and would create an email message to be delivered to a recipient configured in the HTML page.

Example 6-1. HTML "contact us" sample snippet using formmail.pl

<html><head><title>Contact Us</title></head><body> Please fill out this form and we will get back to you shortly.<br /> <form name="contact" method="post" action="/cgi-bin/formmail.pl" />  <input type="hidden" name="recipient" value="[e-mail]" /> <br />  <input type="text" name="realname" /><br />  <input type="text" name="e-mail" /><br />  <textarea name="comments" rows="5" cols="4" wrap="virtual">  Please enter your comments here...  </textarea> </body> </html>

In 2001, web sites around the world were using Version 1.6 of this script, yet it contained little in the way of security checks. In fact by typing in the URL in Example 6-2 and providing known parameters in the URI, users could anonymously send mail anywhere.

Example 6-2. Exploiting formmail.pl Version 1.6

 http://your.server.com/cgi-bin/formmail.pl?recipient=dest-addr@anywhere. net&message=This%20is%20SPAM.&realname=Anyone&e-mail= [e-mail]

Early versions of formmail.pl did not attempt to verify that the request came from the local server and would quietly generate and send email. Subsequent fixes to the formmail.pl script to add REFERER checks were marginally effective but still exploitable.

The point here is that if you attempt to deploy your mail servers in a vacuum without considering the surrounding architecture, you may one day be surprised to find you're part of the problem.

6.1.3. Unwanted Mail

There are two categories of unwanted mail: common unsolicited commercial mail, and malware. Finding these kinds of messages doesn't indicate that your server is being attacked, they just utilize mail transport as a means of efficient delivery. However, unwanted mail consumes resources, reducing the amount of legitimate mail your servers are able to process and reducing the effectiveness of your organization's users. Don't pass by "consumes resources" without giving it serious consideration. Many organizations, after putting in place spam and virus blocking software, suddenly discover that they are rejecting three to ten times as much email as they are accepting. That's anything but a drop in the bucket.

Malware can be viruses, worms, or spyware hidden in email messages that exploits bugs in code (generally on client workstations) and is often propagated by users. While unwanted mail may lead users to point their fingers at poorly configured mail servers, the servers themselves are not particularly to blame for the propagation of unwanted mail. Nevertheless, when you need to stem the flow of spam and malware into your network and you know that mail is one of the key vectors that viruses and worms use to attack that software improving your mail system's ability to stop unwanted mail becomes an appealing goal.