Subject: [Asrg] How to defeat spam that uses encryption?

From: Jason Hihn <[email-masked]>
Date: Mon, 31 Mar 2003 10:49:19 -0500

If I were a spammer (I am not) I'd start encrypting messages to throw off
content filtering. Public keys are easily obtainable and are readily
associated with good email addresses.

Also, but not quite as complex:
A few years ago, I 'invented*' a way to encode a whole web page as a long
string. This string is a variable in JavaScript. When it's opened, a
function is applied to the string where it's decoded contents are written to
the browser. Imagine a simple ROT13 decoder. What's more is Bayesian
filtering would fail because the spammer can invent pads, and ROT bases,
thereby inventing new 'words' in the dictionary all the time.

Just a thought of what's to come...

* I probably wasn't the first, but I never found anything like it elsewhere
on the web at the time I did it. Originally it was to hide content from
hosting services (or browsers, a la secret key pad entered into a form or
JavaScript prompt.)- they'd actually have to view it in a JS enabled
browser. 'Grep'ing the file wouldn't work.

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

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 31 Mar 2003 09:55:24 -0700 (MST)

> From: Jason Hihn <[email-masked]>

> associated with good email addresses.

Many spammers encode their efforts as quoted-printable, base64,
or even both (never mind the MIME RFCs and MUA behavior).  However,
the stuff must still be deccode or decrypted at zillions of targets
or spamming is wasted effort.  If it can be decoded to show to a human,
then it can first be decoded for a filter.

> ...

That's all old hat.
The anti-spam counter is to apply the insight that wrecks most content
management schemes.  That insight is that it must be made intelligible
to humans, and that which is intelligible to humans can be recorded
and analyzed.  Some current spam filters spend more or less effort
render the HTML/Javascript/wathever before filtering.

The counter to that is to send spam that harder to analyze.  For
example, last year some stock-fraud spam was purely graphical, such
as URLs of pictures of text.
The counter to that is for filters to recognize naughty URLs.

And so forth.

As others have said, this is a never ending cycle.  The 6 years I've
been running content analyzing filters have convinced me that the
advantage lies with the defense.  Techically, I think it should be
easier to evade filters.  I've never built a filter that wouldn't be
easier to evade than to operate.  Spammers are always slow and behind.
Why?

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

---

From: Jason Hihn <[email-masked]>
Date: Mon, 31 Mar 2003 12:36:56 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Vernon Schryver
> Sent: Monday, March 31, 2003 11:55 AM
> To: [email-masked]
> Subject: Re: [Asrg] How to defeat spam that uses encryption?
>
>

The difference here is that a scheme that I describe exists as JavaScript
code until render time. The observation here to make is that render time is
AFTER decode time. Base64, mime,  and ROT13 can be done using compiled code
already in the client, so it can filter after that is done. By throwing it
into JavaScript, it's not rendered until shown.

> advantage lies with the defense.  Technically, I think it should be

They are lazy and reactive as we are: they only want to do a minimum amount
of work to keep doing their thing. We react, and they have to react to our
reaction. Coming up with the perfect method of spam would only shorten their
lives, as a perfect method would draw 100% of the spammers, and therefore
100% of anti-spammers attempting to kill it off. It's much better for them
to play this cat-and-mouse game.

We could implement a complete anti-spam infrastructure that would take all
the method and motive out of spamming, but this list has proven to me that
we'll never take that step because admins are lazy.

I came up with (what I thought was) the most important piece of a system to
ending spam and I got baulked at. It was not hard to implement, but no one
seemed to think it important.

(It was a mail protocol negotiation proxy, so the internet could use
multiple mail protocols, each protocol can easily be replaced, or upgraded.
If the preferred supposed spam-unfriendly protocol was not used, there would
be some 'penalty' (delay, filtering, tar proxy) imposed. This would allow
protocols to compete, with the bonus of weaking spam techniques, because
hopefully, the same technique won't work on all protocols.)

---

From: Markus Stumpf <[email-masked]>
Date: Mon, 31 Mar 2003 19:19:47 +0200

On Mon, Mar 31, 2003 at 09:55:24AM -0700, Vernon Schryver wrote:
> or even both (never mind the MIME RFCs and MUA behavior).

You mean like in
    Perfo<!--|s=3zd=3FAizd[S0=|d,F08F3-->rmance
    En<!--|s=3zd=3FAizd[S0=|d,F08F3-->hancer
    Enla<!--|s=3zd=3FAizd[S0=|d,F08F3-->rgement
> easier to evade than to operate.  Spammers are always slow and behind.

If they are so far behind, why do/did messages of these type pass so much
"ahead" content filters?

> However,

Do you suggest I should write down the passphrase to my private key in
some file so that the filter can decode incoming encrypted emails?

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked] (Justin Mason)
Date: Mon, 31 Mar 2003 13:18:13 -0800

> If they are so far behind, why do/did messages of these type pass so much

Hmm.  *Do* they?  I haven't heard of any filters, apart from the "A Plan
For Spam" style ones which do not even trivially decode HTML, that are
vulnerable to this.

SpamAssassin certainly isn't; in fact, it makes a great spam sign for us.
But about twice a week, someone posts to the SpamAssassin-talk list asking
if we're worried about this "new technique", which gets irritating after a
while.

BTW, in response to Vernon's original comment --  the reason at least one
spam tool uses QP/Base64 encoding on normal text, is to evade *AOL's*
content filters and bulk-mail detectors specifically.  By adding a random
"hashbuster" at the start of the mail, the base64 text changes radically
and requires a totally different fuzzy hash signature.  (I read the
tool's documentation ;)

--j.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 31 Mar 2003 17:11:57 -0700 (MST)

> From: Markus Stumpf <[email-masked]>

> > easier to evade than to operate.  Spammers are always slow and behind.

No, I call that the <!--HTML-comment--> hack.  A varient is the use
of random strings between <> brackets.  Browsers generally ignore that
they don't understand

Base64 and quoted-printable are older and far more common tactics.

> If they are so far behind, why do/did messages of these type pass so much

They have to win occassionally for a little while.  

> some file so that the filter can decode incoming encrypted emails?

That would be a problem, but only in the impossible but desirable
eventuality that encrypted mail became common.

  ...

] From: [email-masked] (Justin Mason)

] > If they are so far behind, why do/did messages of these type pass so much
] > "ahead" content filters?
]
] Hmm.  *Do* they?  I haven't heard of any filters, apart from the "A Plan
] For Spam" style ones which do not even trivially decode HTML, that are
] vulnerable to this.

at least not after the first month or two the use of <!--HTML-comments-->

] ...
] BTW, in response to Vernon's original comment --  the reason at least one
] spam tool uses QP/Base64 encoding on normal text, is to evade *AOL's*
] content filters and bulk-mail detectors specifically.  By adding a random
] "hashbuster" at the start of the mail, the base64 text changes radically
] and requires a totally different fuzzy hash signature.  (I read the
] tool's documentation ;)

That implies that AOL's content filter could be improved.  You must
decode QP and Base64 before computing hashes, because there are MTAs
that add and remove at least QP and I think sometimes Base64 encoding.
If you don't always decode, you can't get consistent signatures.

Another case of that problem is that if your filter system works in
both the MTA and the MUA, then you must decode QP and B64 whenever you
see it and especially in the MTA, because when you see it in the MUA,
it will be decoded.

I think this applies to virus scanners as well.

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 31 Mar 2003 23:30:14 -0500

>easier to evade than to operate.  Spammers are always slow and behind.

Because until recently so few people ran filters that it wasn't worth 
the effort to work around them?
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg