Can Received: fields be spoofed?

In the recent weeks, I've had to deal with some pissed off people sending emails back to the company because they contained viruses or some malicious content. Now, I know how easily the From and other parts of the email can be easily forged. Basically what's going on, is some smartass or multiple smartasses are going to our company website, copying the account names and forging the header information and sending emails to random people with virii and the like making it appear to the common user, that we're sending out dirty emails.

I understand the basics of email spoofing and how to trace the full path of an email .I also determined that this is indeed the work of an outsider (not a trojan/virus or co-worker). The emails are definately originating from mail servers outside our network. With all that being said, I was actually wondering if it's possible to spoof the IP in the Received: field in the email header. From my understanding, it's not possible (and this is what I've been using to trace the emails).
According to the sites I've checked, they all seem to agree that while some parts of the Received: field can be forged, the IP cannot. How true is this?

The IP cannot be forged, the attacker can however use a proxy to connect to a mailserver and thus his IP won't be visible to you.

Anything in an email message can be spoofed except for the headers that the recipient's mail server puts there. Just because it says it originated somewhere or that it passed through certain mail servers doesn't mean it actually did. Mail can be sent by telnetting to port 25 on a mail server and typing the commands manually. Since that is possible one could make an email message look like it routed through any mailserver one wanted. The mail server that the sender sends the message to (and any downstream servers) would also add a received header which the malicious sender would not be able to control.

attacker can also use a smtp server that belongs to an innocent company. You cant believe how much smtp relays are open worldwide....
I think there is some smtp relays on east (russia and likely) that everybody can use.

ShagDevil - I deal with the same issue on a daily basis. The easiest option for me was to draft a standard canned answer. It's not really a good option for me, but it is doable. Wish I could offer you a solutions but I think we are both in the same leaky boat.

jonathans_daddy, So what you're saying is, that a malicious user can add as many Received: fields as they want to an email and even attach valid IP's to make it seem like the email did indeed go through mail servers that it never did?.

Is it possible that a malicious user who received an email from my company at some point, to expand the full valid path in the email header, then use any old random mail server, forge in the appropriate Received: fields (that they copied from a valid email my company sent) with valid IP's and mail servers and create an email that for all practical purposes, will appear to have come from within my network?

It would seem that if that is indeed the case, the only way to determine if an email originated from within my network would be to actually monitor all outgoing emails (which we currently do) and tracing emails through server transactions, would be utterly pointless.

**note - I just thought about something else. Don't the mail servers keep records of transactions? Wouldn't it be possible to take an email, even with Received fields that made it appear as though it came from within my network and compare it to some database on the actual mail server itself? I know most (if not all) mail servers attach an ID number to the transaction. no?

Erm.... Unless the headers show IP's or Mail Servers that belong to your company when they arrive at the pissed off party's mail client then this is all really rather normal activity.

Other people outside your company have viruses infecting their machine. They harvest email addresses from all over the infected machines hard drive including, (in some cases), cached web pages in the users history folders. They then pick a name at random and place that in the "from" field and send out a copy to everyone except the the user in the "from" field. This is to make it more difficult for the infected machine to be tracked down. There are a thousand viruses out there right now that act in this fashion.

The interesting side effects of this behaviour are as follows:-

1. Your users proudly tell you that they didn't open the attachment because they didn't recognize the sender.
2. Your users complain about NDR's from people they never sent messages to because they don't know them.
3. Your users forward the bitch fits of others to you accusing your company of being infected with a virus and telling them to "please try to be more professional" - It's a bitch when the pissed off party reads my reply - they go all nice and apologetic.... ;)

In any of these cases it's the virus activity not some malicious bastige trying to make your company look bad. To prove that try to talk the pissed off party into sending you the original headers. I bet you won't find anything to do with your company in them...... But don't expect the pissed off party to have looked at the headers and understood them.

That's probably what it is, but what if it isn't? If I'm correct, smtp doesn't have any authentication built in, so wouldn't it be pretty easy to do what ShagDevil is talking about?
As long as you don't expect an answer back, can't you just spoof all the headers, including the IP?

Tiger Shark :D lol
You should have seen the looks I recently got when I tried to explain to my co-workers how to break down an email header and find the fields needed in order to see where the email may have originated. I might as well have been talking swahili.
We did receive a couple of the spoofed emails back and to my pleasure, not one of the received fields in any of the emails was even remotely close to any mail server we use. The hard part is convincing these outside people that we didn't send the malicious email in the first place. why? because exactly like you said, they don't understand how to read headers. go figure.
I've come to a conculsion on how to resolve the problem though.
1) disable all email capabilities
2) hand out free pens and envelopes
3) hire a clown so they stop looking at me all funny
4) quit
5) move to switzerland and start a farm :D

I've also recently figured out a mathmatical formula to determine the stress level for a LAN admin.
number of users * number of complaints * blue screens of death / a batch of mom's homemade chocolate chip cookies = stress level.

Shag: I don't try to convince them. I send a slightly concescending email informing them of how this works and how the email could not possibly have emanated from my domain because of x, y and z. Then I point out how surprised I am that their IT chap hasn't explained this to them so they don't go pissing off admins of other domains by accusing them of not knowing their job....... It works for me...... ;)

Quote:

---

3) hire a clown so they stop looking at me all funny
4) quit
5) move to switzerland and start a farm

---

ROFLMAO

Quote:

---

The IP cannot be forged, the attacker can however use a proxy to connect to a mailserver and thus his IP won't be visible to you

---

I agree with el-half on this. I know from personal experience (no I'm not a spammer) you can send Anonymous e-mail if you use this method. Use an anonymous proxy server to surf then net find a system thats running smtp server (simple mail transfer protocol) on port 25. Use the telnet client to bring up a shell prompt on the remote system then issue smtp commands to the SMTP server to make spoof *e-mail*. This is Very simple. A simple google search proves this:http://www.google.com/search?hl=en&l...elnet%27+SMTP+

As far SMTP being secure. Nope not in my opionion. 70% of SMTP servers out there allows anonymous access to the SMTP server. Large security hole. :)

Quote:

---

jonathans_daddy, So what you're saying is, that a malicious user can add as many Received: fields as they want to an email and even attach valid IP's to make it seem like the email did indeed go through mail servers that it never did?.

---

Yes, but some servers (like mine) will refuse to accept the message if there are too many (>25 if memory serves) recieved headers because it assumes the message is bouncing back and forth between a couple of misconfigured servers.

Quote:

---

Is it possible that a malicious user who received an email from my company at some point, to expand the full valid path in the email header, then use any old random mail server, forge in the appropriate Received: fields (that they copied from a valid email my company sent) with valid IP's and mail servers and create an email that for all practical purposes, will appear to have come from within my network?

---

Yes. Would you like a demonstration? What's your email address?

Quote:

---

It would seem that if that is indeed the case, the only way to determine if an email originated from within my network would be to actually monitor all outgoing emails (which we currently do) and tracing emails through server transactions, would be utterly pointless.

---

Log files work well for determiing whether a message truly came from within your network.

Quote:

---

**note - I just thought about something else. Don't the mail servers keep records of transactions? Wouldn't it be possible to take an email, even with Received fields that made it appear as though it came from within my network and compare it to some database on the actual mail server itself? I know most (if not all) mail servers attach an ID number to the transaction. no?

---

If your mail server keeps such a database, then yes. Mine doesn't so I use the logfiles.

Quote:

---

That's probably what it is, but what if it isn't? If I'm correct, smtp doesn't have any authentication built in, so wouldn't it be pretty easy to do what ShagDevil is talking about?
As long as you don't expect an answer back, can't you just spoof all the headers, including the IP?

---

Most SMTP doesn't require authentication, but if you're worried about people abusing your mail server you should require authentication for anyone claiming to be from your domain and not connecting from one of your IP addresses. This can be accomplished in a couple of ways... POP before SMTP (user must check his mail before he/she can send) or setting up SMTP AUTH (http://www.faqs.org/rfcs/rfc2554.html)

And yes, you can spoof all the headers *except* the ones that your mail server adds to the message when it receives it. That's how you can know which computer out there delivered it to you. Other than that, everything else is suspect.

Quote:

---

Log files work well for determiing whether a message truly came from within your network

---

[RANT]

Log files don't just help you with email.....

Log files are the final defense for the adminstrator that is bothered about security, period.

It might seem like a high overhead to log _every_ last connection you can to your network and set the most verbose logging of every service you provide but it isn't anything like the overhead of looking at 500 workstations and wondering which ones _might_ be compromised.... :eek:

Of course, you also have to be able to interpret them.......

[/RANT]

Ladies and Gentlemen, please return to your normal programming... :cool:

Well, I appreciate all the help and attention you guys have offered. It seems the ultimate solution in this case is to keep the log files of all our emails up to date, amongst other things. I can honesty admit that although we have been keeping logs of our emails, I haven't paid much attention to them until now.
tsk tsk on me :D

Maybe in the future, we can implement some kind of PGP but, right now, it's just not feasible for us to take on a task of that magnitude(we have a crap load of clients on our exchange server database). I'm also not very familiar with PGP and I don't want to go start screwing around with it until I can catch up on some reading first.