ietf-asrg
[Top] [All Lists]

Re: [Asrg] Spammer proxies using legitamate mail relays

2005-02-15 23:43:22
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