spf-discuss
[Top] [All Lists]

Re: A hole in planned phishing-prevention?

2004-06-03 20:38:28
On Thu, 2004-06-03 at 16:54, Ryan Malayter wrote:

Unless I'm missing something, a message with these properties:

   ENVELOPE-SENDER: someguy(_at_)phisher(_dot_)com  (no RFROM)

   RFC-2822 From: Operations(_at_)FirstNationalBank(_dot_)com
   RFC-2822 Sender: someguy(_at_)phisher(_dot_)com

will pass under the new SPF, assuming phisher.com has valid SPF records.

Everyone, stop the presses.

Ryan is right, and he has a good point.

Background:  Those of us who've been on the list for a while had 
             discussed this problem in regards to the previous SPF,
             dismissing the problem as not being within the purview of
             the old SPF.

             I don't think anyone has brought it up since the merger.

             (Though Seth recently brought up something very close.)

I think this is a solvable problem with the new SPF, at least to a some
extent.  At the very least, I think we should spend some time and some
serious effort in revisiting this issue.

Here's my first go at it:

Initial simplification:
-----------------------

First, for an initial simplification of the problem, let's remove
mailing lists from the problem set, and imagine a solution that could
work if mailing lists just didn't exist.

Other than their use in mailing lists, individuals basically don't use
"Sender".  At least, they don't use it much at all in outgoing mail.  I
for one don't think I've actually used it in outgoing mails for more
than ten years, and I don't expect to do so much in the near future
either.

(Well, if what I'm suggesting gets incorporated into SPF, I'll obviously
use it in testing. :-)  )

In any event, I don't expect to send mail on someone else's behalf using
Sender in the near future, and I *very much* don't expect to have to ask
someone else to send mail with my From: line on my behalf.

And if I don't expect to ask someone else to send mail on my behalf,
that's a short hop from me saying:

     "I don't want someone else to send mail
      on my (header From) behalf."

That last statement is just *itching* for an SPF modifier!

So imagine an RFC2821-with-extensions MAIL command like so:

  MAIL FROM:<SES-return-path(_at_)example(_dot_)com>   \
       SUBMITTER=<forwarder-account(_at_)example(_dot_)com> \
       Sender=<sending-account(_at_)example(_dot_)com> \
       OnBehalfOf=<me(_at_)example(_dot_)com>

A server receiving that line would do an SPF lookup on "example.com",
pull out some spiffy macro-laden validsenders= modifier, and use it to
see if me(_at_)example(_dot_)com allows sending-account(_at_)example(_dot_)com 
to send mail on
its behalf!

If me(_at_)example(_dot_)com doesn't, then FAIL.

If it does, then after DATA, check that the envelope MAIL SENDER above
matches the body header Sender:, and that the envelope MAIL ONBEHALFOF
matches the body header From:, and FAIL if it doesn't, just like you'd
FAIL if the envelope SUBMITTER didn't match the DATA PRD--and if
ONBEHALFOF does match, then return whatever SPF-result you'd otherwise
return.

So, push for SENDER and ONBEHALFOF 2821 extensions along with the
SUBMITTER extension all in the same RFC.

This solves the given problem.

When SENDER and ONBEHALFOF don't exist:
---------------------------------------

Unfortunately, there is a necessary (minor) downside that comes from the
fact that people trying to scam folks in this way aren't going to use
any 2821 SENDER and ONBEHALFOF extensions.  (Though honest folks will.)

That means you have to be careful about the what failure modes you
design in if SENDER and ONBEHALFOF aren't in the envelope, but there's a
Sender: in the body data.

I'm not sure of the best way to resolve that, but here's one way to
incorporate that problem:

I note that after flag day we will be rejecting all forwarded email if
DAVE isn't in the envelope.  I suggest that after flag day we also
reject all mails sent-on-behalf-of-another via Sender if SENDER and
ONBEHALFOF isn't in the envelope.

That *sounds* extreme, ("Dude, you're dropping legitimate mail!") 
but...look at who this would negatively affect:  I'm guessing that it
will hardly affect any legitimate Senders.

Then look who it will positively affect:  Receivers who get Sender!=From
actual forgeries.

(And before flag day, we'll be able to check all this by looking at the
body header, because we already have to do all spf checking after-DATA
just to pull in the PRD.  And, just as before flag day, I'll be noting
places that legitimately forward me mail but don't use SUBMITTER yet,
and making sure they switch even before flag day, I can also note places
who use a body sender without an envelope SENDER and ONBEHALFOF.)

Simplification removed:  Re-add mailing lists:
----------------------------------------------

Now we have to add mailing lists back in.

There are two ways to do this:

1.  Add more to the MAIL envelope header.

    We could require something like 
"LIST=<spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>",
    then a lookup at v2.listbox.com can show what Senders are allowed
    and..

    I haven't thought this one completely.  (Though my initial gut
    feeling is that this way lies madness.)

2.  Just as the PRD comes from the highest-priority of:

         Resent-Sender:
         Resent-From:
         Sender:
         From:

    We could redefine ONBEHALFOF to come from the highest-priority of:

         List-ID:
         From:

    Problem solved, with the cost of all mailing lists having to switch 
    to using RFC 2369 headers.  (RFC2369 defines List-ID:)

Summary:
--------

So again, the logic is that after flag day:

1.  Do pre-DATA SPF check on the basis of SUBMITTER as normal.
2.  FAIL if there's an ONBEHALFOF without a SENDER.
3.  FAIL if ONBEHALFOF doesn't allow SENDER to send.
4a.  After DATA, FAIL if SUBMITTER!=PRD,
4b.  After DATA, FAIL if no SUBMITTER and PRD!=From:
5a.  After DATA, FAIL if ONBEHALFOF!=max(List-ID:,Sender)
5b.  After DATA, FAIL if no ONBHEHALFOF and max(List-ID:,Sender) exists
6a.  After DATA, FAIL if SENDER!=Sender:
6b.  After DATA, FAIL if no SENDER but Sender: exists 

(The logic will have to be a bit more complicated to account for things
such as queries for ONBEHALF itself failing.)

Pre-flag-day logic would more or less be the first three steps, just
pulling SUBMITTER, SENDER, and ONBEHALFOF from the body after DATA.

I would suggest default values of validsenders= meanings to be that:

  o if the modifier doesn't exist for a domain, to allow all senders,
  o if it does exist but is empty, to allow no senders, and
  o if it does exist and is not empty, well, to go by its meaning. :-)

Comments?

(The worst thing about this suggestion is that it becomes more difficult
to fit SUBMITTER, SENDER, and ONBEHALFOF *all* into source- and
reverse-routes, so we'd need the ESMTP extension.)

Note that the validsenders= modifier (needs a better name), means that
phishing problems reduce to the problem of having a From: line saying
"accounts(_at_)paypa1(_dot_)com", where there's a numeral "1" in "paypal" 
instead
of the letter "L".

(Right-hand-side blacklists can address this reduced problem, though
admittedly they could conceivably address the full problem too, though
maybe not as well.)

Side note:  A long, boring note on an unnecessary over-complication:
--------------------------------------------------------------------

Just to be complete, there's one other pluggable hole for a specific
potential denial-of-service-attack:  Reply-To.  It's kind of along the
same notion as all the above, but I'm not sure if this one is quite
worth it, and I might be descending into madness even giving this a
moment's thought.

But I want to be complete in thinking about everything potentially
tangentially related to this phishing problem, and Reply-To is the last
email-address-containing body header of the bunch.

Here's the problem I'm wondering about:  Anyone can send out zillions of
rude mails with a reply-to of someone they hate, and that poor person
would get all the nasty replies from the rude email.

One can imagine another "REPLYTO" argument to "MAIL" with all that
implies, in order to let people list what Senders they allow to set
replies to them on their behalf.

But that whole concept is fraught with difficulties of its
own--rejecting all mail with Reply-To body headers and no REPLYTO in the
envelope probably won't work out so well, to say the least!  (Not
without another flag day a decade in the future.)

Then, mailing lists who leave Reply-To alone will have to not complete
peoples' subscriptions until they adjust their spf-allow-replyto
settings to allow the mailing list in, meaning there's yet something
else for subscribers to keep up with.  (Granted, mail clients that let
you list what lists your subscribed to can help automated that. and
people will probably default to allowing everyone to reply-to them.)

Since you couldn't rely on always having REPLYTO envelope headers when
necessary, you'd forever have to do REPLYTO checks after DATA, which
would be the only spf-ish thing left after flag day that would require
after-data checks for everything.

Then even if we did come up with a perfect check for this particular
reply-to problem, it won't affect any clickable links in emails.

So in other words, Reply-To verifications don't really fit into spf-ish
checks of the don't-accept-emails-that-fail-thus-and-such-tests variety.

And in fact, people are likely going to tend to allow default use of
reply-to by anyone (as is proper IMHO), but they aren't going to be
instantly aware that they're a victim to this attack in real time, and
most folks won't reply within seconds of getting the message, so...

So anything to address this reply-to type of issue would probably be
best done at the time of *reply*, meaning the MUA could look at an SPF
record related to the Reply-To address, interpret some sort of macro,
find out whether the message was "legitimate" or not, and possibly get
back some form of data, updated since the message was sent, with all
sorts of useful data for the reply that includes such things as forms,
sample text, relevant data all formatted well, possibly even html code
for the reply (ugh)..

Woohoo, I see a job for XML.  :-)

Not in the SPF record, but perhaps in the response that an spf
replytoinfo= type of modifier could direct an MUA to.  

And what an interesting feature to market to people to get them to
upgrade their MUA's or back-office email-generating software!  And you
can endlessly extend the protocol to endlessly add in (incompatible)
feature after feature.  :-)


Anyway, I'm not sure what all should be in the response such a modifier
could direct the person to; I'm just happy to conclude that, even though
I think that SPF should counter the phishing problem that Ryan brought
up, that we don't want it to similarly (directly) counter problems with
the only remaining unchecked direct body header email address, namely
Reply-To:.

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com