spf and email forging

[Lucas Albers <ad...@cs.montana.edu>]

I posted some items about phishing:
"The Anti-Phishing Working Group says 95% of all fraudulent E-mail scams
use spoofed, or forged "From" addresses."

http://www.informationweek.com/shared/printableArticle.jhtml?articleID=22102466

"Citibank remained the No. 1 target of phishers in May, a dubious honor it
has held for the last two months. Other companies with a phishing
bull's-eye on their backs include eBay, U.S. Bank, and PayPal. These top
four targets accounted for 82% of all phishing and E-mail fraud scams for
the month."

It must take a lot of work to setup a phish, as it mentions that most of
the phishing is directed to a few institutions.
Takes signifigant amount of time to setup a phish, forcing hacker to focus
on one target at a time?
Why is this?
Luck of the draw?
Easier to phish?

Then I ranted on about how all the financial institutions should implement
spf.

<spf rant>
All the top phish targets should implement spf.
Takes about perhaps a day to identify all the outgoing mail servers, and 5
minutes to setup the dns records.
Yes, for enterprise customers it takes more effort to implement new
changes,etc...
<spf rantoff>


Neal, at securescience mentions some ideas on why he thinks spf isn't the
solve-all solution that everyone thinks it could be.
I wanted to get some other counter arguments, from the sa mailing list, so
I decided to re-post his reply with his permission.
He mentioned that Justin Mason appeared to have already gone over this...

Any ideas?
--Luke

----------
Hi Luke,

I'll reply to your SPF comment.
SPF will not stop spam.
SPF will not even dent spam.
SPF *will* interfere with regular email delivery.

=== SPF will interfere with regular email delivery ===
Under the SPF architecture, it is assumed that all email goes directly: A->B.
For example, if cow@yahoo.com receives email from pig@aol.com, then yahoo
will check to see if the delivering mail server is listed in aol's SPF entry.
This is fine if email goes directly: from aol to yahoo.

Unfortunately for SPF, the SMTP protocol is flexible.  The MX records
are used to route data around network problems.  In other words, if
A->B is not possible, then try A->C->B.  We saw this type of network
routing really kick in during the network outages following 9/11 and the
east coast blackouts.

So let's see how alternate routes work with SPF...
  A tries to send email to B, but fails due to a network problem.
  A tries to send email to C and succeeds.
    C has the option to check the SPF and say "Yup, A is listed in A's SPF."
  C then tries to relay the email to B.
    B checks if C is in the SPF record for A.  Nope.  Email rejected.
This failure is clearly described in <http://spf.pobox.com/howworks.html>,
left column, bottom item.

Then there is a variation of SPF where trust is assumed across the network.
  In the case of A->C->B, B will accept the email because of the associated
  trust from A->C.  Unfortunately, this trust can be abused by the same
  spoofing we are seeing today.

Making matters worse, mobile users will be blocked by SPF.  Consider this:
  A department at IBM decides to hold an off-site meeting.
  They all leave the comfort of IBM and take their laptops.
  They go to send email from their laptop.
    - Their IP address does not match IBM.com's SPF entry.  Email is blocked.
    - They could use IBM's external POP server, but most companies do not
      offer such a system.  (HP, for example, does not offer an external
      method for users to connect to the internal subnet.)  External
      access is forbidden due to security reasons.

And just to top it off, many companies do not want to publish all of
their domains in an SPF entry.  A good example is the FBI -- they have
a variety blind of domains that they use for accessing the internet.
If they are required to list them in the "fbi.gov" SPF entry, then they
will be advertising to the world all of their secret domains.  This is
just asking for an attack.


=== SPF will not stop spam ===
Spam is more than a problem for the recipient.  Spam also causes problems
with mail servers, network congestion, and disk space.
SPF is a filter system.
SPF does not stop the email from being generated, traversing the network,
or being received by the recipient mail server.  It only limits the email
that can be placed in the file repository.


=== SPF will not even dent spam ===
Spammers are not stupid.  They rapidly change their tools to bypass filters.
There are many ways around SPF.  For example:

  - DNS is full of holes.  Anything from a DNS DoS to DNS hijacking can
    be used to make an SPF record unaccessible (or appear valid).

  - Compromised hosts.  We are seeing a trend where hosts are targeted for
    being compromised, and not just compromised randomly.
    If any host in the "citibank.com" domain gets compromised, then it
    could be very lucrative for a phisher.

  - Spelling errors.  A spammer can configure "c1t1bank.com".  How many
    ways can you spell "citibank"?

  - "If I can't, nobody can."  Spammers have waged month long DoS attacks
    against blacklist providers.  They could simply cause a DoS attack
    such that a service provider (e.g., ebay.com) would be forced to route
    traffic via a secondary route.  At that point, the provider has three
    choices:
    (1) don't use SPF, (2) open SPF to all hosts, or (3) not be able to
    email their customers.  The moment they make any of these choices,
    the phishers come back.  And after a week, they *will* make a choice.

And that is just the beginning of the list.
We are already seeing spammers prepare a major war if SPF is widely accepted.
And frankly, I expect the spammers to win.

SPF is not a solution -- it is a hack and a bandaid.  It addresses the
symptom without addressing the problem.  Until the problem is addressed,
spammers will always win.

                                        -Neal
--
Dr. Neal Krawetz
Secure Science Corporation
http://www.securescience.net/


-- 
Luke Computer Science System Administrator
Security Administrator,College of Engineering
Montana State University-Bozeman,Montana

Re: spf and email forging

[Kelson Vibber <ke...@speed.net>]

A few responses off the top of my head...

At 06:58 PM 6/30/2004, Lucas Albers wrote:
>Under the SPF architecture, it is assumed that all email goes directly: A->B.

SPF is changing significantly with the Caller-ID merger.  Neal should check 
out the SPF mailing lists for more current info.

>Making matters worse, mobile users will be blocked by SPF.  Consider this:
>   A department at IBM decides to hold an off-site meeting.
>   They all leave the comfort of IBM and take their laptops.
>   They go to send email from their laptop.
>     - Their IP address does not match IBM.com's SPF entry.  Email is blocked.

IBM sets up an SMTP-AUTH server, problem solved.

>SPF does not stop the email from being generated, traversing the network,
>or being received by the recipient mail server.  It only limits the email
>that can be placed in the file repository.

1) The recipient can often reject the message before DATA.
2) If there are intermediate servers (say A->forwarder->B, or A->secondary 
MX->B), then those servers can implement their own SPF checks

>   - Compromised hosts.  We are seeing a trend where hosts are targeted for
>     being compromised, and not just compromised randomly.
>     If any host in the "citibank.com" domain gets compromised, then it
>     could be very lucrative for a phisher.

If a host in citibank.com is compromised, phishers are the least of our 
worries.

>   - Spelling errors.  A spammer can configure "c1t1bank.com".  How many
>     ways can you spell "citibank"?

That are indistinguishable from the correct spelling?  One.  That look like 
L337-speak? Lots.  This is going to vary depending on what letters are in 
each name - paypai.com (with a capital I) was a classic example.

>   - "If I can't, nobody can."  Spammers have waged month long DoS attacks
>     against blacklist providers.  They could simply cause a DoS attack
>     such that a service provider (e.g., ebay.com) would be forced to route
>     traffic via a secondary route.  At that point, the provider has three
>     choices:
>     (1) don't use SPF, (2) open SPF to all hosts, or (3) not be able to
>     email their customers.

Or (4) change their SPF record to cover the new route.  (Gee, that was easy.)

>SPF is not a solution -- it is a hack and a bandaid.  It addresses the
>symptom without addressing the problem.  Until the problem is addressed,
>spammers will always win.

What does Neal think the problem is?  He doesn't actually say.

SPF isn't designed to stop spam, it's designed to stop email forgery.  A 
lot of people assume it's the former and decide it's useless on that basis 
- which is like complaining that a coffee pot is useless for making 
breakfast because it won't help you fry an egg.

Really, he needs to take a look at the SPF mailing lists - the website is 
way out of date.


Kelson Vibber
SpeedGate Communications <www.speed.net>