ietf-smtp
[Top] [All Lists]

Re: Options for the ID Command

2005-05-17 22:08:20
On Tue, 17 May 2005 19:25:12 PDT, David MacQuigg said:

We seem to be at an impasse.  There is some difference between your 
understanding of the situation and mine, and I have no idea what that 
difference is.  Maybe someone else can jump in at this point.

The difference is that you're designing a protocol that works when everybody
behaves, while I'm a professional paranoid who makes a good living by assuming
that *everybody* is lying through their teeth and giving the most advantageous
answer, and seeing what breaks. 

OK? You got that straight?  You're assuming that anybody who sends an ID will
be morally upright and honest.  I'm looking at it from the perspective of
"OOoooh. ID command. Nice. Shiny. I wonder what *new* ways I can use this to 
feed
David MacQuigg's mail server totally bogus/invented data to make him accept my
spam".

Ever wonder why obvious spam mail has a *higher* rate of valid SPF records than
non-spam? Because spammers are even more anxious to convince you that they're
for real than legitimate sites are

http://www.techworld.com/security/news/index.cfm?NewsID=2154

SPF comes out May 2004.  Inside 6 months, spammers are using it more than
non-spammers. Even the paranoid in me was surprised - I was expecting it to be
at least a year.

Only if all your SPF parameters don't fit in the _AUTH record.  Normally, 
that record would provide everything you need to authenticate a transfer.

(If you're a security geek, and that one sentence just make klaxons go off and
the DEFCON[1] sign went from 5 straight to 2 without stopping at 4 and 3, you 
can
hit <delete> now. The rest of the mail is just me spelling it out for David and
hopefully getting him up to speed)

That's exactly *WHY* your proposal is even *more* broken than I originally
thought.  It isn't *just* that you're piling all the different "identities"
into one value - you then compound it by leaving that identity under
the attacker's control.

(Hint if you want to work it out on your own before reading further - if an
'ID attacker.com' will fetch the data "X1, Y2, Z3" from _AUTH.attacker.com, then
*semantically* it's equivalent to just saying 'ID attacker.com X1, Y2, Z3' and
putting all that authenticator stuff right there on the ID and saving a DNS
lookup....  See the problem yet?)

You will waste a bunch of DNS queries and possibly conclude this message 
offers no authentication.  For each possible Identity 
(mailserver7.bigforwarder.com, bigforwarder.com, sales.some-company.com, 
some-company.com) you need to search every possible location for DNS 
records (<Identity>, _client._smtp.<Identity>, ...), and we still haven't 
searched all the header identities.

If you don't understand *why* all these different queries are being done,
you totally fail to understand why One Great Answer To It All won't work.

The only records we trust are the ones in the Registry.  The Registry gets 
its information on ratings from the rating services, and its information on 
authentication methods from the domain owner.  It is not normally necessary 
to make a separate query to the domain.

OK.  Let's work out an actual example...

Here's the *real* SPF entry for vt.edu:
vt.edu.                 14400   IN      TXT     "v=spf1 ip4:128.173.0.0/16 
ip4:198.82.0.0/16 mx ptr a:lennier.cc.vt.edu a:lyta.cc.vt.edu 
a:dagger.cc.vt.edu a:vivi.cc.vt.edu a:steiner.cc.vt.edu a:zidane.cc.vt.edu ~all"
Ask any of the 5 registered NS entries for vt.edu, that's what you'll get.

We've not published a DomainKey for vt.edu, so let's pretend we have one that
starts off dk:AA34CF..

Let's say I'm an evil spammer, and I have a zombied machines on a cablemodem at
24.19.4.269.  So I send this from my hijacked cablemodem:

EHLO
ID evil-spammer.com
MAIL FROM:<faked(_at_)vt(_dot_)edu>
... (including rfc822 signed with a DomainKey I generated that starts 
dk:FF973C, and
a 'From: faked(_at_)vt(_dot_)edu'

Now you go to _AUTH.evil-spammer.com, and pull back:

        spf1:ipv4:24.19.4.269/32
        dk:FF973C....

Well.. how about *THAT*?  You fetched "all the data needed to authenticate"
from right where the ID command told you to fetch it.  Now, of *course*, if
that SPF record[2] covers exactly one IP address, and the mail's coming from
that *exact* address (out of the 4 billion possible addresses). It *must* be OK.
And look at that - I gave you a DK-signed mail, and gave you the key that goes
with it.  And the signature is valid.  Wow, this mail must *really* be OK.
I bet if you checked a 3rd authentication method, *that* one would check out
too....

What's wrong with this?  Basically, I've called you on the phone, and said
"This is George W Bush.. I want you to do something for me... If you don't
believe I'm really me, don't bother calling the White House listed number, you
should call (203) 555-1919 instead".  You call 555-1919 and not surprisingly,
the guy at the other end says "Yeah, that was really me, George W Bush..."

Kind of makes you wish you'd called the White House's listed number, doesn't
it? ;)

*now* do you see why you have to make a trip to the DNS servers listed in
the NS for vt.edu to get those records?

Write this on the chalkboard 100 times:

"I will not trust attacker-supplied pointers to attacker-supplied 
authentication data".

(And don't say "but you should have looked at the vt.edu _AUTH entry instead" -
you do and I'll have to hunt you down and smack some sense into you. ;)
        
The record for rr.com includes 6 blocks of 170 IP's and 5 blocks of 4 
each.  Read the proposal.

QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
      +4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)

Gaak.  I never would have guessed. And here I thought it was 5 servers in the
170.24/16 address space and 6 hiding in 4/8 :)

Good thing it was 170 in each block, starting from .1.  150 servers starting at
24.30.23.109[3] and 173 servers at 24.93.47.10 would have complicated this entry
immensely.

----
[1] http://www.fas.org/nuke/guide/usa/c3i/defcon.htm - Cuban Missle Crisis
we went to Defcon 2.  Seems about right.

[2] Don't even *try* to quibble over "it's an SPF for vt.edu" or "it's an SPF
for evil-spammer.com".  Either way, *I* am feeding *you* a crafted SPF that's
(a) not the one you *should* be checking and (b) I've set up to pass my hijacked
machine as OK.

[3]  and remember to DTRT at the 147th server. :)

Attachment: pgpV8NoavQqKU.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>