by Rik Farrow <rik@spirit.com>
Email is trouble. While email itself is one of the most important enabling technologies of the Internet, it is also one of the most commonly abused. There are the everyday abuses such as email from non-existant addresses promising to make you rich or sexy. And, there are viruses that travel as email attachments, including the exceptional virulent ones, like ILOVEYOU or Melissa.
And then there are the email headers themselves. You will certainly be accustomed to seeing some of these email headers while reading your email, lines beginning with To:, From:, and Subject:. But there's more to email headers than what your friendly mailtool has been willing to show you, and the information in the other headers can be very revealing. Your headers can reveal the name and version of the mailtool you use, the operating system you use, the name and version of your mail server, internal IP addresses, and the type of firewall your organization uses (if any).
For these reasons, it is time to examine email headers, and get a better idea of why they are used, the information they contain, and why some firewalls actually remove some of the information found in these headers.
Like anything used on the Internet, email headers are governed by a standard, in this case RFC 822. A separate RFC, 821, defines the envelope and transport of email, but that is not our concern today. RFC 822 was written to replace an earlier attempt to define a standard (RFC 733), with the goal of making it possible to send email between different networks. So the headers I am talking about are required for sending any email across the Internet, or even between two internal email servers that are using TCP/IP and are not using a proprietary format.
To help you understand what we are talking about, take a look at Figure 1. You may also be able to view email headers using your mailtool. For example, if you use Outlook, select the View menu, and Show Fields to see a dialgoue box with the names of some the fields that may appear in email messages.
Each header begins with a fieldname, which is always followed by a colon and a space, such as To: or Received:. Long header lines are 'folded', that is, represented as multiple lines, with each additional line beginning with one or more spaces. In Figure 1, the first header field is a Received field that actually extends for three lines, then is followed by another Received field, which also extends over three lines.
Some of the fieldnames specified are simple and self-explanatory, such as the Date:, To:, Subject:, and From: header fieldnames. For example, the return address appears after the From: fieldname, and the receipients address appears after the To: fieldname. SMTP (Simple Mail Transport Protocol, RFC 821) does not require that the address appearing after the From: fieldname accurately represent the sender. SMTP really has no way to check to see if the sender is using his or her own address, although most mail server software today will at least verify that the sender's domain exist. The lack of verification is what makes it easy to spoof the sender of email, something you will usually see in spam.
When you are trying to learn something more about the sender of email, the Received headers are much more interesting than the From: header, as that can be spoofed. To be accurate, any of the header lines can be tampered with up to a point, as the headers are just textual data, and only the headers added by servers that you trust can be considered reliable. Received headers are added by each mail server that relays the email, with the most recent email server first, and the first mail server that relayed this email last. In figure 1, the first Received header shows that bear.spirit.com/ received email for rik@spirit.com from the server 0nus.l0pht.com.
This first header also provides some other interesting information. Data that appears within parentheses, such as (0nus.l0pht.com [199.201.145.3]), are treated as comments by compliant mail servers. In this case, sendmail running on bear.spirit.com/ has verified that the sending system is really 0nus.l0pht.com using IP address 199.201.145.3. Sendmail information from the TCP/IP connection to get the IP address, and then used DNS to look up the domain name of the server.
The second Received header is more interesting. Note that the email is received from [172.16.1.75], an absolute IP address by the system 0nus, which still appears at 199.201.145.3. IP addresses that begin with 172.16 are Private Network Addresses (RFC 1918), which can be reused and are not supposed to be routed across the Internet. This Received header tells us that 0nus is functional as the l0pht's firewall (or a part of it), and is performing network address translation (NAT). This Received header also informs us that 0nus is running Postfix, a new mail server written by Wietse Venema with an emphasis on being as secure as possible.
The example email header shown in figure 1 only has two Received headers. Sometimes there are many more, and those headers may reveal other internal network addresses, mail server names, as well as internal hostnames. The Received lines are important, as they are used to detect loops, where one mail server forwards email to another, which sends it right back again creating a loop. But the Received lines also contain a lot of data that may be interesting to an outside attacker.
So far we have identified two mail servers, sendmail and Postfix, from the Received headers. Microsoft Exchange and Lotus Notes also leave their mark in the Received headers, as do other UNIX mail servers.
We have also noticed that 0nus.l0pht.com is possibly part of the l0pht's firewall. In some cases, identifying the firewall is much easier than having to guess. Sometimes, the firewall will be named 'firewall', 'eagle', 'fw1', or some other easily recognized name that will show up in the Received headers. But some firewalls, for example Interlock, actually advertise their presence by adding a comment to the Received line (see figure 2). Another vendor's firewall added a less revealing line mentioning that "Private Information was Removed", but only that one vendor used that specific comment, making it almost as obvious as the Interlock firewall.
The Received headers are there for a reason--analysing email problems. Removing these headers is not considered good netiquette, but some firewalls do remove them, sometimes as an administratively controlled option. I consider removing these headers for email leaving your organization to be a reasonable act, as you should be responsible for email problems within your organization, and you don't really expect (or want) outsiders to be analysing your email problems (and network layout) for you. Yet. not all firewalls allow you to do this (and generally, only those that have application gateways will be clever enough to do this correctly).
RFC 822 actually requires Received headers, so removing them would be against the intent of the Internet standard. In private email with some support staff at sendmail.org, a consultant suggested a method for removing the Received headers selectively, by using a modification to sendmail and a configuration file containing the addresses of servers to remove. The support staff at sendmail decided that this modification would be against the spirit of the RFC, but did suggest that instead of deleting the Received headers, information in them could be obscured by replacing internal information with hashes.
There have been attacks designed specifically to take advantage of mistakes in parsing the headers. Most recently, Microsoft put out a patch for a module named inetcomm.dll used to parse the Date header (among other things), and used by Outlook and Outlook Express. With an overly long Date field, both mailtools could be crashed, or even coerced into executing arbitrary code (if the data sent contained a buffer overflow exploit).
How do you know if someone is using Outlook or Outlook Express? You can look for an x-mailer header. In Figure 1, jolly was using Claris emailer, which also tells us the he or she was using a Macintosh (Claris being a suite of applications only for the Mac). In Figure 3, the x-mailer line is even more explicit, not only telling us the name of the mailtool, dtmail, but also the version of the operating system and the hardware architecture: SunOS 5.7 sun4u sparc.
RFC 822 permits anyone to add extension headers, as long as they begin with X- or x- (header names are case insensitive). So you may also see interesting and unusual things in people's mail headers. Mail headers are begun my mailtools, such as Outlook or Eudora, which will add headers such as From:, To:, Subject:, Cc:, and X-Mailer:, and added to by mail servers, which add the Received lines as they process or relay email. If you get an open source mailtool and edit the source, you can create your own headers. Spammers simply use software that takes a static data file with fixed headers, and then connects to someone's mail server and uses it as a relay (to hide their own source), permitting them to obscure the true source of the sender. This is why when you replay to spam, the address either does not exist, or belongs to some site that is not preventing relaying.
Internet email, like most of the Internet, was not designed to withstand attacks from within. The Internet (or the ARPAnet, as it was called when RFC 822 was written), was an exciting, collaborative adventure in making computers work together over a variety of network media through the use of common protocols as defined in the RFCs. Security and the initial goals of the Internet, working interconnectivity, are still at odds with one another.
Tools that encrypt and digitally sign email, such as PGP, do not solve the problem, as these tools only add privacy to email and authenticate the sender. Email would have to be drastically changed in order to prevent some of the abuses we see today. But, you can consider filtering your email headers as they leave your site to clean them of internal information that might be useful to a remote attacker.
The Internet standard for email headers: http://www.faqs.org/rfcs/rfc822.html
Wietse Venema's Postfix mail server:
http://www.porcupine.org/postfix-mirror/start.html
Microsoft advisory about trouble in the inetcomm.dll module that parses
part of the email header:
http://www.microsoft.com/technet/security/bulletin/ms00-043.asp
Sam Spade has an option for analysing email headers looking for forged email: http://samspade.org/ssw/
Carole Fennelly's article about configuring sendmail for use on a
firewall:
http://www.sunworld.com/sunworldonline/swol-06-1999/swol-06-security_p.html
Mail Abuse Prevention System for blackholing email spammers:
http://mail-abuse.org/
Tips on using sendmail to masquerade (rewrite mail headers so that they
all appear to come from your domain rather than internal systems at your
domain): http://www.connactivity.com/~esj/sendmail/masquerade.html
Figure 1: This email header from a ficticious person within the l0pht tells us that the l0pht has some form of a firewall (at least NAT), they are using an RFC1918 net address internally, and that the sender, jolly, used Claris Emailer 2.0v3, compiled on Jan 22, 1998, to send this email to the l0pht's firewall email server, which runs Postfix. It also reveals my own email server version (sendmail 8.9.3) running on a system named bear.
Mudge, a l0pht member, contacted me in July 2003 and told be that 0nus was not part of the l0pht's firewall, just the email relay. 0nus did have two interfaces, and so could appear to be a firewall doing NAT. The l0pht was using a "transparent" firewall, similar to Sun Microsystem's SunScreen.
Received: from 0nus.l0pht.com (0nus.l0pht.com [199.201.145.3])
by bear.spirit.com/ (8.9.3/8.9.3) with SMTP id PAA00816
for <rik@spirit.com>; Mon, 12 Jun 2000 10:12:53 -0600
Received: from [172.16.1.75] (0nus [199.201.145.3])
by 0nus.l0pht.com (Postfix) with SMTP id 24A8146AB
for <rik@spirit.com>; Mon, 12 Jun 2000 12:05:45 -0500 (EST)
Subject: Some sample email
Date: Mon, 12 Jun 2000 12:06:21 -0400
x-sender: jolly@172.16.1.75
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Jolly Roger <jolly@l0pht.com>
To: <rik@spirit.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20000412370548.24A8146AB@0nus.l0pht.com>
Figure 2: Some firewalls actually add an advertisement that reveals the name and version of the email gateway software used:
Received: by interlock.changed.com/ id JAA00373
(InterLock SMTP Gateway 4.2 for wft@changed.com);
Thu, 2 Mar 2000 09:06:26 -0500
Figure 3: The X-mailer header gives away a lot of information:
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc