Re: Sender Spoofing via SMTP

• Previous message: Steven Meyer: "Re: Ecryption Cracking Tools"
• In reply to: brandon.steili_at_gmail.com: "Re: Sender Spoofing via SMTP"
• Next in thread: dominiquesb_at_collegeestrie.com: "Re: Re: Sender Spoofing via SMTP"
• Maybe reply: dominiquesb_at_collegeestrie.com: "Re: Re: Sender Spoofing via SMTP"
• Maybe reply: brandon.steili_at_gmail.com: "Re: Re: Sender Spoofing via SMTP"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 8 Nov 2005 11:56:14 +0100
To: security-basics@securityfocus.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

Thursday, November 3, 2005, 9:20:35 PM, brandon wrote:

> Thanks for your replies thus far, but they have helped add few
> more thoughts. By the way, I'm also looking for any thoughts on how
> to restrict this from happening internally as well. Using the about
> example, I can connect to a local exchange server and intiate the
> same spoofing technique to another local user -- for example I can
> connect to the server via Telnet to 25 and send my cubemate an email
> from santa@mydomain and tell him that the north pole has been having
> connectivity issues... It's junk like this I am trying to prevent
> internal and external people from doing straight from a telnet
> session.

In reality, you can't do anything about that. You can only use
half-measures.

This is a general problem with the SMTP protocol and nothing but a
complete overhaul of mail protocols will help in preventing that.

> Quote(Andrew Chong) - Currently, two common technologies are
> SMIME and PGP to digitallysign/encrypt emails.
> Response - This would help validate the sender to the enduser,
> which is a good start (and easy to teach to users). Not really the
> overall solution but definetly getting there. Thanks!

Well, SMIME and PGP are very nice, but you cannot require EVERY sender
you can think of to sign their letters digitally. It's nice if they
do, then you may be sure it's really them that sent the emails. But
99% of the senders will not sign their emails.

So, you're in a situation where you can neither force everyone to use
digital signatures [why should external senders listen to you?], nor
discard all unsigned letters [you'd be discarding 99% of legitimate
traffic]. All you CAN do is require all your company senders to
digitally sign their email, but this only validates them in the eyes
of their recipients, and does NOT prevent them from sending unsigned
letters from fake domains.

> Quote(Craig Wright) - Internal mail will not generally pass through
> SMTP Response - Great Point, but in this scenario I am connecting to
> port 25 and intiating the message directly via SMTP on the server. I
> think regardless of what happens to the message once it hits the
> queue and gets moved around by the Information Store or another MTA
> the fatal problem is that I was able to connect and send send the
> message?

Well, there IS a way to prevent this from happening partially, but it
has serious consequences as well. More about that later...

> Quote (Dallas Jordan & Corey LeBleu) (sort of combining these
> two) - I believe you should set your email server to only relay
> email coming from your domain. that would prevent people from the
> internet connecting to the server and sending emails randomly.

NO, NO, NO!

First of all, NEVER use the domain given in MAIL FROM as a basis of
the decision to relay mail or not. This domain can be given by ANYONE,
as MAIL FROM is no form of authentication. I could connect to your
server then:

> telnet yourserver.com 25
< 220 yourserver.com ESMTP
> HELO yourdomain.com
< 220 yourserver.com
> MAIL FROM:<postmaster@yourdomain.com>
< 220 Ok.
> RCPT TO:<someoneelse@somewhereelse.com>
< 220 Ok.

This is BAD, BAD, BAD. It's a classical open relay, which spammers
know very well how to use. You'd end up with queue full of spam, you'd
be listed on DSBL, NJABL [not ORDB I think since I don't think it uses
a domain-based test]. You'd be in a lot of trouble then.

The ONLY things that may be used to make a decision whether to relay
mail or not are:

* the IP address of the connection [you MAY, but don't have to relay
  all mail from internal IPs such as 10.*, 192.168.* etc.]
* SMTP AUTH [best use CRAM-MD5, not LOGIN or PLAIN, for security
  reasons]
* POP BEFORE SMTP [this validates a given IP for a given amount
  of time]

What you MIGHT do, if Exchange or other servers allow this [I haven't
researched into other servers either...] is implement the following
politics:

1. ALL local users [local IPs] are allowed to relay mail, BUT
2. the MAIL FROM given by the local user MUST match one of your local
   domains

This will prevent your users from playing tricks, but will NOT prevent
users from the outside connecting to your server and doing this:

> telnet yourserver.com 25
< 220 yourserver.com ESMTP
> HELO yourdomain.com
< 220 yourserver.com
> MAIL FROM:<santa@santaclaus.com>
< 220 Ok.
> RCPT TO:<localuser@yourdomain.com>
< 220 Ok.

There are ways to check the validity of MAIL FROM, but, as I already
said, they bring dire consequences and more on that later on in this
mail.

> Unauthenticating Mail Relay Response - However if I setup the server
> so it requires authentication for communication, would this not
> break the ability for other domains to send email to my users? I

No, if it's set up correctly. The politics must be such:

1. If someone [anyone] wants to send mail to one of your local
domains, authentication is NOT required
2. If someone from the outside [or anyone for that matter] wants to
send mail to some remote domain, authentication IS required

This is the proper way to set up a mailservers and all properly set up
mailservers use this solution. The only differences lay in whether
local [local IP] users must use authentication or not. This is really
up to you to decide, dependent on the size and security of your
internal network.

> have validated that I cannot spoof outbound emails from the internet
> based connection, so I'm not a completely open relay, but open
> enough that external connections can spoof an internal email
> sender and get that mail delivered to a recipient.

If anyone from the outside may send email to any remote user via your
server just by giving your local MAIL FROM, then you ARE an open relay
and sooner or later spammers will find that out and you'll find
thousands of mails in your queue and you'll find yourself blocked on
open relay blacklists... Don't let that happen!

I used to have a hole on my server which allowed someone to give any
login and password in the SMTP AUTH dialogue to authenticate and relay
mail. This is much more difficult for the spammer to discover, than an
open relay such as you're describing. And they DID find that hole and
I was listed for some time on open relay blacklists, so believe me I
know what I'm talking about 8].

> Sorry for hitting this so hard, but I have done a bunch of
> searching on the net, read way too much Technet and although I find
> bits and pieces, nothing really addresses the ability to spoof a
> sender or prevent this type of relaying without breaking everything
> else.

Well, there is a way. But a risky one.

It's called SPF.

It works in the following way:

1. Every domain [that's the goal of SPF, however until now only a
small part of domains does that] publishes a special IN TXT record in
their DNS, which contains information on which SMTP servers [IPs,
FQDNs] are allowed to send mail from this domain.

2. A mail server protected with SPF does the following.

2.1. Notes the IP of the connecting user/mailserver
2.2. Notes the given MAIL FROM and extracts the domain name
2.3. Looks up the SPF record in the DNS for the domain given in MAIL
     FROM and checks whether the IP noted in 2.1. is allowed to send
     mail with this sender address.

3. Now there are a couple of things that can happen.

3.1. The SPF record exists and matches the IP -> accept mail
3.2. The SPF record exists and does not match the IP -> deny mail
3.3. The SPF record does not exist... what to do then? Either:
3.3.1. Deny the mail [you'd be denying 90% of traffic...] or
3.3.2. Accept the mail [you'd be accepting 90% of spoofed mails then]

The problem in SPF is that not everyone uses it and not everyone will
use it. Ever. Impossible to force this upon everyone. So you'd allways
find a domain which does not have an SPF record and then you have to
accept it, or else you're risking denying legitimate emails.

Now, imagine, santaclaus.com does not have an SPF record. You have to
accept all mail from domains which do not have an SPF record [or else
you'd be denying 90% of the traffic, blah blah blah], so ANYONE can
spoof using this domain!

Worse case. Imagne a spammer buys a domain called, for example,
biggestbankofamerica.com and published an SPF record, which allows
EVERY IP to send mail using this as MAIL FROM. Then you have a global
address that can be used by EVERYONE as a spoof, and NO SPF will help
you, even if you deny traffic from domains which do not have an SPF
record, since this domain DOES have an SPF record and ANYONE can send
mail from it...

The problem is, that legitimate domains with such setup must exist,
and these domains belong to companies which sell mail forwarding...
Such as, I believe, mail.com? There are thousands of such domains or
more. And the owners of those domains have no other way but to publish
SPF records allowing ANYONE to relay! Why?...

Imagine the following situation.

1. You have a mail forwarding account, joe@forwardtome.com. This
account is managed by the company which owns the forwardtome.com
domain and sells mail forwarding or gives it for free for everyone so
they can place adds on their websites or in the forwarded mails. This
is a very popular setup.

2. You've set this domain up at www.forwardtome.com, so that all mail
sent to joe@forwardtome.com is sent to joe@yourserver.com. And
yourserver.com is protected with SPF.

3. Someone sends you email to joe@forwardtome.com. The original sender
is, say, mike@somedomain.com. Now, somedomain.com publishes an SPF
record which states that only mail.somedomain.com is allowed to send
mail with somedomain.com MAIL FROM. If this mail was sent directly to
yourserver.com, your SPF protection would see the following:

* IP address of the connection would be mail.somedomain.com
* Sender name is mike@somedomain.com
* the SPF record for somedomain.com allows mail.somedomain.com to send
  mail for this domain
* mail is accepted

4. Now, what happens if the mail is sent to joe@forwardtome.com? Since
forwardtome.com is managed by the company ForwardToMe, its mailserver,
not yours, receives the mail and then forwards it to your mailserver,
maintaining the original sender! So your server will see:

* IP address of the connection would be mail.forwardtome.com
* Sender name is mike@somedomain.com
* the SPF record for somedomain.com DENIES!!! all other mailservers
  from sending mail with somedomain.com
* mail is denied!!!

Therefore, if SPF is introduced on all mail servers, automatically ALL
companies offering mail forwarding go out of business!!! Because they
cannot forward mail anywhere!!! Same happens to all forwarding options
in all other mail accounts, you will not be able to forward mail to
other addresses, so a fundamental functionality of SMTP which until
now was used globally, is removed by the use of SPF!

Therefore, SPF will not help you much, because you'll either have to
deny 90% of the traffic or accept 90% of spoofed emails, and you will
not accept any mail from forwarding accounts.

Conclusion: SPF IS BAD! DO NOT USE IT EVEN IF YOU'RE TEMPTED!

Ouffff... Now this was a long post 8].

So, in conclusion, there is NOTHING you can do against address
spoofing, as long as SMTP is used as the mail protocol. You have to
live with it. And you have to protect your server against relying
mail, or else you'd be marked as a spammer by the community.

- --
Tomasz Nidecki, Sekr. Redakcji / Managing Editor
hakin9 magazine http://www.hakin9.org
mailto:tonid@hakin9.org jid:tonid@tonid.net

Do you know what "hacker" means?
http://www.catb.org/~esr/faqs/hacker-howto.html

Czy wiesz, co znaczy slowo "haker"?
http://www.jtz.org.pl/Inne/hacker-howto-pl.html

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUAQ3CEUUR7PdagQ735AQHStAQAtUjDBzKQXqMEQJRBh3rO6Gs1ImXE3JEV
kgbHLog1+fJmC6IhS/++opDFdy6mH6ed+5IL39G9rt/IGPHkxRKS8n99Ya97i+5u
cKqba+sBw1AJ5pBg1Z1ihrdyltBqXskJoQ3zOpT4gTlNegpHG51W2uiqE0Sg4FAr
u7d9WYyahH8=
=XO78
-----END PGP SIGNATURE-----

• Previous message: Steven Meyer: "Re: Ecryption Cracking Tools"
• In reply to: brandon.steili_at_gmail.com: "Re: Sender Spoofing via SMTP"
• Next in thread: dominiquesb_at_collegeestrie.com: "Re: Re: Sender Spoofing via SMTP"
• Maybe reply: dominiquesb_at_collegeestrie.com: "Re: Re: Sender Spoofing via SMTP"
• Maybe reply: brandon.steili_at_gmail.com: "Re: Re: Sender Spoofing via SMTP"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]