funsec mailing list archives

Re: Public Policy and Consumer ISP Hygiene (was Comcastpop-ups)


From: Rich Kulawiec <rsk () gsp org>
Date: Sat, 17 Oct 2009 11:22:06 -0400

On Sat, Oct 17, 2009 at 09:31:08AM -0400, Larry Seltzer wrote:
That reduces it to a trust decision, right? We've had this option for
years with DKIM, at least at the domain level, and it doesn't seem to
have changed things much.

It hasn't.  It won't.  DKIM/SPF/SenderID/etc. all fall under what I
sometimes call the MAFT: the Mythical Anti-Forgery Technology.

They don't stop spam, because of course spammers can deploy these
as much as anyone can -- and spammers were notable among early
adopters of SPF.

So that leaves forgery, and they don't stop that either -- in the
general case, which I'll get to below.

Would authenticating down to the sender level really improve things? 

Nope.  Because if there are 100M compromised systems out there (and
I am beginning to think the number is closer to 200M, but what's a
hundred million zombies between friends?) then we have to presume
that there are many more compromised sets of email credentials out
there.  (If I had control of your laptop right now, how many of
your home, work, freemail, etc. email accounts would I now own?
So pick a Z for number of zombies, an M for average number of
email accounts per zombie, and compute Z x M.)

We should further presume that additional email credentials have
been and will be disclosed via other means: security breaches
at email providers, weak passwords, etc.  Given all that, I don't
think it's unreasonable to suggest that there are probably 500M
compromised email accounts out there.

Which brings me back to forgery.

If I have your email credentials, then I can forge mail as you
that will pass any MAFT.  Now...it still might be detectable as
a likely-forgery under skilled analysis ("Why is Larry's submitting
IP address in North Korea, when I know that Larry is actually in
Cucamonga?") but that's out-of-reach for any MAFT. [1]

I can do the same for everyone else -- all 500M of them.  And the
mail thus generated, whether it has no payload, or is a phish,
or is part of a spam run, will all happily pass MAFT checks
done on recipient mail servers.

Incidentally, I have a dutifully-DKIM-signed recent 419 spam sample
from a probably-compromised system on Travelocity's internal network
that illustrates this beautifully.  Now...this one was clumsy and
obvious, but had it been a skillful phish, and had it been sent to
someone who's not a paranoid nitpicking bastard, then...

So the MAFT gets us nowhere because the underlying infrastructure
is rotten at the core.

Unless -- and this is the non-general case -- we are dealing with
mail servers that are presumed-secure, all of whose users are
on systems that are presumed-secure.  (I say "presumed-secure"
because I'm reluctant to point at anything and pronounce it "secure".)
But there are probably some small operations which have (let's say)
an OpenBSD mail server locked down within an inch of its life, used
only by three 'nix folks on similarly locked-down systems.  *That*
might be one of the non-general cases where the MAFT actually works.

But it's not going to work at all at Travelocity or Ohio State
or Blue Cross or Oracle or the Treasury Department.  Not.  Happening.
Those networks have Windows systems, therefore they have zombies,
therefore they have compromised email accounts.  (And given the
increasing attacks against MacOS and Linux and so on, I think in
a few years I'll be able to remove the word "Windows" from that
sentence.  But we'll see about that.)

So here's the bottom line: you wanna stop spam?  You're going to
have to figue out how to un-zombie a hundred million zombies
and keep them that way.  And so far, nobody has proposed a viable
way of doing that, and just as important, nobody has proposed a
viable way of *paying* for that.

Me, I think Microsoft should pony up, because it's their mess.
Let's all pause now to contemplate the chances that'll happen.

Okay, that's long enough.

There's a general principle to extract from all this, though, and
it's something I've said many times: spam is a surface indicator
of underlying poor security.  It's certainly not the only one or
even the best one, perhaps, but I think it's helpful to recognize
that while lots of us, including me, talk about "the spam problem",
we're really talking about one symptom of a much deeper problem.
And it's that deeper problem that we have to attack and solve --
dancing around the edges with MAFT or proposed new protocols or
whatever doesn't do a thing about it.

---Rsk

[1] It might be enforced on the submission server, but very few
people actually do this, with good reason.
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.


Current thread: