Subject: Re: [Asrg] Spammer proxies using legitamate mail relays

From: Jonathan Morton <[email-masked]>
Date: Wed, 16 Feb 2005 05:28:33 +0000

>> So, we need to devise a scheme which they *can't* adapt to.  That's 
>> what
>> I'm working on.
>
> I don't believe there ever will be a full prove way.  It will be a
> continuing struggle of measure counter-measure.

Have a think about the following scheme, then, which I'm in the process 
of implementing.  If you can, I'd like you to point out any chinks in 
the armour.

You've heard of hashcash, naturally.  As a proof-of-work system, it is 
simple in concept - physically prevent spammers from being able to 
generate lots of (deliverable) mails per second per host, by chewing up 
their CPU time.  The disadvantage of hashcash, when used on it's own, 
is that it also limits the rate at which legitimate mails can be sent.

There is also the concept of whitelists.  However, addresses can be 
spoofed in today's e-mail, so conventional whitelists can be 
circumvented by plundering the address book from a zombie and doing a 
bit of guesswork.  One solution is to use a cryptographic signature, 
unique to the sender/recipient pair.  This still leaves the 
introduction problem - how do you get on the whitelist and hand over 
the signature verification keys?

The solution is to allow a signature *or* a hashcash token to get a 
message past the filter.  The first messages of an e-mail exchange 
contain hashcash tokens, which are expensive enough to prevent spammers 
from flooding inboxes as they do today (with today's estimated zombie 
population, that means 27 bits or more).

In this first exchange, signature keys are also exchanged, and are used 
for computationally-cheap conversation subsequently.  The protocol 
would ensure that only genuinely two-way conversations would be able to 
set up signature relationships.  The signature relationship involves a 
pair of asymmetric key-pairs, one for each direction of message flow.  
The private key is, of course, used for signing, and the public key for 
verification.  There is no relationship between the body of the message 
and it's signature - the signature merely has to be unique for each 
message, a fact which is enforced using a double-spend database just 
like hashcash.

Because of Moore's Curves, the threshold value of the initial hashcash 
token would have to be increased over time, by approximately 1 bit 
every 18 months if past trends continue.  This can be accomplished 
either by application of an internal date-based formula, or by 
occasional reference to a DNS entry, or else by a manual configuration 
entry (the latter is discouraged).  This factor I believe is 
manageable.

A further problem is that some situations have limited processor power, 
but still need to send mail to a diverse range of recipients with 
tolerably low latency.  Sales and tech-support desks would be good 
examples, as would the low-power mobile phone.  Solutions include a 
"captive zombie" approach where hashcash stamp production is 
intentionally farmed out to all workstations in the department, 
reducing latency but not affecting total throughput - if businesses 
really don't want to subscribe to the thin-client model, they might as 
well harness the benefits of the fat-clients they already have.  The 
solution for mobile and thin-client situations is to have stamp 
production done (possibly for a fee) by a server farm just upstream of 
the client.

The remaining problems centre on mailing lists and legacy users.  I'll 
deal with mailing lists first.  The obvious solution is to have the 
listservs implement the scheme natively, and benefit from the stronger 
subscriber authentication.  A signature relationship can be defined 
during the standard double-opt-in process, obviating the need for the 
listserv to generate hashcash many times for each message it processes. 
  A listserv that doesn't implement the scheme should look just like any 
other legacy user, whom we will now deal with.

Legacy users are a sticky problem - literally.  However, we can 
consider the hashcash and signatures as acting like a bypass mechanism. 
  Messages without valid hashcash or a valid signature are directed into 
a content filter.  Because there is now a foolproof way to avoid being 
processed by that filter, it can be a lot more aggressive than usual, 
thus reducing false negatives.  Eventually, when participation is 
sufficiently high, it could become a straight blackhole.

To help participation figures, Eric and I have been considering how to 
get the ISP involved, seeing as MUA plugin systems are presently highly 
proprietary and thus hard to deploy rapidly.  The easiest solution 
seems to be to install a daemon on the user's machine, which stays in 
contact with software attached to the ISP's MTA.  The latter then 
notifies the former when it receives a message from the user that 
requires hashcash, allowing the user to accelerate delivery far more 
than the ISP would economically be able to do alone.

The software attached to the MTA would take over hashcash production 
(generally at a much slower rate) if necessary, and also handle all 
signature and filtering duties - thus ensuring that all clients of the 
ISP participate in the scheme.  This is, of course, best combined with 
SMTP AUTH to prevent zombies from exploiting other clients of the same 
ISP.

For the avoidance of doubt, the working title is, at present, 
RubberStamp.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email-masked]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "George Ou" <[email-masked]>
Date: Tue, 15 Feb 2005 21:46:07 -0800

-----Original Message-----
From: Jonathan Morton [mailto:[email-masked]] 
Sent: Tuesday, February 15, 2005 9:29 PM
To: George Ou
Cc: ASRG
Subject: Re: [Asrg] Spammer proxies using legitamate mail relays

---SNIP----
Have a think about the following scheme, then, which I'm in the process of
implementing.  If you can, I'd like you to point out any chinks in the
armour.

You've heard of hashcash, naturally.  As a proof-of-work system, it is
simple in concept - physically prevent spammers from being able to generate
lots of (deliverable) mails per second per host, by chewing up their CPU
time.  The disadvantage of hashcash, when used on it's own, is that it also
limits the rate at which legitimate mails can be sent.

There is also the concept of whitelists.  However, addresses can be spoofed
in today's e-mail, so conventional whitelists can be circumvented by
plundering the address book from a zombie and doing a bit of guesswork.  One
solution is to use a cryptographic signature, unique to the sender/recipient
pair.  This still leaves the introduction problem - how do you get on the
whitelist and hand over the signature verification keys?

The solution is to allow a signature *or* a hashcash token to get a message
past the filter.  The first messages of an e-mail exchange contain hashcash
tokens, which are expensive enough to prevent spammers from flooding inboxes
as they do today (with today's estimated zombie population, that means 27
bits or more).

In this first exchange, signature keys are also exchanged, and are used for
computationally-cheap conversation subsequently.  The protocol would ensure
that only genuinely two-way conversations would be able to set up signature
relationships.  The signature relationship involves a pair of asymmetric
key-pairs, one for each direction of message flow.  
The private key is, of course, used for signing, and the public key for
verification.  There is no relationship between the body of the message and
it's signature - the signature merely has to be unique for each message, a
fact which is enforced using a double-spend database just like hashcash.

Because of Moore's Curves, the threshold value of the initial hashcash token
would have to be increased over time, by approximately 1 bit every 18 months
if past trends continue.  This can be accomplished either by application of
an internal date-based formula, or by occasional reference to a DNS entry,
or else by a manual configuration entry (the latter is discouraged).  This
factor I believe is manageable.

A further problem is that some situations have limited processor power, but
still need to send mail to a diverse range of recipients with tolerably low
latency.  Sales and tech-support desks would be good examples, as would the
low-power mobile phone.  Solutions include a "captive zombie" approach where
hashcash stamp production is intentionally farmed out to all workstations in
the department, reducing latency but not affecting total throughput - if
businesses really don't want to subscribe to the thin-client model, they
might as well harness the benefits of the fat-clients they already have.
The solution for mobile and thin-client situations is to have stamp
production done (possibly for a fee) by a server farm just upstream of the
client.

The remaining problems centre on mailing lists and legacy users.  I'll deal
with mailing lists first.  The obvious solution is to have the listservs
implement the scheme natively, and benefit from the stronger subscriber
authentication.  A signature relationship can be defined during the standard
double-opt-in process, obviating the need for the listserv to generate
hashcash many times for each message it processes. 
  A listserv that doesn't implement the scheme should look just like any
other legacy user, whom we will now deal with.

Legacy users are a sticky problem - literally.  However, we can consider the
hashcash and signatures as acting like a bypass mechanism. 
  Messages without valid hashcash or a valid signature are directed into a
content filter.  Because there is now a foolproof way to avoid being
processed by that filter, it can be a lot more aggressive than usual, thus
reducing false negatives.  Eventually, when participation is sufficiently
high, it could become a straight blackhole.

To help participation figures, Eric and I have been considering how to get
the ISP involved, seeing as MUA plugin systems are presently highly
proprietary and thus hard to deploy rapidly.  The easiest solution seems to
be to install a daemon on the user's machine, which stays in contact with
software attached to the ISP's MTA.  The latter then notifies the former
when it receives a message from the user that requires hashcash, allowing
the user to accelerate delivery far more than the ISP would economically be
able to do alone.

The software attached to the MTA would take over hashcash production
(generally at a much slower rate) if necessary, and also handle all
signature and filtering duties - thus ensuring that all clients of the ISP
participate in the scheme.  This is, of course, best combined with SMTP AUTH
to prevent zombies from exploiting other clients of the same ISP.

For the avoidance of doubt, the working title is, at present, RubberStamp.

---SNIP----

Most effective anti-spam systems already implement a wide range of every
practical anti-spam technique available and are always in a state of
evolution.

Most hashcash proponents are already for a hybrid system that would skip the
computationally intensive part for relatively strong authenticated senders.
For example, senders from reputable domains that comply with SPF and/or
SenderID or maybe even domain keys should be allowed to skip hashcash.  For
bulk senders, they should have to have a registered (or bonded) domain using
DomainKeys because of it's non-repudiation for any spam they spew.  For all
other email that hasn't been verified by SPF/SenderID/DomainKeys, they
should be brutally punished with a one minute computation (on a dual 3.6 GHz
XEON box) for every message they want to send.  If they don't want to
compute it, too bad.  The only problem for hashcash is that spammers already
have a massive SuperGrid available to them in the form of Zombies that
currently act as SMTP proxies.  I guess that means we'll either need to flag
them as suspicious and place the messages in a quick flush folder or we'll
just need to drop them.

As for Moore's law, the major CPU vendors have been in violation of it for
nearly 2 years now.  Intel's been stuck in the 3 GHz funk for 2 years now
and they're going to start resorting to multi-cores like every other CPU
vendor.

Bottom line is, anti-spam technology is getting better but the spammers are
still one step ahead.

George

---

From: James Lick <[email-masked]>
Date: Wed, 16 Feb 2005 14:39:20 +0800

Jonathan Morton wrote:

>
> You've heard of hashcash, naturally.  

And exactly how long do you expect it will take for spammers to install 
a hashcash computing trojan on their 5 million zombie PCs?  That's *way* 
more computing power at their disposal than anything we have available.

-- 
James Lick -- 黎建溥 -- [email-masked] -- http://jameslick.com/

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 16 Feb 2005 06:56:49 +0000

> SenderID or maybe even domain keys should be allowed to skip hashcash.

SPF alone isn't sufficient reason to skip hashcash, as your original 
post should make clear.  The concept of "reputable" is also woolly, in 
non-obvious ways - it's much simpler and less "gameable" to just 
require hashcash regardless.

> For bulk senders, they should have to have a registered (or bonded) 
> domain using
> DomainKeys because of it's non-repudiation for any spam they spew.

You're right - a bonded-domain system could be another string to the 
bypass bow.  It doesn't really break the system, though, it's just an 
addition to consider.

> For all
> compute it, too bad.

That, I'm afraid, discriminates unfairly against ordinary users with 
old machines on small, backwater ISPs, which is one of the reasons 
plain hashcash doesn't quite work.

> The only problem for hashcash is that spammers already

The 27-bit (plus) hashcash cost actually takes into account the 
potential zombie population.  Strangely enough, we were able to 
discover a point where spammers' profit-per-message went through the 
floor, even when they could get as many zombies as they liked for free.

> and they're going to start resorting to multi-cores like every other 

When it comes to computing SHA-1 collisions, there are a number of 
special optimisations which are unlocked by newer processors.  The 
Motorola/IBM processors have *not* been in violation of Moore's Curves 
in recent history, and thus the current crop of PowerPC 970s is capable 
of 9 million collisions per second (at 2GHz, per CPU), a long way ahead 
of the P4.  AMD have also been steadily improving *their* chips, which 
are also usually faster in real terms than the P4.

At the moment, the sweet spot in price/performance, when it comes to 
hashcash, is the Mac Mini.  It's small and power-efficient, so you can 
put lots of them into a colocation shelf, without paying over the odds 
for air conditioning.  It's also cheap, at $399 for about 6 million 
collisions per second.  I advise using that figure for any cost 
calculations.

> Bottom line is, anti-spam technology is getting better but the 

Yes, they are at the moment.  But that's because the general e-mail 
industry is highly inertial, and it takes some time to convince them to 
adopt each incremental change.  So we introduce one measure - SPF - and 
by the time half the ISPs have started using it, the spammers have all 
adapted so that it's having no effect on overall volume, even if it 
happens to make the next step much easier to implement.

I'm trying to put forward a solution that actually reduces volume, and 
cannot be sidestepped.

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 16 Feb 2005 07:05:20 +0000

> And exactly how long do you expect it will take for spammers to 
> install a hashcash computing trojan on their 5 million zombie PCs?  
> That's *way* more computing power at their disposal than anything we 
> have available.

Is it?  There are 5 million zombies, perhaps, but there are many *more* 
legitimate e-mail users.  At the very least, that allows us to get the 
"percentage of e-mail that is spam" down below the 50% mark that it 
passed many months ago.  Remember that spammers have to spread those 
zombies out among all their campaigns and targets.

Right now, each zombie can send tens or hundreds of messages a second.  
Reducing that to one or less per minute would, in itself, put a big 
damper on their operations.

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Feb 2005 11:44:23 +0000

Jonathan Morton <[email-masked]> wrote:
>There are 5 million zombies, perhaps, but there are many *more* 
>legitimate e-mail users.

If you want to analyse hashcash's effectiveness, you should read
Richard Clayton and Ben Laurie's paper which uses real numbers
from a medium-sized ISP to show that it cannot be made to work.

http://www.cl.cam.ac.uk/~rnc1/

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: NORTHEAST 3 OR 4
BECOMING VARIABLE 3 OR LESS, BUT MAINLY NORTH OR NORTHWEST 3 OR 4 LATER
WEATHER: OCCASIONAL RAIN OR DRIZZLE LATER. GOOD BECOMING MODERATE.

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 16 Feb 2005 12:17:20 +0000

> from a medium-sized ISP to show that it cannot be made to work.

Yes, I've read it.  It assumes naive PoW is in use, but what I'm 
talking about is *not* naive PoW - it gives a significant advantage 
back to legitimate users, by eliminating virtually all the processing 
overhead (it goes down to a few SHA-1 hashes and an RSA encrypt) from 
repeat contacts between consenting parties.

That means the hashcash threshold value can be set based on the impact 
on spammers (who are *not* making repeat contacts, except for the 
0.003% response rate), instead of having to watch out for legitimate 
users so much.  Of course, we still have to watch out for the classes 
of users for whom generating even one stamp could be a significant 
hardship, but the solution there is upstream infrastructure to help 
them generate the stamp, not to reduce the stamp size and dilute the 
benefits.

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 16 Feb 2005 12:21:23 +0000

I know next to nothing about Windows, but can this (etc) be easily (?) got
from the registry?

HKEY_CURRENT_USER -> Software -> Microsoft -> Internet
Mail and News -> Mail:
DefaultSMTPServer

---

From: "Larry Seltzer" <[email-masked]>
Date: Wed, 16 Feb 2005 07:54:06 -0500

>>HKEY_CURRENT_USER -> Software -> Microsoft -> Internet Mail and News
-> Mail:
DefaultSMTPServer

This is not a standard value in Windows. It may be common, but you can't
rely on it. I've just tested 3 systems and found it on none. 

Windows, Outlook, Outlook Express and other mail clients change the
location of their server values even from version to version. This is
far from an insurmountable obstacle, but it makes the job non-trivial.
In all likelihood the encoding in the registry for the passwords changes
from version to version. Outlook 2003 doesn't store even the SMTP server
in plain text or an obvious location anymore.

