Security Basics mailing list archives

RE: e-mail tracing


From: LordInfidel () directionweb com
Date: Wed, 1 Sep 2004 01:00:40 -0400

Before I get into the nut's and bolts of what you are seeing,

One of the best places to learn about e-mail is actually from reading the
RFC's. The RFC's governing e-mail are 2822 and 2821 (www.faqs.org is my rfc
archive of choice)

Now why do I recommend reading the RFC's?  Because even though using tools
such as sam spade is great ( I personally use sam spade and encourage you to
download a copy of it), nothing beats knowledge of deciphering it yourself.

As I am sure you have learned in your net sec class, there are certain rules
and guidelines that everything must follow on the net, from the 3 way
handshake to ftp transmissions.  SMTP is the same way, it has set
guidelines.

Now you will see in each MTA relay (or handoff), a ip in brackets as well as
a spoofed FQDN.  Well both of those items are part of the rfc and must be
there in one form or another (no FQDN then an IP must appear).  Now here is
the cool part, the FQDN of the MTA can be spoofed and the next MTA in line
still must accept the e-mail.  But the IP in the brackets can not be
spoofed, at least not according to the RFC.  Which is where it get's into
grey area.

MTA's that do not function correctly can be tricked into accepting e-mail
from spoofed source address'.  Typically when this is done you will see
multiple MTA's in the e-mail header.  This is accomplished by none other,
our friend, mr source-routing.

