Latest spammer trick stymied
Lately (as prophesied), there have been a number of very short spams arriving, containing only a singleton URL. My proxy's classifier was giving these an "unsure" rating -- too few clues. But, these buggers were starting to become quite annoying... So today I added a simple web-crawler, which will venture out on demand and slurp the words off any site. This little hoover is only unleashed when the number of distinct clues/words in an email is less than 150, it's heading for the "unsure" bucket, and we find an http URL in there. The entire source HTML is then whacked through the tokenizer and classified. The extra servlet processing can take a couple seconds, mostly network overhead, and really only noticeable when paying close attention to message download times, but the results are really worth it! It nails them dead. Cheers! Richard
At 09:14 PM 3/31/03 +1000, Richard Jowsey wrote:
So today I added a simple web-crawler, which will venture out on demand and slurp the words off any site. This little hoover is only unleashed when the number of distinct clues/words in an email is less than 150, it's heading for the "unsure" bucket, and we find an http URL in there. The entire source HTML is then whacked through the tokenizer and classified.
Won't this just convince spammers that: 1) Their spam is "working", because "people are clicking on the link", and 2) If there's a unique ID in the URL, it will confirm that your address is live and that you're a sucker for whatever it is they mailed you. :) Of course, I also suppose it's possible that if enough people install a spam filter that works this way, the resulting "spambayes effect" might crash a few of their servers. :)
"Phillip J. Eby" wrote Won't this just convince spammers that:
1) Their spam is "working", because "people are clicking on the link", and
So? More fool them - hopefully they'll spend more money on this useless technique, and go broke, sooner.
2) If there's a unique ID in the URL, it will confirm that your address is live and that you're a sucker for whatever it is they mailed you. :)
I figure there's little or no point to trying to hide addresses from spammers. Unless you never ever post to a mailing list, or to anyone off-site, and you've got a non-obvious username, they're going to get your address anyway.
Of course, I also suppose it's possible that if enough people install a spam filter that works this way, the resulting "spambayes effect" might crash a few of their servers. :)
Well, if nothing else, the useless load on their webserver helps push a little of the cost of spam back towards the spammer. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
3/31/2003 6:51:03 AM, Anthony Baxter <anthony@interlink.com.au> wrote:
Well, if nothing else, the useless load on their webserver helps push a little of the cost of spam back towards the spammer.
We have to be careful with this. It would be relatively simple to stymie, by simply adding two urls, the spam one, and an unrelated innocent site. Or three urls, or whatever... We definitely should NOT crawl the site, just in case it really is an innocent url. The load can crush a site, particularly if it's hosted. BUT, if we don't crawl the site, then the trick is easily stymied by simply having the page be a linked jpg with the appropriate information, or a flash, or whatever... so we're darned if we do, darned if we don't. Spambayes is superb at recognizing spam based solely upon the payload received. If these mails are slipping through, then we need to examine the clues and see why. Can you show us the clues for one of your mails that headed for unsure? At the moment, we clue url:<chunk>, which is very likely to become a hapax. Perhaps a better solution is to create a token for the presence of a url... c'est moi - TimS http://www.fourstonesExpressions.com http://wecanstopspam.org There are 10 kinds of people in the world: those who understand binary, and those who don't.
We have to be careful with this. It would be relatively simple to stymie, by simply adding two urls, the spam one, and an unrelated innocent site. Or three urls, or whatever...
Spammers are simple folk. They won't be putting no innocent url's in these spams...
We definitely should NOT crawl the site, just in case it really is an innocent url. The load can crush a site, particularly if it's hosted.
Nah. You need to throw thousands of requests at a half-decent web server before it gives up the ghost. And if they're sending out 10 million mail pieces, they should expect their http server to take some load. These are definitely NOT innocent emails. They come from bogus senders, have minimal headers (deliberately), and contain *nothing* but a url. Which points, via redirect naturally, to an incest porn or get-a-huge-penis site, etc.
Spambayes is superb at recognizing spam based solely upon the payload received. If these mails are slipping through, then we need to examine the clues and see why.
I couldn't agree more! Here's one which got a resounding "unsure" (p=0.5130) from my classifier first time through. After slurping that url, it shot up to p=0.9893, exactly where it belongs! -------------------------------------------------------------------- Return-Path: <tkeamou@kerchunk.com> Received: from kerchunk.com ([61.149.21.5]) by www1.kc.aoindustries.com (8.11.6/8.11.6) with SMTP id h2V3DST27976 for <richard@jowsey.com>; Date: 29 Mar 2003 04:44:15 -0400 From: Ella Bunton <tkeamou@kerchunk.com> To: richard@jowsey.com Subject: inside Daughter Message-ID: <20030330002313.YhnvhVSzPGVA@kerchunk.com> Content-type: text/plain; charset="us-ascii" http://leajoulom.lewdmother.com -------------------------------------------------------------------- Cheers, Richard
>> We definitely should NOT crawl the site, just in case it really is an >> innocent url. The load can crush a site, particularly if it's >> hosted. Richard> Nah. You need to throw thousands of requests at a half-decent Richard> web server before it gives up the ghost. And if they're sending Richard> out 10 million mail pieces, they should expect their http Richard> server to take some load. These are definitely NOT innocent Richard> emails. They come from bogus senders, have minimal headers Richard> (deliberately), and contain *nothing* but a url. Which points, Richard> via redirect naturally, to an incest porn or get-a-huge-penis Richard> site, etc. You can't make that judgement beforehand. If the site you are poking is a valid site and the email received was not spam, none of what you said holds. If I remember correctly, you said this was only to be performed in circumstances where certain criteria were met, none of which included a conclusion the mail was spam. Skip
3/31/2003 3:46:36 PM, Skip Montanaro <skip@pobox.com> wrote:
We definitely should NOT crawl the site, just in case it really is an innocent url. The load can crush a site, particularly if it's hosted.
Richard> Nah. You need to throw thousands of requests at a half-decent Richard> web server before it gives up the ghost. And if they're sending Richard> out 10 million mail pieces, they should expect their http Richard> server to take some load. These are definitely NOT innocent Richard> emails. They come from bogus senders, have minimal headers Richard> (deliberately), and contain *nothing* but a url. Which points, Richard> via redirect naturally, to an incest porn or get-a-huge-penis Richard> site, etc.
You can't make that judgement beforehand. If the site you are poking is a valid site and the email received was not spam, none of what you said holds. If I remember correctly, you said this was only to be performed in circumstances where certain criteria were met, none of which included a conclusion the mail was spam.
That's right. We really should try to solve this problem with tokenization.
Skip
c'est moi - TimS http://www.fourstonesExpressions.com http://wecanstopspam.org There are 10 kinds of people in the world: those who understand binary, and those who don't.
That's right. We really should try to solve this problem with tokenization.
You're quite right. My initial response to these spams was ripping up the url, then checking every possible fragment (>= 3 chars) against the database. This proved reasonably effective when there were enough additional spam-words in the message to shift the classifier out of "unsure". However, these new spams appear designed to provide us the absolute minimum number of clues. Additional tokenization logic probably won't help much, but I'd be delighted if we could figure out a better way! Cheers, Richard
"Richard Jowsey" <richard@jowsey.com> writes:
However, these new spams appear designed to provide us the absolute minimum number of clues.
So, as Tim keeps saying <wink>, perhaps the thing to do is turn this on it's head: make constructions that appear to be intended to minimize clue-generation generate tokens. Cheers, M. --
Or can I sweep that can of worms under the rug? Please shove them under the garage. -- Greg Ward and Guido van Rossum mix their metaphors on python-dev
Quoting Skip Montanaro <skip@pobox.com>:
>> We definitely should NOT crawl the site, just in case it really is an >> innocent url. The load can crush a site, particularly if it's >> hosted.
Richard> Nah. You need to throw thousands of requests at a half-decent Richard> web server before it gives up the ghost. And if they're sending Richard> out 10 million mail pieces, they should expect their http Richard> server to take some load. These are definitely NOT innocent Richard> emails. They come from bogus senders, have minimal headers Richard> (deliberately), and contain *nothing* but a url. Which points,
You can't make that judgement beforehand. If the site you are poking is a valid site and the email received was not spam, none of what you said holds. If I remember correctly, you said this was only to be performed in circumstances where certain criteria were met, none of which included a conclusion the mail was spam.
Anyone who includes a URL in a mail message will probably be prepared for some load based on the number of people receiving the message. If I send a message to a client asking him to look at a web site on a staging server, I expect a dozen or so hits, followed by a phone call. If I send a message to my family mailing list, I expect a couple hundred hits (followed by a complaint from my brother that his picture looks ugly (What can I do? 8-) ). If an evil spammer sends a URL to 50 million addresses, it might expect (hope for) a decent slashdot spike. Interpreting the results of the http request opens a new can of worms. All of the tricks we use to mangle addresses (javascript, formmail honeypots, user-agent based web-pages, funky encodings, etc.) can now be used by the spammer against us. hmmm. I think it will take a while for that to become a major problem. In a server-side deployment where the same spam is likely to reach many hosted mailboxes, a specialized proxy server might be able to reduce the perceived response rate and the wasted bandwidth. -- Terrel
currently, does spambayes treat a URL as a single token or is it parsed somehow? it would seem that if URLs were parsed you would be able to train spambayes to detect mail for odious content based on components of the link. take the example: http://check.myspam.com/ad/junk?random=fsldkjflksj it would seem that the most accurate way to evaluate this would be to parse using '/' (starting after 'http://'). that would allow spambayes to evaluate the domain (check.mypam.com) while giving it the ability to differentiate between directories (which may map to users on ISP systems: http://user.aol.com/niceguy vs. http://user.aol.com/spammer). b
[Tim S]
That's right. We really should try to solve this problem with tokenization.
I'm not sure how many tricks we can pull with tokenization - in the sample mail, there simply aren't enough tokens in the message. I see lots of these, and another trick they use is to use simple mis-spellings of words that would otherwise be clues - eg "fatherr and daugter". Like Richard, I assume these are designed to provide minimal clues. The problem seems to simply be the "unsure" nature of these messages. As Richard says, a trivial URL message in ham will *generally* have enough good clues to push it over the edge. It sounds like we are asking for a tweaking of the math and/or configuration options to push unsure messages towards "spam" - ie, a "in the absence of any clues, assume spam" rather than the current "assume unsure". The only problem I see with this is that, by definition, unsure messages do not have enough clues. A distinction seems to be that in one case we have lots of unsure clues, where in this case we have very few unsure clues. I'm not sure we want a token for the length of the message - the number of clues is the issue. [Alex]
Spammers might be simple folk, but serious crackers (not the script kiddies) certainly are not. If there comes to be a widely deployed
As Richard says, this may be a stretch. Such a DOS attack would require sending a crafted spam to each of these addresses known to run such a filter (or a blind spam hoping to hit them). This spam would cause a single hit on the web server. Re-sending the same spam would not re-fetch the URL, as now we have spam clues, and can score the message without the URL fetch (this is assuming we auto train after the first fetch). We would obviously only fetch html text from the server. Could you not do the same thing today, by sending out a HTML email referencing some images from the server you want to attack? Given the number of mail clients out there that will fetch these images (using their mailers default settings), I would expect this to remain a far more effective attack than the one you propose. [Tim S again]
EXCELLENT point, Alex. Case closed.
I'm not sure who you are speaking for here <wink>. But yeah, fetching the URL does seem the wrong long-term approach. I'm very impressed with the creativity of the idea though - I see lots of these spams and did wonder WTF we could do about it. Mark.
Mark Hammond wrote:
Could you not do the same thing today, by sending out a HTML email referencing some images from the server you want to attack? Given the number of mail clients out there that will fetch these images (using their mailers default settings), I would expect this to remain a far more effective attack than the one you propose.
yes, that would DoS the [http] target, but one could DoS the [mail] recipient's system by sending multiple messages linking to a site that is overloaded (or intentionally slow) so that the [blocking] 'slurp' event clogs up the mail processing flow. it's just a matter of whom you wish to annoy. :o) b
3/31/2003 6:24:36 PM, "Mark Hammond" <mhammond@skippinet.com.au> wrote:
[Tim S again]
EXCELLENT point, Alex. Case closed.
I'm not sure who you are speaking for here <wink>. But yeah, fetching the URL does seem the wrong long-term approach. I'm very impressed with the creativity of the idea though - I see lots of these spams and did wonder WTF we could do about it.
Speaking for myself, of course... We currently do not provide a token for the *presence* of a url. I'm not sure if this would have pushed it toward spamminess or not, but it bears researching. c'est moi - TimS http://www.fourstonesExpressions.com http://wecanstopspam.org There are 10 kinds of people in the world: those who understand binary, and those who don't.
[Tim Stone]
Speaking for myself, of course...
We currently do not provide a token for the *presence* of a url.
We already generate one of proto:http proto:https proto:ftp depending on what's approrpriate.
I'm not sure if this would have pushed it toward spamminess or not, but it bears researching.
Look in your database for the spamprob on 'proto:http'. My bet is that it's near neutral; it's reasonable to expect that a "found a URL" token would have the same spamprob.
3/31/2003 6:59:56 PM, Tim Peters <tim.one@comcast.net> wrote:
Look in your database for the spamprob on 'proto:http'. My bet is that it's near neutral; it's reasonable to expect that a "found a URL" token would have the same spamprob.
Ok. I missed that one. Yeah, it's .56 or so. So that idea's a dumb one. ;) So what's your take on the slurping thing, Tim? c'est moi - TimS http://www.fourstonesExpressions.com http://wecanstopspam.org There are 10 kinds of people in the world: those who understand binary, and those who don't.
[Tim Stone]
... So what's your take on the slurping thing, Tim?
It could be valuable, although it seems more at home in a central (shared) server kind of scheme, where the expenses (on all sides) of fetching content can be incurred once for the benefit of many (I'm picturing a shared dict/database mapping a URL to a token sequence -- there's no "ham or spam?" judgment there, just a one-time fetching and pre-digesting of the referenced info). One twist I didn't see mentioned is that spam web sites often get shut down quickly, so failure to resolve a URL would be a useful (& sometimes expensive (in time) to obtain!) clue too. The spambayes system has always scratched its head over (a) very short msgs, and (b) long, chatty, "just folks" spam. Fetching URL content could improve classification of both. The OP's scheme of invoking it only when the score would otherwise be unsure was a neat idea. Integrating blacklist lookups as part of header analysis would be similar (IMO) in many ways. OTOH, I don't exepct 1-URL spam to survive -- there's no motivation to click the link.
Toby Dickenson <tdickenson@devmail.geminidataloggers.co.uk> writes:
On Wednesday 02 April 2003 4:30 am, Tim Peters wrote:
OTOH, I don't exepct 1-URL spam to survive -- there's no motivation to click the link.
Curiosity? There are few clues to the human that it is spam too.
I'd like to think that people wouldn't click on unidentified URLs appearing in unsolicited emails. But if that were true, things like the ILOVEYOU "virus" wouldn't exist. So you're probably right... Paul. -- This signature intentionally left blank
[Tim[
OTOH, I don't exepct 1-URL spam to survive -- there's no motivation to click the link.
[Toby Dickenson]
Curiosity? There are few clues to the human that it is spam too.
I talked about the novelty factor before, and didn't want to repeat it. For 1-URL spam to *survive* means we see lots of them over time. As a 1-shot trick it may be effective, but it gets old very fast, and I can't imagine anyone clicking on a link like http://abcdefgh.lewdmother.com a second time <wink>. BTW, don't click on that -- it's a live URL, and lewdmother.com doesn't care what you (or they) put before the first dot. It's an obnoxious porn site that pops up a sequence of browser windows in full-screen mode. Clicking on just one of those would be enough to stop just about anyone from clicking on a 1-URL msg from a stranger again.
At 19:59 -0500 31/03/2003, in message RE: RE: [Spambayes] Latest spammer trick stymied, Tim Peters wrote:
[Tim Stone]
I'm not sure if this would have pushed it toward spamminess or not, but it bears researching.
Look in your database for the spamprob on 'proto:http'. My bet is that it's near neutral;
Number of spam messages: 470. Number of ham messages: 224. Probability that a message containing this word is spam: 0.643541700966. So, for my kind of mails, it is on the spam side of things ;-) -- Hofstadter's Law : It always takes longer than you expect, even when you take into account Hofstadter's Law.
Look in your database for the spamprob on 'proto:http'. My bet is that it's near neutral
i have been trying to figure out how to query the db for sometime now to get this very info. can someone point me to the FAQ/note/msg/comment/util that allows one to do so? thanks b
>> Look in your database for the spamprob on 'proto:http'. My bet is >> that it's near neutral bill> i have been trying to figure out how to query the db for sometime bill> now to get this very info. can someone point me to the bill> FAQ/note/msg/comment/util that allows one to do so? I doubt there's anything in the faq about it. Here's how to go about printing the raw spam/ham counts for a given token: >>> import shelve >>> db = shelve.open("hammie.db") >>> print db.get("proto:http") (12106, 20272) >>> db.close() The only reason I used db.get("proto:http") instead of db["proto:http"] is that there's no guarantee that any particular token is present in your database. (This was a poor example to demonstrate that.) I can't remember if the first element is the number of times it appears in ham or spam. A little guesswork suggests the first element is nspam: >>> print db.get("viagra") (122, 4) Skip
[Mark Hammond]
... But yeah, fetching the URL does seem the wrong long-term approach.
I'm very impressed with the creativity of the idea though - I see lots of
Hard to say. these
spams and did wonder WTF we could do about it.
I suggest you wait <wink>. I saw a lot of these last week, but a lot less this week so far. As advertising, sending a single URL has got to suck: who would click on it, and why, especially after the novelty wears off? For reasons explained earlier, if this is combined with the minimal-header gimmick, positive tokens generated for the absence of assorted header lines will eventually get high spamprobs too.
We definitely should NOT crawl the site, just in case it really is an >> innocent url. The load can crush a site, particularly if it's >> hosted.
Richard> Nah. You need to throw thousands of requests at a half-decent Richard> web server before it gives up the ghost. And if they're sending Richard> out 10 million mail pieces, they should expect their http Richard> server to take some load. These are definitely NOT innocent Richard> emails. They come from bogus senders, have minimal headers Richard> (deliberately), and contain *nothing* but a url. Which points, Richard> via redirect naturally, to an incest porn or get-a-huge-penis Richard> site, etc.
You can't make that judgement beforehand. If the site you are poking is a valid site and the email received was not spam, none of what you said holds. If I remember correctly, you said this was only to be performed in circumstances where certain criteria were met, none of which included a conclusion the mail was spam.
Skip, I agree absolutely! We certainly can't assume that an email containing only a singleton url is spam. NB: when friends or colleagues send me a single url, as they do, such messages already get a "good" classification. No problem there. But the same kind of message from a spammer ends up as "unsure", primarily because there's simply not enough clues to be definite about its classification. Actually, what prompted this whole question was a "complaint" from one of my proxy beta testers about one of these spams. He reckoned it was "bloody obvious" that the message was junk. The classifier disagreed. I went looking for a simple solution! My *only* criteria for poking the url (rather ironic choice of verb, considering the sites in question ;-) are: 1. an "unsure" classification 2. number of clues < 150 (or whatever max_discriminators one has) 3. a URL in the message body If the url happens to point at an "innocent" site, this extra bit of information-gathering will simply tip the message over to the "good" bucket. A Good Thing, no harm done. And, in this (unusual) case, there's definitely no extra load happening at the web server, precisely because there weren't millions of this email getting blasted out... HTH! Cheers, Richard
Won't this just convince spammers that: 1) Their spam is "working", because "people are clicking on the link",
Won't matter, coz I'm not buying anything, just slurping words. Let 'em count away, haha...
2) If there's a unique ID in the URL, it will confirm that your address is live and that you're a sucker for whatever it is they mailed you. :)
More fools them. They've already got my address, and they'll keep on mindlessly sending out junk no matter what...
Of course, I also suppose it's possible that if enough people install a spam filter that works this way, the resulting "spambayes effect" might crash a few of their servers. :)
Ha! I doubt it. They'll only stop doing this single URL trick when it's not translating into sales. The key point is that these little uglies appear to be specifically designed to get past our kind of filtering, by dint of insufficient clues in the email.
participants (13)
-
Anthony Baxter -
bill parducci -
Francois Granger -
Mark Hammond -
Michael Hudson -
Paul Moore -
Phillip J. Eby -
Richard Jowsey -
Skip Montanaro -
Tim Peters -
Tim Stone - Four Stones Expressions -
Toby Dickenson -
tshumway＠jdiworks.net