But it can be done. See Passware (http://www.lostpassword.com/) for
programs that can crack cached credentials for almost anything, and I've
specifically tested it against SMTP AUTH credentials.

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 16 Feb 2005 08:16:24 -0500 (EST)

> specifically tested it against SMTP AUTH credentials.

Port 25 on "mail" or "smtp" is a valid smtp relay not requiring any
authentication for more than half of ISPs. The Windows resolver will fill
in the domain part of the relay host name. I have seen no claims that any
spamware *at the moment* goes any further than this, although of course as
time goes by it will do whatever is necessary.

I do hope that ISPs don't get the idea the way to fight this is to obscure
the MTA name.

---

From: Bill Cole <[email-masked]>
Date: Wed, 16 Feb 2005 08:55:05 -0500

>I do hope that ISPs don't get the idea the way to fight this is to obscure

There is a next obvious step for the zombieware: keep an eye out for 
any outbound port 25 connections. If ZoneAlarm can do it, there's no 
reason a trojan can't.

Or it could just ask the user. That has worked for Swen for a year and a half.

-- 
Bill Cole
[email-masked]

---

From: "George Ou" <[email-masked]>
Date: Wed, 16 Feb 2005 11:50:00 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill
Cole
Sent: Wednesday, February 16, 2005 5:55 AM
To: [email-masked]
Subject: RE: [Asrg] Spammer proxies using legitimate mail relays

>There is a next obvious step for the zombieware: keep an eye out for any
outbound port 25 connections. If ZoneAlarm can do it, there's no reason a
trojan can't.

>Or it could just ask the user. That has worked for Swen for a year and a
half.

Enforcement of SSL for SMTP/POP3 is a very good thing to require for
security in general and will make it more difficult to sniff TCP 25 for
clear text credentials.  But to stay up to speed with the spammers, we must
simply assume that zombieware at some point will be able to acquire the
user's full SMTP server name and full username/password credentials in the
vast majority of cases using any means necessary.  The question is what to
do about it.

James Lick makes some great points on what can be done i.e. rate limiting,
outbound scanning and account lockout.  But the problem is getting the
cooperation from ISPs to put in the time and effort.  At the very least,
SenderID and SPF will force some accountability and we will be able to
accurately black list individual email accounts on ISPs that enforce SMTP
AUTH.

George

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 16 Feb 2005 16:19:16 -0500 (EST)

"George Ou" <[email-masked]> wrote:

> James Lick makes some great points on what can be done i.e. rate
> limiting, outbound scanning and account lockout.  But the problem is
> getting the cooperation from ISPs to put in the time and effort.  At
> the very least, SenderID and SPF will force some accountability and
> we will be able to accurately black list individual email accounts
> on ISPs that enforce SMTP AUTH.

What do you mean "we"?  The chances of a small domain getting enough
spam (even more than 1) from any individual zombie will be quite
small, providing spammers distribute well.  So blacklisting individual
accounts will either require a huge public list, or a major recipient
domain.

The rest of us will have to blacklist the entirety of any ISP that
doesn't cut off its zombies.

Seth

---

From: "George Ou" <[email-masked]>
Date: Wed, 16 Feb 2005 15:28:54 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Seth
Breidbart
Sent: Wednesday, February 16, 2005 1:19 PM
To: [email-masked]
Subject: Re: [Asrg] Spammer proxies using legitimate mail relays

"George Ou" <[email-masked]> wrote:

>What do you mean "we"?  The chances of a small domain getting enough spam
(even more than 1) from any individual zombie will be quite small, providing
spammers distribute well.  So blacklisting individual accounts will either
require a huge public list, or a major recipient domain.

>The rest of us will have to blacklist the entirety of any ISP that doesn't
cut off its zombies.

>Seth

Blacklisting entire domains because of an irresponsible and negligent ISP
that doesn't police it's own users or network is fine with some but not for
others.  Unfortunately, killing off legitimate email is a very sensitive
topic.  The trick/challenge is getting the entire industry to agree to a
formal "treaty" of some sort of what acceptable ISP behavior is, and then
getting the entire industry to black list entire domains in unison to force
an instant change in behavior of irresponsible ISPs.  Basically, we want to
avoid the slow boil syndrome since ISPs are stupid enough to stay in the
water and tolerate a certain level of black listing.

George

---

From: Gadi Evron <[email-masked]>
Date: Thu, 17 Feb 2005 01:46:58 +0200

> cooperation from ISPs to put in the time and effort.  At the very least,

As was said before, this evolution of the spammers is a Good Thing. It 
means there will be less spam, and not very spoofed.

What it also means is that ISP's pipes may take less of a beating, but 
their servers will be over-whelmed.

ISP's will take action, or lose. It's not a "go figure how to convince 
them" type of thing. They will get there on their own.

	Gadi.

---

From: "George Ou" <[email-masked]>
Date: Wed, 16 Feb 2005 16:03:56 -0800

-----Original Message-----
From: Gadi Evron [mailto:[email-masked]] 
Sent: Wednesday, February 16, 2005 3:47 PM
To: George Ou
Cc: 'Bill Cole'; [email-masked]
Subject: Re: [Asrg] Spammer proxies using legitimate mail relays

>> the very least,

>	Gadi.

Change is a difficult thing for many organizations.  It's not the actual
technical change itself, but the bureaucratic process.

As for servers taking a beating, cheap fast computers are the least of our
worries compared to reoccurring bandwidth costs.  Unfortunately, there are
many organizations that would rather pay $10K a year on hardware maintenance
for an old Sun box that goes for $1000 on eBay than go out and build a cheap
and high-powered WinTel or LinTel computer.

George

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 16 Feb 2005 19:55:17 -0500 (EST)

"George Ou" <[email-masked]> wrote:

> Blacklisting entire domains because of an irresponsible and
> negligent ISP that doesn't police it's own users or network is fine
> with some but not for others.

Agreed.

>  Unfortunately, killing off legitimate email is a very sensitive
> topic.

Also true.

>  The trick/challenge is getting the entire industry to agree

Ain't never gonna happen, so quit there.

> Basically, we want to avoid the slow boil syndrome since ISPs are
> stupid enough to stay in the water and tolerate a certain level of
> black listing.

When the pain gets high enough, they notice.  They notice AOL yelling
at them now, for instance.

Seth