But wait, source routing e-mail?  I thought that was only for IP.  But no,
e-mail also has source routing capabilities where you can tell each MTA to
whom(next MTA) to deliver the envelope.  (which is why operating open
relay's is bad)

Usually whenever you see multiple MTA transfers that do not follow a logical
pattern (same IP block like in large org's) you can bet your last dollar it
(the IP) is going to be spoofed and the e-mail is spam. 


Now there are several ways to tell where the e-mail really came from.

1: hope the originating IP is not spoofed
2: the next hop MTA correctly records the IP
3: The next hop MTA has logging enabled at either a choke point, or other
network monitoring device.

The headers you provided are a classic example of open-relays and spoofing.

The 1st entry written is fake and can not be trusted at all, it was meant to
muddy the waters so to say and to look like it was coming from citibank:

from E39 (a222.53.141.148.oeo6.wsj.admin170 () citibank com [160.129.208.70])by

mail67.k.yahoo.com

The 2nd MTA to handle this e-mail hopefully recorded the correct IP of the
sending MTA in the [brackets] (remember your RFC's).  original sending IP=
61.149.215.9.  The 2nd MTA lawfully abided by the RFC and accepted the
e-mail even though it was clearly spoofed.

from 216.200.145.35 (61.149.215.9 [61.149.215.9])by pmta04.mta.everyone.net 
(EON-PMTA) with SMTP id 894D1584for <xxxx () cbgb net>; Sun, 22 Aug 2004 
17:58:31 -0700

The next and final MTA, imta39.mta.everyone.net, received the e-mail from
pmta04.mta.everyone.net [172.16.0.19] (note this is a reserverd address and
in the same namespace as the final MTA, meaning it is NAT'd since pmta04
resolves to 216.200.145.35, and the bigiplb-dsnat entry gives it away, {the
BigIP is a network device from F5 and is a great loadbalancer, it's the
ferrari of loadbalancers}.  So the e-mail entered into the eveyone.net's
172.16 from the public net passing thru the BigIP, DNAT to pmta11, and then
deliverd to imta39, in turn delivering it to your mailbox.

from pmta11.mta.everyone.net (bigiplb-dsnat [172.16.0.19])by 
imta39.mta.everyone.net (Postfix) with ESMTP id EC06C4A619for 
<xxxx () cbgb net>; Wed, 25 Aug 2004 13:25:59 -0700 (PDT)

What we can derive from the 1st header written was that this e-mail was
generated on a local machine, had it's headers spoofed and sent directly
from that local machine to everyone.net. Who happily accepted it because the
final destination host@domain was in the namespace that they are accepting
mail for.


Hope that answeres your question

LordInfidel

-----Original Message-----
From: P S [mailto:seclistmail () hotmail com]
Sent: Saturday, August 28, 2004 10:27 AM
To: security-basics () securityfocus com
Subject: e-mail tracing


Hi,
I have been getting e-mails about confirming my credit card number and pin 
at different banks
and I decided to try to trace them back just to see where it is really 
coming from.
At school in the network security class we learnt how e-mail goes through 
MTA's, and spammers can send e-mails through open mail servers but we didn't

go into details and of course they didn't give us any hands on either.

So I googled "reading e-mail headers" and went through lots of pages and 
learnt a lot but I still have a few questions and I would really apprechiate

if somebody could help me.

What I learnt is I have to read the headers from bottom to top, thats how it

goes through the MTAs. Now I am reading these headers but the bottom "from" 
lines are confusing. I will copy 3 of the headers here:

Received:
from pmta04.mta.everyone.net (bigiplb-dsnat [172.16.0.19])by 
imta41.mta.everyone.net (Postfix) with ESMTP id 7547A50809for 
<xxxx () cbgb net>; Sun, 22 Aug 2004 17:58:31 -0700 (PDT)

from 216.200.145.35 (61.149.215.9 [61.149.215.9])by pmta04.mta.everyone.net 
(EON-PMTA) with SMTP id 894D1584for <xxxx () cbgb net>; Sun, 22 Aug 2004 
17:58:31 -0700

from E39 (a222.53.141.148.oeo6.wsj.admin170 () citibank com [160.129.208.70])by

mail67.k.yahoo.com

(606.70.4q95/1.773.2) with SMTP id vvh21F66RMEpjz471;Mon, 23 Aug 2004 
14:59:29 +0100


Received:
from pmta11.mta.everyone.net (bigiplb-dsnat [172.16.0.19])by 
imta39.mta.everyone.net (Postfix) with ESMTP id EC06C4A619for 
<xxxx () cbgb net>; Wed, 25 Aug 2004 13:25:59 -0700 (PDT)

from 216.200.145.35 (4.16.55.202 [4.16.55.202])by pmta11.mta.everyone.net 
(EON-PMTA) with SMTP id F1842D83for <xxxx () cbgb net>; Wed, 25 Aug 2004 
13:25:59 -0700

from 6.190.168.160 by 4.16.55.202; Wed, 25 Aug 2004 14:23:52 -0700


Received:
from pmta08.mta.everyone.net (bigiplb-dsnat [172.16.0.19])by 
imta38.mta.everyone.net (Postfix) with ESMTP id 718FF4A636for 
<xxxx () cbgb net>; Wed, 25 Aug 2004 12:13:39 -0700 (PDT)

from x1-6-00-08-0e-8a-58-75.k149.webspeed.dk (80.162.14.71 [80.162.14.71])by

pmta08.mta.everyone.net (EON-PMTA) with SMTP id 16ED3FB9for <xxxx () cbgb net>;

Wed, 25 Aug 2004 12:13:39 -0700

from 30.34.132.240 by 80.162.14.71; Wed, 25 Aug 2004 16:09:33 -0400

The first one says it's coming from 
a222.53.141.148.oeo6.wsj.admin170 () citibank com and from this I think the IP 
address should be 148.141.53.222 but in brackets it says 160.129.208.70. 
After this the received by says it was sent through yahoo's mail server. Now

to me it looks like this field is fake, am I right?

The second from field says 216.200.145.35 but the relaying mailserver put in

the real IP as 61.149.215.9. Is this the real spammer IP where the mail is 
really coming from? Same with the other two headers, it looks like the first

(bottom) fields are fake. Am I right when I think the spammer sent the mails

from 4.16.55.202 and 80.162.14.71?

Every answer and help will be really apprechiated, thank you.

Peter

_________________________________________________________________
Scan and help eliminate destructive viruses from your inbound and outbound 
e-mail and attachments. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=htt
p://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN(r) Premium right now and get the 
first two months FREE*.


---------------------------------------------------------------------------
Computer Forensics Training at the InfoSec Institute. All of our class sizes
are guaranteed to be 12 students or less to facilitate one-on-one
interaction with one of our expert instructors. Gain the in-demand skills of
a certified computer examiner, learn to recover trace data left behind by
fraud, theft, and cybercrime perpetrators. Discover the source of computer
crime and abuse so that it never happens again.

http://www.infosecinstitute.com/courses/computer_forensics_training.html
----------------------------------------------------------------------------

---------------------------------------------------------------------------
Computer Forensics Training at the InfoSec Institute. All of our class sizes
are guaranteed to be 12 students or less to facilitate one-on-one
interaction with one of our expert instructors. Gain the in-demand skills of
a certified computer examiner, learn to recover trace data left behind by
fraud, theft, and cybercrime perpetrators. Discover the source of computer
crime and abuse so that it never happens again.

http://www.infosecinstitute.com/courses/computer_forensics_training.html
----------------------------------------------------------------------------


Current thread: