Subject: [Asrg] AntiSpit Info.

From: [email-masked]
Date: Mon, 14 Feb 2005 15:43:58 +0530 (IST)

If anyone knows about different AntiSpit techniques currently in use or
under development. Could u please give me some pointers to the detailed
information.

Regards,
@

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 14 Feb 2005 15:13:05 -0800

>under development. Could u please give me some pointers to the detailed
You might want to start with the following (brand new) Internet Draft:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-00.txt

-Jim

---

From: "George Ou" <[email-masked]>
Date: Tue, 15 Feb 2005 17:13:57 -0800

According to this article http://www.spamhaus.org/news.lasso?article=156,
spamware has improved it's capability to avoid black listing by using the
legitimate outbound SMTP servers of it's infected victim.  As a result, an
increasing amount of spam is coming from legitimate mail gateways.

Does anyone have more detailed information on spamware and how it manages to
do this?  Does it steal SMTP server configuration information from the
user's email real email client?  Can it also steal stored user credentials
so that it can even work if the outbound SMTP server of the ISP requires
user authentication?  Even if that weren't possible to steal stored
credentials because they're encrypted, couldn't it simply sniff the network
traffic and simply log/capture all SMTP or POP authentication requests?  If
this was true (and there is no reason it couldn't be done), this would mean
that spamware would be able to fool SPF or SenderID.  Can anyone confirm
this?

At this point, the anti-SPF or anti-SenderID folks are probably saying "I
told you so".  I don't believe this was a surprise to the SPF proponents
because it was always known that "throttling" for outbound SMTP would have
to be implemented.  It will probably need to be even more drastic than that,
such as account lock out the minute an outbound message triggers a spam
alert and is verified.

George Ou

---

From: Laird Breyer <[email-masked]>
Date: Wed, 16 Feb 2005 11:33:32 +1000

> do this?  Does it steal SMTP server configuration information from the

If a trojan or spyware/spamware is installed on a user's Windows
computer, then it can do everything a user can do. The actual details
of how it's done don't matter, because you can never fully protect
against that sort of abuse.

All a program has to do is to move the mouse and simulate keyboard
typing and then it has all the privileges of a user. If a password
needs to be typed repeatedly, it can be intercepted and saved. Or the
program can just wait for the user to type in credentials, and then
hijack the mouse and keyboard. Other methods are simply programming
shortcuts.

The only limit is how smart the black hats are, and that depends on how
much they are getting paid to write the spamware.

-- 
Laird Breyer.

---

From: "George Ou" <[email-masked]>
Date: Tue, 15 Feb 2005 18:32:33 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laird Breyer
Sent: Tuesday, February 15, 2005 5:34 PM
To: [email-masked]
Subject: Re: [Asrg] Spammer proxies using legitamate mail relays

On Feb 15 2005, George Ou wrote:
> According to this article 
> http://www.spamhaus.org/news.lasso?article=156,
> spamware has improved it's capability to avoid black listing by using 
> the legitimate outbound SMTP servers of it's infected victim.  As a 
> result, an increasing amount of spam is coming from legitimate mail
gateways.
> 
> Does anyone have more detailed information on spamware and how it 
> manages to do this?  Does it steal SMTP server configuration 
> information from the

>If a trojan or spyware/spamware is installed on a user's Windows computer,
then it can do everything a user can do. The actual details of how it's done
don't matter, because you can never fully protect against that sort of
abuse.

>All a program has to do is to move the mouse and simulate keyboard typing
and then it has all the privileges of a user. If a password needs to be
typed repeatedly, it can be intercepted and saved. Or the program can just
wait for the user to type in credentials, and then hijack the mouse and
keyboard. Other methods are simply programming shortcuts.

Thanks for the detailed response Laird.  I was well aware that once malware
is installed on a computer, the computer is "owned" by the author of that
malware.  I'm simply curious about the actual state of implementation that
spamware has achieved.  "Spamware" is the actual name of the software
written by a Russian programmer as noted by the Spamhaus article.  Spamware
is the platform of choice and is sold to spammers world wide and is being
protected by MCI the former Worldcom and soon to be Verizon.  This is more
of a practical question than a theoretical one, but thanks for your
respones.

George Ou

---

From: Laird Breyer <[email-masked]>
Date: Wed, 16 Feb 2005 13:05:23 +1000

> is installed on a computer, the computer is "owned" by the author of that

Nevermind, I responded quickly without actually RTFA'ing your link, sorry.

I don't know how "spamware" operates, but I can think of at least one
method where spam can be sent completely independently of any user
authentication requirements.

-- 
Laird Breyer.

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 16 Feb 2005 03:42:57 +0000

> spamware has achieved.

I don't think spamware has gone as far as emulating physical user 
input.  It hasn't needed to so far, not by a long way.  Instead, it 
will simply harvest various databases on the machine (Outlook's address 
book, for example), then start opening sockets and spewing SMTP.

The content and immediate destination(s) of the messages spewed in this 
manner is pretty much irrelevant, although the engine appears to be 
able to do various kinds of replacements and mangling on the message to 
get it past content filters.  I imagine a lot of the content production 
work is still done offline, before a spam run.

The above is just an educated guess, however.  I don't actually have 
any of this software to hand for examination, nor do I think I want to. 
  I'd much rather work on the solution than the problem.

--------------------------------------------------------------
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.

---

From: "George Ou" <[email-masked]>
Date: Tue, 15 Feb 2005 19:56:47 -0800

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

>> Thanks for the detailed response Laird.  I was well aware that once 
>> malware is installed on a computer, the computer is "owned" by the 
>> author of that malware.  I'm simply curious about the actual state of 
>> implementation that spamware has achieved.

>I don't think spamware has gone as far as emulating physical user input.
It hasn't needed to so far, not by a long way.  Instead, it will simply
harvest various databases on the machine (Outlook's address book, for
example), then start opening sockets and spewing SMTP.

Not according to the theme of that Spamhaus article.  Spamware now sends
email via the user's legitimate SMTP relay which may even have a legitimate
SPF and/or SenderID record.  This escalates the problem because the spam has
added legitimacy to bypass certain black lists or direct outbound TCP 25
restrictions.  This forces it to the next level where we will need to start
throttling user accounts on the number of SMTP messages it can send using
per hour and per day quotas.  I'm simply curious if Spamware has the ability
to steal user passwords "yet" which is somewhat trivial to a good
programmer. 

>The content and immediate destination(s) of the messages spewed in this
manner is pretty much irrelevant, although the engine appears to be able to
do various kinds of replacements and mangling on the message to get it past
content filters.  I imagine a lot of the content production work is still
done offline, before a spam run.

>The above is just an educated guess, however.  I don't actually have any of
this software to hand for examination, nor do I think I want to. 
  I'd much rather work on the solution than the problem.

Ah, but a solution provider must first fully understand the nature of the
threat in order to counter that threat.  Developing a solution based on a
theory is a waste of time if it can't meet real world threats.  This has
gone way beyond just spewing SMTP with direct connections to the victim's MX
records, an additional layer of counter measure and counter-counter measure
has been added.  We're now in a fight against a product that was designed to
counter SPF and SenderID.  The problem (according to Spamhaus) has now been
shifted to legitimate mail relays.  Still, at least we know who's neck to
choke and we can black list an entire domain that refuses to police it's
users by throttling them and forcing them to clean up, or we can blacklist a
specific user account within that domain.

George

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 16 Feb 2005 04:23:24 +0000

>> input.
> SPF and/or SenderID record.

I'm aware of that.

> I'm simply curious if Spamware has the ability

I don't know the answer to that.  What I can easily guess is that if it 
becomes useful/necessary in order to continue operation, the spammers 
will add that feature post-haste.

>> able to
>> any of
> theory is a waste of time if it can't meet real world threats.

I didn't say I wasn't interested in information.  I'm just not 
interested in ferreting around in the bowels of malware for that 
information, and would rather let others find it and post it somewhere 
useful, like ASRG.

Now, drawing from the information above, we know that spamware doesn't 
yet implement every possible tool that we believe spammers *could* 
use...  but we also know that they adapt pretty darn quickly when they 
see that a new feature becomes necessary to their operation.  If we're 
honest with ourselves, that basic truth has been evident for some time.

So, we need to devise a scheme which they *can't* adapt to.  That's 
what I'm working on.

---

From: Gadi Evron <[email-masked]>
Date: Wed, 16 Feb 2005 08:35:58 +0200

> increasing amount of spam is coming from legitimate mail gateways.

No offense, but for a half-dead list like this, you couldn't follow the 
couple of messages Martin and I sent just last week?

---

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

I wrote a big rant on my blog about this a couple of weeks ago that has 
some more details than this response: 
http://www.livejournal.com/users/jlick/10243.html

George Ou wrote:

>do this?  

It looks at the hostname of the proxy, e.g. adsl-63-29.someisp.com, 
looks up the MX for someisp.com and sends through that.  This has a few 
problems in that the domain of the ISP's clients and the domain of their 
e-mail infrastructure could be different.  Also MX is for incoming 
email, not necessarily outgoing email.  An ISP which blocked their 
client systems from sending out through the incoming MX could defeat 
this until the software gets smarter.

>Does it steal SMTP server configuration information from the
>user authentication?  

Not yet, but one should assume that they will at some point.

>Even if that weren't possible to steal stored
>traffic and simply log/capture all SMTP or POP authentication requests?  
>

In many cases yes.  But POP3, IMAP and SMTP-AUTH submission can all run 
over SSL, and at least IMAP can do a hash-based authentication over 
clear-text.  So there is protection against snooping if one chooses to 
implement the appropriate technologies.  However, you are still left 
with the problem of any credentials used by an owned machine being hijacked.

>If

SPF/Sender-ID only tells you that the message came over an authorized 
channel.  In other words, this would not 'fool' SPF insofar as it 
actually *did* come from an authorized host.  The flip side of this is 
that the source of the message now has to take responsibility for it and 
fix the problem.  Identifying spam involves looking at roughly three 
categories of things: identity, reputation, content.  SPF addresses only 
identity.  And *any* scheme that tries to prove identity is vulnerable 
to a world where millions of machines (and any credentials on them) are 
controlled by bad guys.  Where the identity schemes help is that you can 
hold the sender responsible for the messages.  If they don't, then you 
move on to the reputation part and calculate in the senders that have 
made too many mistakes.

But this method of sending spam already has a huge problem related to 
reputation.  Until now the zombies have mostly been in dynamic IP ranges 
where it is easy to block with minimal to no collateral damage.  
Regardless of whether SPF verfies the source of a message, it already 
came from an ISP's own mail server, one that is often explicitely 
whitelisted.  Following this line of logic, this means big ISP mail 
servers cannot necessarily be whitelisted.  Which means that they will 
have to end up being more aggressively filtered, which means there will 
be more false positives and more legitimate mail thrown out.  Unless the 
ISPs find a better way to control what comes out of their network, in 
which case I refer to my blog entry above.

>"Spamware" is the actual name of the software
>protected by MCI the former Worldcom and soon to be Verizon.
>

Actually the word spamware in the article was used generically.  The 
actual product is called Send Safe and is available over the MCI UUNET 
network at http://send-safe.com/.  You can download demo versions of all 
their products if you are curious what they do.

>This forces it to the next level where we will need to start

Yes, you will probably need to start setting limits.  I talk a lot about 
that in my blog entry at the start of this message.  In order to set 
effective limits, you need to be able to determine which account is 
associated with the sending machine.  Since many ISPs don't have an 
automated method of mapping IP to account, and because the obvious next 
step is for a trojan to grab a new dhcp address every 10 minutes, the 
easier way of being able to identify the account is by requiring 
SMTP-AUTH.  If you can easily determine the account used, then it is 
possible to place limits, flag unusual activity, and correlate incoming 
complaints to an account more easily.  Which allows you to identify and 
isolate compromised accounts on your network more easily

The big change with this development is that now the ISP has an 
incentive to take responsibility for the spam traversing their network, 
because the load directly impacts their ability to provide service.  If 
the ISP in turn implements SMTP-AUTH, then they further give their users 
an incentive not to get their systems owned.  That may not seem like 
much, but given an incentive, I believe they will have to take steps to 
protect themselves.  Ultimately those that don't will find it difficult 
to send email because their reputation will suffer.

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

---

From: "George Ou" <[email-masked]>
Date: Tue, 15 Feb 2005 23:00:01 -0800

Thanks, I'll check out your blog.  Sounds like the spamware code is rather
stupidly written if it has to assume that the MX record is the outbound SMTP
server.  All it would need to do is sniff and capture TCP 25 traffic to
determine the SMTP server and the user credentials since most ISPs don't
enforce SSL for SMTP/POP3 yet.  I guess this idiot wouldn't have to resort
to crime if he had such programming skills.

The bottom line is, we must assume that spamware will eventually be able to
steal passwords even if it has to resort to key logging after it detects a
CTRL-ALT-DEL sequence.

Still, this is better that we force spammers to use legitimate email
accounts rather than just anonymously spew SMTP traffic directly to your
ISP's MX record.  This still gives us more granular filtering by
blacklisting the [email-masked] who likes to click on executable
attachments merely because the email asks them to do so.

George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Lick
Sent: Tuesday, February 15, 2005 10:37 PM
To: Undisclosed-recipients:
Cc: [email-masked]
Subject: Re: [Asrg] Spammer proxies using legitamate mail relays

I wrote a big rant on my blog about this a couple of weeks ago that has some
more details than this response: 
http://www.livejournal.com/users/jlick/10243.html

George Ou wrote:

>manages to do this?

---

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

>this until the software gets smarter.

We observed this attack in September. I'm not sure if the machine being
used by the spammers was a zombie or an open SOCKS proxy - I think the
latter, based on information from an external blacklist and based on
our fairly effective anti-virus protection. Fortunately earlier last
year I had split our MX and our smarthost so I could lock down the MX
properly. I very much recommend that others do so too.

The next pro-active defence is to add some kind of rate limiting...

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHETLAND ISLES: SOUTHWEST 6 OR 7, OCCASIONALLY GALE 8 AT FIRST, VEERING WEST 4
OR 5, OCCASIONALLY 6 IN NORTH WEATHER: RAIN CLEARING TO OCCASIONAL SHOWERS
VISIBILITY: MODERATE BECOMING MAINLY GOOD. ROUGH BECOMING VERY ROUGH IN WEST
AND NORTH