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 idiot(_at_)someISP(_dot_)com who likes to click on executable
attachments merely because the email asks them to do so.
George
-----Original Message-----
From: asrg-bounces(_at_)ietf(_dot_)org
[mailto:asrg-bounces(_at_)ietf(_dot_)org] On Behalf Of
James Lick
Sent: Tuesday, February 15, 2005 10:37 PM
To: Undisclosed-recipients:
Cc: asrg(_at_)ietf(_dot_)org
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:
Does anyone have more detailed information on spamware and how it
manages to 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'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?
Not yet, but one should assume that they will at some point.
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?
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
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?
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
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.
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
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.
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 -- 黎建溥 -- jlick(_at_)jameslick(_dot_)com -- http://jameslick.com/
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg