one of the most efficient forms of communication today. Ironically, the email system's infrastructure is similar to that of the traditional post office in that it requires you to have "routable" addresses enabling mail to be delivered. The mail server is similar to your human mail carrier, and the mail client is you physically walking to your mailbox.
To begin, let's dive into understanding how the user goes about creating,
sending, and receiving email. We'll finish with a discussion of how to forge email.
Email Headers
The process of sending and receiving email involves two types of systems: the mail client (that's you) and the mail server (similar to the post office). To understand email headers, one must understand that email doesn't simply go from points A to B and suddenly "You have mail!" In many cases, an email message routes through four computers before it reaches its destination. Technically speaking, the total number of systems involved in the full process of email delivery is about twice that, but it's transparent and performed efficiently.
For examples in our email demonstrations, we will use an email message that I want to send to my readers. The email addresses we will use are:
Figure 1 shows an example of a common screen for creating an email message:
Figure 1 Standard Email Process: Creating a Message
As you can see, there is an optional CC field, enabling you to add email addresses to send this message to (a perk you don't get at the standard post office with a single stamp and envelope). Then I click Send and off my message goes to be received by you@receivingemail.com.
It appears that this comes off without a hitch, but the internal workings are what keep the message going. The mail protocol has headers that mark the emails with information on where it originated, its destination address, and the route it took to get there. Yes, that's right, email tells a story of its delivery, similar to a tracking number when you ship something via a carrier like Federal Express. The development of the email header's progress on its way to the destination address are typically marked by three different systems that are handling the mail delivery. I sent mail to you@receivingemail.com and the minute I clicked Send, the message was handed off to my mail server (mail.sendingemail.com). At that point, my mail client sent the mail server the following email headers to process:
As we continue, our mail client has sent the email to our mail server (mail.sendingemail.com). The mail server will read the header information that our mail client sent it, and will add some additional header information before sending it off to the receiver's mail server (mail.receivingemail.com). Here is what the headers look like:
Let's view the final header additions marked on the receiving mail server endpoint:
This entry header:
The headers derived in this email are legitimate headers. Anytime a system assists in routing an email, an extra Received header will be added on. Notice that the order of Received headers is destination endpoint first, and the bottom header is the starting point (see Figure 2).
Figure 2 Standard Email Process: Multiple Hops Required to Reach Receiver
STEP 2 :
Phishers take advantage of these settings to successfully perform social engineering against the average email user. To understand this concept a bit more, let's take a quick review of the email protocol.
Within the typical setup for email, two ports are typically used: port 25, and port 110. Port 25 is the Simple Mail Transfer Protocol (SMTP), and its job is to transmit and receive mail—basically what is called a Mail Transfer Agent, or MTA. An MTA is comparable to the mail carrier who picks up the mail and sends it off to where it needs to go. Just as the mail carrier drops off and picks up mail, so does the MTA. Port 110 is the Post Office Protocol, version 3 (POP3), and it is essentially the mailbox from which users pick up their mail up. This has an authentication process that allows users to log in and retrieve their email, which, in most cases, depending on your settings, is set to delete the mail from the server once you have completely retrieved it.
Raw SMTP Communication
A quick way to comprehend the operations of SMTP is to send an email using the Telnet protocol. Telnet is a communication protocol that allows you to connect to and communicate with a port in a terminal. In this case, we will Telnet to port 25 of mail.sendingemail.com:
To start, we have to identify ourselves by simply saying HELO:
To send email after the meet and greet, we want to tell the mail server who the email is from and where it is going:
To send our message, we will use the DATA command:
The mail server infrastructure works in such an efficient fashion that we did not use only four servers but, at minimum, eight servers to deliver our email. In the process of sending email, we query multiple DNS servers to obtain information about where the mail servers are on the Internet.
Here is an example of the complete process for sending an email (see Figure 4):
Figure 4 Standard Email Infrastructure
Step 3 :
To begin, let's dive into understanding how the user goes about creating,
sending, and receiving email. We'll finish with a discussion of how to forge email.
Email Headers
The process of sending and receiving email involves two types of systems: the mail client (that's you) and the mail server (similar to the post office). To understand email headers, one must understand that email doesn't simply go from points A to B and suddenly "You have mail!" In many cases, an email message routes through four computers before it reaches its destination. Technically speaking, the total number of systems involved in the full process of email delivery is about twice that, but it's transparent and performed efficiently.
For examples in our email demonstrations, we will use an email message that I want to send to my readers. The email addresses we will use are:
me@sendingemail.com you@receivingemail.comMy mail server will be mail.sendingemail.com, the receiver will be mail.receivingemail.com. The sending workstation will be called Sender, and the receiving workstation will be called Receiver. Now let's look at the internal operations of an area most of you reading this book should be familiar with: the client user experience of opening an email client to enter the To, Subject, and Body fields in the new email message.
Figure 1 shows an example of a common screen for creating an email message:
Figure 1 Standard Email Process: Creating a Message
As you can see, there is an optional CC field, enabling you to add email addresses to send this message to (a perk you don't get at the standard post office with a single stamp and envelope). Then I click Send and off my message goes to be received by you@receivingemail.com.
It appears that this comes off without a hitch, but the internal workings are what keep the message going. The mail protocol has headers that mark the emails with information on where it originated, its destination address, and the route it took to get there. Yes, that's right, email tells a story of its delivery, similar to a tracking number when you ship something via a carrier like Federal Express. The development of the email header's progress on its way to the destination address are typically marked by three different systems that are handling the mail delivery. I sent mail to you@receivingemail.com and the minute I clicked Send, the message was handed off to my mail server (mail.sendingemail.com). At that point, my mail client sent the mail server the following email headers to process:
From:me@sendingemail.com (Lance James) To: you@receivingemail.com Date: Tue, April 04, 2005 23:01:12 PST X-Mailer: Microsoft Outlook, Build 10.0.2616 Subject: This is your subject fieldAs you can see, the fields I referred to are actually headers. Email is technically constructed of headers with the field: value set. A blank line separates sections within the headers, so the actual body has a blank line with a content type before it, usually plaintext, which is indicated by the following:
Content-Type: text\plain; charset=ISO-8859-1: format=flowedThis text is usually found below the headers we displayed previously (different mailers have different header ordering) and indicates the type of content found within the email. The content-type field is determined by the mail client since it knows what it is sending. When we send plaintext, the content-type field is optional, but the majority of mail clients use it to stay within the specifications found in requests for comment (RFCs; see www.imc.org/rfcs.html).
As we continue, our mail client has sent the email to our mail server (mail.sendingemail.com). The mail server will read the header information that our mail client sent it, and will add some additional header information before sending it off to the receiver's mail server (mail.receivingemail.com). Here is what the headers look like:
Received: from sender (xx.7.239.24) by mail.sendingemail.com (Postfix) id 125A56; Tue, April 04, 2005 23:01:16 -0800 (PST) From: me@sendingemail.com (Lance James) To: you@receivingemail.com Date: Tue, April 04, 2005 23:01:12 PST Message-ID: ssc041837262361-293482299@mail.sendingemail.com X-Mailer: Microsoft Outlook, Build 10.0.2616 Subject: This is your subject fieldThere are a few extra additions marked on there, mainly stating from where the message was received (the mail client, when it identified itself to the mail server) and the time it was received, along with a message ID. The message ID has no human-based significance, but from an administrative standpoint, a mail administrator can use it to look up emails. The email message ID is similar to a FedEx or UPS Tracking number, and although it's a completely random number, can be very useful.
Let's view the final header additions marked on the receiving mail server endpoint:
Received: from mail.sendingemail.com (mail.sendingemail.com [xx.7.239.25]) by mail.receivingemail.com (Postfix) with ESMTP id T12FG932 for <you@receivingemail.com>; Tue, 04 April 2005 23:01:22 -0800 (PST) Received: from sender (xx.7.239.24) by mail.sendingemail.com (Postfix) id 125A56; Tue, April 04, 2005 23:01:16 -0800 (PST) From: me@sendingemail.com (Lance James) To: you@receivingemail.com Date: Tue, April 04, 2005 23:01:12 PST Message-ID: ssc041837262361-293482299@mail.sendingemail.com X-Mailer: Microsoft Outlook, Build 10.0.2616 Subject: This is your subject fieldWhen the receiving client user sits down at the receiver workstation, he will be able to view these email headers within the email (depending on the email client software, he might have to select the appropriate view headers field). When you receive an email, it can be very important to understand headers so you can trace the historical logs of an email. Let's look at the last set of headers we received and review each line item added to the Received headers.
Received from: mail.sendingemail.com (mail.sendingemail.com [xx.7.239.25]) by mail.receivingemail.com (Postfix) with ESMTP id T12FG932 for you@receivingemail.com; Tue, 04 April 2005 23:01:22 -0800 (PST)This first header tells us that this message was received by a server dubbed mail.sendingemail.com. The parentheses show the verification of identity, stating that a DNS reverse lookup revealed that the IP matches this identification and that xx.7.239.25 is the IP address the message came in from. The mail server that received the email is mail.receivingemail.com, which is running Postfix ESMTP with an arbitrary id of T12FG932. The ID is arbitrary and constructed by the receiving mail server for administrative purposes. The email address this message is intended for is you@receivingemail.com, with a receive date of Tuesday, April 4, 2005, at 11:01 P.M. and 22 seconds, Pacific Standard Time.
This entry header:
Received: from sender (xx.7.239.24) by mail.sendingemail.com (Postfix) id 125A56; Tue, April 04, 2005 23:01:16 -0800 (PST)documents the mail transfer between the Sender workstation and the sender's mail server. It is identified by the IP address in parentheses, and we know that mail.sendingemail.com is a Postfix server and has labeled this message with an arbitrary message ID. The date of mail transfer was Tuesday, April 4, 2005, at 11:01 P.M. and 16 seconds, Pacific Standard Time.
The headers derived in this email are legitimate headers. Anytime a system assists in routing an email, an extra Received header will be added on. Notice that the order of Received headers is destination endpoint first, and the bottom header is the starting point (see Figure 2).
Figure 2 Standard Email Process: Multiple Hops Required to Reach Receiver
STEP 2 :
Phishers take advantage of these settings to successfully perform social engineering against the average email user. To understand this concept a bit more, let's take a quick review of the email protocol.
Within the typical setup for email, two ports are typically used: port 25, and port 110. Port 25 is the Simple Mail Transfer Protocol (SMTP), and its job is to transmit and receive mail—basically what is called a Mail Transfer Agent, or MTA. An MTA is comparable to the mail carrier who picks up the mail and sends it off to where it needs to go. Just as the mail carrier drops off and picks up mail, so does the MTA. Port 110 is the Post Office Protocol, version 3 (POP3), and it is essentially the mailbox from which users pick up their mail up. This has an authentication process that allows users to log in and retrieve their email, which, in most cases, depending on your settings, is set to delete the mail from the server once you have completely retrieved it.
Raw SMTP Communication
A quick way to comprehend the operations of SMTP is to send an email using the Telnet protocol. Telnet is a communication protocol that allows you to connect to and communicate with a port in a terminal. In this case, we will Telnet to port 25 of mail.sendingemail.com:
me@unixshell~$ telnet mail.sendingemail.com 25
Trying 127.0.0.1...
Connected to mail.sendingemail.com.
Escape character is '^]'.
220 mail.sendingemail.com ESMTP We have successfully established a session with the SMTP or ESMTP (Extended STMP) server, and it has given us a return code of 220. We can now send it commands. The commands typically used to send email are HELO, MAIL FROM, RCTP TO, DATA, and QUIT. Basically, five primary commands control the majority of the protocol. To start, we have to identify ourselves by simply saying HELO:
220 mail.sendingemail.com ESMTP Postfix HELO sender.sendingemail.com 250 mail.sendingemail.com Hello sender.sendingemail.com [xx.7.239.24], pleased to meet youAs you can see, the server greeted us back and identified us by displaying our IP address. Technically, we could make up anything describing who we are; most SMTP servers will allow that because they know our IP, and it will mark our IP within the Received headers.
To send email after the meet and greet, we want to tell the mail server who the email is from and where it is going:
MAIL FROM: me@sendingemail.com 250 me@sendingemail.com... Sender ok RCPT TO: you@receivingemail.com 250 you@receivingemail.com… Recipient okThis code states that the inputs we've entered are okay. In the real world, we would be rejected for the RCTP TO: from Telnet, since relaying to another network should be denied. But since we're on our own network and run our own mail server locally, this is allowed. Note that this is a quick and easy way to forge headers right at the MAIL FROM: and RCPT TO: fields. From our local network, we can put anything we want in both those fields and it will be accepted. This is one basis for some forgery; the other is the open relays, which we will get to shortly.
To send our message, we will use the DATA command:
DATA 354 Enter mail, end with "." On a line by itself Subject: Test EmailHere is my data that I would like to send to you@receivingemail.com. This is essentially the body of the message and we will close by skipping a line and entering "." -me
. 250 I6A2341RR Message accepted for delivery QUIT 221 mail.sendingemail.com closing connectionNote that the 250 return code revealed an ID for our message; this is the message ID we see in the headers on the way out. Once we tell the mail server QUIT, it will send our message. This is the internal protocol that SMTP works with. As you can see, it's simple and flexible, which is the exact reason the technology enables so many problems while also offering convenience.
The mail server infrastructure works in such an efficient fashion that we did not use only four servers but, at minimum, eight servers to deliver our email. In the process of sending email, we query multiple DNS servers to obtain information about where the mail servers are on the Internet.
Here is an example of the complete process for sending an email (see Figure 4):
Figure 4 Standard Email Infrastructure
- Create the email, specifying the From, To, Subject, and content.
- After you click Send, the mail client will access the DNS server of your ISP to locate your local mail server.
- The local mail server (mail.sendingemail.com in our example) receives your email and uses the local DNS to determine who sent it by doing a reverse IP lookup of Sender.
- After verification, the local mail server adds the headers and relays the mail to the mail.receivingemail.com mail server. To do this, mail.sendingemail.com has to look up what is called a mail exchange, or MX, record within DNS. This MX says, "Hello mail.sendingemail.com, mail.receivingemail.com is handling mail for receivingemail.com." Once that has been identified by our mail server, it can relay to the proper mail server.
- Once mail.receivingemail.com receives the email, it applies more header information, including routing data and receiving time; checks the DNS server for a reverse lookup regarding mail.sendingemail.com; and looks up the user you for the domain it is handling mail for.
- Client email user Receiver contacts mail.receivingemail.com (again, local DNS is used), makes a request to the POP3 port (110), and asks to retrieve its email. The email is delivered to the email client, and Receiver happily reads the email.
Step 3 :
No comments:
Post a Comment