This chapter is from the book
This chapter is from the book
This chapter is from the book
Tracing Email and News Postings
Before heading down the messaging path and looking for tracks in the sand, let's quickly discuss how these messaging services operate. News groups and email are cousins. Descending from original siblings on pre-Internet Unix systems, they have continued to evolve in parallel, with much sharing of genetic material. Both services have the following attributes:
Simple Internet application protocols that use text commands
Store-and-forward architecture allowing messages to be shuttled through a series of intermediate systems
Message body composed entirely of printable characters (7-bit, not 8-bit)
Human-readable message headers indicating the path between sender and receiver
You'll need the assistance of systems administrators, perhaps on every system the message transited, and they won't be able to help you unless they have logging information on their messaging hosts. If the originator wants to cover his or her tracks, determining the real sender of either bogus news postings or suspicious email can be challenging. News is probably a bit easier, but email is more common today, so let's start with it.
Tracking Email
An email program such as Outlook, Notes, or Eudora is considered a client application, which means that it is network-enabled software that is intended to interact with a server. In the case of email, it is normal to interact with two different servers: one for outgoing and one for incoming mail. When you want to read email, your client connects to a mail server using one of three different protocols:
Post Office Protocol (POP, not to be confused with Point of Presence)
Internet Mail Access Protocol (IMAP)
Microsoft's Mail API (MAPI)
For the purposes of investigation, the protocol used to gather incoming email from a server is of minimal interest. The most important thing to understand about these different protocols is that their use affects where mail messages are stored (as depicted in Table 2-1). All incoming mail is initially stored on a mail server, sorted by that mail server into individual mailboxes for access by the addressee. POP users have the choice of either downloading a copy of their mail from their server, or downloading it and subsequently allowing it to be automatically deleted. Email that has been read or stored for future use is stored on the computer that is running the email client. IMAP and MAPI users have the option of leaving all their mail on their mail server.
There are two major advantages to leaving email stored on the server. First, all of the stored email for an entire organization can be easily backed up from a central location. Second, it provides users the flexibility of accessing their mailboxes from multiple client machines: office, home, through the Web, and so forth. The implications of this to the investigator is that POP mail users always use their local machine for their email archives: copies of outgoing mail, mail stored in folders for future reference, deleted mail that hasn't been purged, all are stored on the individual's workstation. Organizations that provide IMAP or MAPI service, or a proprietary service like Lotus Notes, probably store email on the server, although individual users may or may not have the option of storing their email locally.
Table 2-1 Internet Email Protocols
|
Post Office Service |
Protocol |
Relevance to Investigation |
|
Incoming message store only |
POP |
Must access workstation in order to trace mail. |
|
Storage of all messages (optional) |
Open: MAPI Proprietary: Microsoft MAPI |
Copies of both incoming and outgoing messages may be stored on server or workstation (and server/workstation backup tapes). |
|
Web-based: send and receive |
http |
Incoming and outgoing messages are stored on server, possibly with optional manual download to workstation. Facilitates identity spoofing. |
Outgoing email uses a completely different protocol called Simple Mail Transfer Protocol (SMTP). Unlike the protocols used to retrieve mail from a post office, SMTP doesn't require any authentication—it is much like tossing a message into a mail slot at the post office. Servers that accept mail and relay it to other mail servers are sometimes called mail transfer agents (MTAs), and they also use SMTP. Your ISP will give you the name of the mail server that you should use for outgoing mail, often something along the lines of smtp.bobsisp.com. The SMTP server that the ISP uses relays messages to their destinations. Either the destination server recognizes a message as being addressed to one of its local users, and places it into the appropriate mailbox for that user, or based on a set of rules, it relays the message on further.
SMTP is a very simple protocol. Like many Internet protocols, such as HTTP, it consists of a few simple text-based commands or keywords. One of the first tricks an Internet hacker learns is how to manually send an email message by telneting to port 25, the SMTP port. Not only is it a fun trick to become a human email forwarder, but it also enables you to put any information you want into the headers of the email message you are sending—including fake origination and return addresses. Actually, you needn't do this manually if you want to fake email. When you configure your personal email client, you tell it what return address to put on your outgoing mail. You can always change that configuration, but if you want to send only a single message coming from Pres@whitehouse.gov, it is much easier to use one of several GUI-based hacker tools that enable you to quickly send a message with your choice of return addresses.
SMTP mail has no strong authentication and without using PGP or S/MIME (Secure Multipurpose Internet Mail Extensions) to add a digital signature, the level of trust associated with a mail message is pretty low. The following steps (our input is in boldface) show how incredibly easy it is to fake the return address in an Inter-net mail message:
[root@njektd /root]# telnet localhost 25 Trying 127.0.0.1... Connected to njektd.com. Escape character is '^]'. 220 njektd.com ESMTP Sendmail 8.9.3/8.9.3; Tue, 5 Dec 2000 17:37:02 – 0500 helo 250 OK mail from: teswt@test.com 250 teswt@test.com Sender ok rcpt to: you@domain.com 250 you@domain.com Recipient ok data 354 Haha-this is a spoofed mail message! . 250 RAA25927 Message accepted for delivery quit 221 njektd.com closing connection Connection closed by foreign host.
The results of this spoofed mail message are shown in Figure 2-4. The test.com domain is just one we made up for demonstration purposes, but the email client reports whatever information it was provided.
){kind=link}
Figure 2-4 Reading the spoofed mail message
As we'll discuss later in this chapter, some identification information is associated with the mail header that is a bit harder to spoof. As recorded in the following mail header, we were indeed logged in as 208.164.95.173:
Received: from dhcp-95–173.ins.com ([208.164.95.173]) by dtctxexchims01.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YM4CM2VP; Sun, 10 Dec 2000 08:46:30 -0600 From: teswt@test.com Date: Sun, 10 Dec 2000 09:46:46 -0500 (EST) Message-Id: 200012101446.JAA06830@horh1.emsr.lucent.com
When relaying a message from another relay host, current versions of SMTP also keep track of the IP address of the system connecting to them, and they add that IP address to the header of the message. If you want to show that a mail message originated from a specific computer, the best way to do so is to investigate the entire path that appears in the extended header information.
Although SMTP servers won't perform any authentication when receiving mail from the client, most Internet mail servers are configured to accept mail for relay only when that mail originates from a specific range of IP addresses. If an ISP does not place any limits on which systems can connect to the ISP's mail server, allowing it to be used as a free relay station, it won't take spammers long to find it. To reduce the amount of spam mail that originates with their mail servers, most ISPs allow relay connections only from IP addresses within the range that they assign to their own subscribers. Authentication based just on IP address is very weak, but for the purposes of preventing unauthorized use of SMTP servers, it is adequate.
It should come as no surprise that Web-based email is not only available, but is becoming increasingly popular. The Internet browser is rapidly becoming the universal front end. Web-based email enables users to access all of their email—both incoming and saved messages—through a Web browser. Not only does this free the user from installing and configuring an email client on his or her workstation, but it also means that the user can easily access email from any workstation virtually anywhere in the world. Undoubtedly, many people are accessing free Web-based email from work for their personal use.
It also shouldn't come as a surprise that free email services are being used by some people to hide their identities. For the novice computer criminal, these services appear to be an easy way to hide their identity, and by adding at least one more server and involving another service provider, it certainly does complicate the association of a mail account with a specific person. The only way to find out who the ISP thinks is using a specific email address is to obtain a subpoena for the account information. If you are working with law enforcement agencies, they can obtain a subpoena to facilitate their investigation, or you can obtain a subpoena from a lawsuit (for more information, see Chapter 12). Fortunately, some providers of free email service are including the originator's IP address in the header information. Previously, you would have to subpoena the email provider and then the originating ISP to determine the originator. We recommend issuing a subpoena for the email logs from the email provider, but at the same time, you can also subpoena the originating ISP.
Reading the Mail Trail
When you are investigating a case involving email, you have to decipher email headers. If you have never viewed a header before, it might first appear to be gibberish, but once you get the hang of it and understand how SMTP works, it makes sense. The first annoyance you encounter is that most client email programs hide the header information from the user. Depending on the mail client you're using, you may have to do a little bit of digging to get to the header. In most programs, if you click File|Properties, an option to view the header is displayed. If your particular program provides a different way to access header information, consult the Help menu and documentation or try the company's Web site for instructions.
Most users don't want to be bothered with deciphering email headers, which encourages the email software vendors to make access to it as obscure as possible. Let's look at Microsoft Outlook Express. It is a popular email program for many reasons, including the fact that it comes free with Internet Explorer and recent versions of Windows.
As shown in Figure 2-5, the header information is available in Outlook Express by clicking on File and then Properties, which displays the dialog box that looks like that shown in Figure 2-6.
){kind=link}
){kind=link}
Figure 2-5 Outlook Express File menu
Figure 2-6 Outlook Express Message Properties window
Figure 2-7 Viewing the message source in Outlook Express
){kind=link}
The General Tab for the properties in Outlook Express displays some basics about the message such as the subject of the message, the apparent sender, and the date and time sent and received. Click on the Details tab to display the information like that shown in Figure 2-6. By examining the headers of this message, it is clear that both the From address (test@testing.org) and the Reply-To address are fake addresses (another_test@test. org). This is a real message that we sent from the Internet, but before sending the message, we first changed the From address to "HTCIA NE Chapter." The From address is completely arbitrary—it contains whatever the sender configures into their email program.
The most important tracks are found at the top of the message. In this case, the first line shows the computer that the message was originally sent from. While the name of the PC, "mypc," can easily be spoofed, the IP address that mypc was assigned when we logged on to the ISP is much more difficult to spoof. While it is not impossible to spoof an IP address, we are not aware of a case in which one has been spoofed to counterfeit email. The practical details involved in spoofing an IP address make it virtually impossible in an email transaction, which involves several round trips between the SMTP server and the connecting system. (Do be aware, though, that the actual sender of the message could have cracked the system from which it was sent, and logged on as somebody else.) In this case, the email was sent from a computer in the same domain, monmouth.com, as the SMTP server that relayed the mail, shell.monmouth.com. Do a whois on the IP address and see if you get something that matches the purported domains of both the originating client and the relay server. Then follow up using the Dig w/AXFR advanced query, as shown in Figure 2-8, using NetscanTools.
){kind=link}
Figure 2-8 Using NetScanTools to investigate an IP address
In contrast to Outlook Express, Microsoft Outlook (included with Microsoft Office) places the full email header information in an obscure position. As shown in Figure 2-9, to view the header information, you click on View and then Options. Clicking on Message Header seems to be a more obvious way to access header information—a mistake that we make all the time—but all that does is hide the To, From, and Subject lines from the message itself. It does not show you the detailed header information that you need to track an intruder. By clicking on Options, you access the Message Options window shown in Figure 2-10.
){kind=link}
){kind=link}
Figure 2-9 Outlook View menu
Figure 2-10 Viewing a message header in Microsoft Outlook
You've probably already noticed "Joe Anonymous" in the Have replies sent to field. We faked this deliberately to illustrate how you cannot believe everything you read. The only way to extract this information from this window is to select it all (hint: try Control-A), copy it, and then paste it into a text document, which we've done in the following:
Received: from hoemlsrv.firewall.lucent.com ([192.11.226.161]) by nj7460exch002h.wins.lucent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id W4VCF23A; Sat, 20 Nov 1999 21:19:10 –0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA06660 for <wgkruse@holmdel.exchange.lucent.com>; Sat, 20 Nov 1999 21:19:10 –0500 (EST) Received: from shell.?nmouth.com (shell.?onmouth.com [205.231.236.9]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id VAA06652 for <wgkruse@lucent.com>; Sat, 20 Nov 1999 21:19:09 –0500 (EST) Received: from mypc (bg-tc-ppp961.?onmouth.com [209.191.51.149]) by shell.?onmouth.com (8.9.3/8.9.3) with SMTP id VAA01448 for <wgkruse@lucent.com>; Sat, 20 Nov 1999 21:17:06 –0500 (EST) Message-ID: <001401bf33c6$b7f214e0$9533bfd1@mypc> Reply-To: "Joe Anonymous" <another_test@test.org> From: "Joe Anonymous" <test@testing.org> To: <wgkruse@lucent.com> Subject: test from outlook express Date: Sat, 20 Nov 1999 21:18:35 –0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859–1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
This header is longer than it was in our first example. This time, the message was relayed through four different servers. Each time an SMTP server accepts a message, it places a new Received header at the top of message before forwarding it on to another server or a user mailbox. In the first message, we intentionally sent the message from our ISP account to our ISP account. The second message originated externally and then was relayed through the Lucent firewall and to the mail server used to host our mailbox. But even with the extra headers, it is still apparent that the original message was received from: "mypc," and our address at the time was: ?onmouth.com [209.191.51.149]. The lines in the header tell a story about where the email message has been, when it was there, and when it was delivered to its destination. It may be a contrived story, but it is still a story. Virtually any of the headers with the exception of the topmost one could be bogus—it is up to you to verify each one of them and determine the actual history of the message.
The last example that we will look at is from Eudora, another popular email client.7 Eudora hides the header information by default, like the rest of the client programs, but as you can see from the Eudora Lite example in Figure 2-11, the full header is only a mouse-click away. A helpful piece of information is X-Sender, which shows the mail server and the account the message was sent from. One of the quirky characteristics of Eudora is that the icon is labeled "Blah, Blah, Blah." Strange label, but it provides the information we need. When you click on the Blah button, your email message changes from that shown in Figure 2-11 to something that looks like that shown in Figure 2-12.
){kind=link}
){kind=link}
Figure 2-11 Viewing the X-Sender header on Eudora Lite
Figure 2-12 Viewing mail headers with Eudora
When you are conducting an investigation involving email, even if the computer's name is bogus, you have the IP address that the user was assigned. If you trust the ISP, or the company that the address resolves to, you can ask for their assistance in identifying your suspect. They probably won't disclose the information to you immediately, but by noting that IP address, along with the exact date and time that the message was sent, you can ask the ISP to save the logs until you have a chance to get a court order. As long as the logs are still available, the ISP or other organization should be able to identify the user that was assigned that IP address at the time the message was sent.
Look at the two headers the arrows are pointing to in Figure 2-13. Compare the domain name in the Received header, "monmouth.com," to the domain in the From header, "test.org." Because they do not match, we can assume that the user configured his or her email incorrectly or that the user is trying to hide his or her identity. A message can be injected anywhere in the chain of Received headers—you can be sure that only the topmost one is accurate. Do an nslookup against each domain—especially the purportedly original domain—and see if they exist. Do a whois against each of those domains to find out who the administrator is and contact that person. Keep in mind that if the administrator is the originator of a phony or illegal message, he or she probably won't be inclined to cooperate.
){kind=link}
Figure 2-13 Extended email header with discrepancies in originator fields
When you are investigating a case on behalf of a victim, but you can't visit the victim or otherwise obtain the original message on your own, it is possible for the victim to email you a copy of it. You must give the victim very specific instructions on the appropriate way to send the mail to you—especially if the victim usually deletes messages right after receiving them. Ask the victim to send the message as an attachment and not to forward the message. Forwarding replaces the suspect's information with your victim's information. You might want to ask your victim not to delete the original message until he or she hears from you.