Subject: Re: [Asrg] "worm spam" and SPF]

From: Fridrik Skulason <[email-masked]>
Date: Sat, 27 Nov 2004 10:14:39 +0000

> No, they are not. They are a critically important part of the 
> robustness of email. Broad acceptance of the idea that bounces are 
> evil will be the last nail in the coffin of email.

Bounces are useful if they go to the person who actually sent the mail.
Those "bounces" do not - they go to an innocent bystander.  Whether this
is due to inherent flaws in the SMTP protocol, sloppy management or
incorrect configuration is arguable - but the fact is that those bounces
are making the problem worse and they NEED to be eliminated.

>Uh, have you heard of Swen???

Swen is NOT an example of the behaviour being discussed.  Most worms
harvest e-mail addresses from the infected machine, and typically 
select one of them at random as the sender.  This can of course result
in the worm sending itself out as being from the "actual" owner of the
machine - however, usually this is not the case.  Swen typically
pretended to be from "MS Technical Support" or something like that.

As far as I know, there is not a single worm in the wild that searches
for the "real" owner of the infected machine and *only* uses that.  I
expect that practice to become more common in the future, as one way
of avoiding SPF checking, but currently this is simply not the case.

-- 
Fridrik Skulason   Frisk Software International   phone: +354-540-7400

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

---

From: Bill Cole <[email-masked]>
Date: Sat, 27 Nov 2004 12:57:32 -0500

>are making the problem worse and they NEED to be eliminated.

On that we agree: bounces should never be the result of some system 
deeming the bounced mail to be in some class that is typically 
malicious or deceptive, i.e. spam of any variety including Microsoft 
OS worm spam.

>Swen is NOT an example of the behaviour being discussed.

Here was the specific context to which I was responding:

     they might even send out email using the user's own email
     account and/or email client.

Swen does that. Really.

>Most worms

Only in the headers. The SMTP envelope of a Swen message is 
consistently the address configured into Outlook Express on the 
infected system, and the mail travels through the configured outbound 
mail server. This is reliable enough that Swen will break on systems 
where those configurations don't work.

>of avoiding SPF checking, but currently this is simply not the case.

Keep in mind that SPF has nothing to do with headers, and is solely 
for SMTP envelope checking. I still see a trickle of Swen even though 
I shun machines transporting it, and SPF does nothing at all to stop 
it.

For example, here's the latest Swen I have where the envelope sender 
domain had an SPF record:

Return-Path: [email-masked]
Received: from mta05-winn.mailhost.ntl.com ([212.250.162.8] verified)
   by sc1.scconsult.com (Stalker SMTP Server 1.8b9d14)
   with ESMTP id S.0000707800 for <[email-masked]>; Mon, 15 Nov 
2004 12:19:11 -0500
Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8])
           by mta05-winn.mailhost.ntl.com with ESMTP
           id 
<[email-masked]>;
           Mon, 15 Nov 2004 17:19:08 +0000
FROM: "Network Message Storage Service" <[email-masked]>
TO: "inet client" <[email-masked]>
SUBJECT:
Date: Mon, 15 Nov 2004 17:19:08 +0000

The relevant SPF record:
ntlworld.com.           43200   IN      TXT     "v=spf1 
ip4:212.250.162.0/26 ip4:62.253.162.0/24 ?all"

-- 
Bill Cole
[email-masked]

---

From: "Larry Seltzer" <[email-masked]>
Date: Sat, 27 Nov 2004 14:14:59 -0500

>>>>     account and/or email client.

No, it doesn't. 

Different versions of Swen do different things to get an SMTP server to
use, but they all use a built-in SMTP engine and none of them use SMTP
AUTH account information. 

In some circumstances Swen will put up a fake MAPI32 exception handler
that asks you for your email account server, username and password (see
a copy at http://www.trendmicro.com/vinfo/images/worm_swen_a_img2.gif).
According to Symantec
(http://securityresponse.symantec.com/avcenter/venc/data/[email-masked]
tml) Swen uses the username and password to check the POP3 account for
copies of itself. So Swen might use the default SMTP server (harvested
from the registry), but that's as close as it gets to using the user's
own e-mail account.

How would a worm work if everyone had SMTP AUTH? It would either have to
use a social engineering trick like Swen does with the MAPI32 dialog -
and there's no evidence that there's a big problem with people filling
out that form - or it would have to find the cached account credentials
in the registry and use them. 

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
[email-masked]

---

From: Bill Cole <[email-masked]>
Date: Sat, 27 Nov 2004 14:53:12 -0500

At 2:14 PM -0500 11/27/04, Larry Seltzer  imposed structure on a 
>>>>>      account and/or email client.

I confess to a lot of ignorance regarding Windows, but are you 
actually stating that the perfect matching I see between SMTP 
envelope senders and the machines handing me Swen is the result of 
tens of thousands of lucky guesses?

>AUTH account information.

I must have missed some previous reference to SMTP AUTH. This is the 
first I recall seeing it mentioned in this conversation.

>from the registry), but that's as close as it gets to using the user's

I know that to not be so in all cases where I've tracked specific 
Swen copies back to the machines sending them and identified the 
owner of the machines. A small set admittedly (4,) however in every 
case the envelope sender was the real email address of the machine's 
owner. Every one of the thousands of Swen's I've seen is consistent 
with the envelope sender being the real email address of the 
machine's owner.

Frankly, I trust the evidence I've seen myself far more than the 
combined opinions of Symantec and a tech journalist. Sorry.

>in the registry and use them.

Worms wouldn't work at all if everyone used competently designed 
operating systems and mailers or if they used the dominant 
garbageware with half a brain. Technical tweaks are nice mind games, 
but the real world argues for them being largely pointless. People 
open encrypted zip files from people they do not know and run the 
contents. There are a lot of perfect fixes for the spam and malware 
problems given a user population that is predominantly not made up of 
blithering idiots. Such solutions are not realistic.

-- 
Bill Cole
[email-masked]

---

From: M Z R <[email-masked]>
Date: Sun, 28 Nov 2004 04:16:35 +0800

> >>>>     account and/or email client.
[snip] 
> copies of itself. 

There it goes, POP-before-SMTP (PBS) defeated. Those who are still
sticking to PBS, guess it's about time they switch to SMTP AUTH.

> in the registry and use them.

It could sniff the outgoing traffic to get the SMTP AUTH pass (not
sure how though??) as almost nobody uses TLS/SSL to encrypt SMTP
traffic.

Regards,

Zia

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 01:51:59 +0100

Bill Cole wrote:

>      they might even send out email using the user's own
>      email account and/or email client.
> Swen does that. Really.

Yes, but not necessarily.  Its installation procedure asks
the user to enter his smart host and credentials, and the
"effects" can be very interesting... ;-)

Generally it was possible to determine the relevant abuse@
for SWEN by looking at the Return-Path, but not _always_

> SPF does nothing at all to stop it.

Yes, SWEN is quite unusual.  SPF could help to enforce the
_always_ in this case, but it can't replace a working abuse@
or the "enforced submission rights" in RfC 2476 option 6.1.

Take care if you send SWEN complaints automatically, it's not
always correct to use the Return-Path with local part abuse@.

                      Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Nov 2004 02:08:13 +0100

M Z R wrote:
 
> There it goes, POP-before-SMTP (PBS) defeated. Those who are
> still sticking to PBS, guess it's about time they switch to
> SMTP AUTH.

SMTP after POP with enforced submission rights is not really
worse than AUTH PLAIN without TLS or AUTH LOGIN.  For unknown
reasons folks often confuse SMTP AUTH with enforced submission
rights.  An MSA allowing any MAiL FROM for authenticated users
is much worse that SMTP after POP enforcing submission rights.

APOP is arguably "better" than an AUTH PLAIN without TLS - in
theory the latter isn't allowed, but...

> almost nobody uses TLS/SSL to encrypt SMTP traffic.

...exactly.  Bye, Frank