Slashdot Mirror
Spammers Targeting Microsoft's Revised CAPTCHA
toomuchtoomuchspam writes "According to Websense, Microsoft's CAPTCHA has been busted again. CAPTCHA was surely a logical move for different service providers to fight against spammers, but it seems to be melting down. 'Realizing the potential for massive abuse from spammers with anti-CAPTCHA capabilities, who could use the clean IP reputation to carry out various attacks over Email and Web space, Microsoft attempted to increase the complexity of their CAPTCHA system. The CAPTCHA system was revised in an attempt to both prevent automatic registrations from computer programs or automated bots, and preserve CAPTCHA's usability and reliability. As this attack shows, those efforts have failed,' says Websense security researcher Prasad. Could there be any better CAPTCHA? A better solution?"
Better yet, how about a combination of image recognition and random questions?
E.g. you're shown a randomly-generated picture with a duck, a chicken, a skunk, and a dog, and background noise. You're asked to click the duck. If you correctly click in the general area of the duck, you're verified.
Probably not the best example, since you'd have a reasonable success rate just for guessing, but it seems like a solid concept.
I had played with this idea a bit a few months back and came up with an idea I think could work - but only ever got around to coding the most basic example of it. For those on /. who are interested, find it here. Each reload will produce the image of a new challenge.
In a closer to final version I had envisioned instructions in multiple fonts and colors involving shapes, letters, etc., and much more flexibility.
In the example I've shown above, pure random clicking will produce a correct response to the challenge 1 time in 30 approximately. So - make them solve three in a row and there you are - 1 chance in 27,000.
How about something interactive?
Use some javascript/css/etc to make a box where depending on the position of you mouse in the box, little images/icons/whatever move around in the box till they overlap and create a bigger picture, then send the mouse position (x,y) to an AJAX server and have it validated.
This won't be a be all and end all to spam, but maybe for new accounts that are freshly created, have an escalating delay for each message sent out? This would go away after some certain rules are matched (date of account creation.)
One can add and subtract modifiers. For example, multiple E-mails sent out to many recipients will have a longer delay than messages sent to the same person, a longer delay if the outgoing content is flagged spam through a heuristic filter, etc.
This in no means would stop spam, but a delay of 10-15 seconds won't affect users much, but will definitely put a crimp on spammers.
> I agree all these things are difficult. So what solution do you suggest?
I personally applied a multi-pronged approach, and my spam problem has been negligible for YEARS.
1) Everyone I give my email address to is given a different alias, in the form 'myname-alias.validation@mydomain.com'. 'validation' is basically the hash of the salted alias, with different salting recipes for different pattern-matches just to make life difficult for spammers. In theory I could generate the aliases by hand, but I wrote a program that runs on my HTC Touch to generate them for me as necessary. Anything sent to 'myname@mydomain.com' automatically bounces with message to go to my website and obtain an alias to use for contacting me. Ditto, for the first message addressed to a given 'alias' whose 'validation' is invalid (thereafter they're unceremoniously sent to /dev/null).
2) I wrote an app to generate time-limited aliases in the form 'myname-yyyymmdd.validation@mydomain.com', but for now it ended up being gross overkill since nobody has ever tried reverse-engineering it so I just automatically accept all incoming mail sent to 'myname-yyyymmdd@mydomain.net' (where 'yyyymmdd' is today's date, or at least a date within the past week or so). But if spammers ever caught on, the generator app goes back up, and the rules get tightened.
Aside from the fact that some people and businesses get seriously weirded out when they're told to email you at 'myusername-theircompanyname.longhexstring@mydomain.org', it works BRILLIANTLY. How brilliantly? On a typical day, procmail chucks, bounces, or otherwise blackholes about 18,000 to 25,000 spam emails addressed to an outright nonexistent address, roughly 8,000-12,000 spams addressed to an alias that fell into spammer hands, and maybe a half-dozen that are in the right form, but have an invalid hashcode (they get sent to another account on the server that I check occasionally). Every few days, I have to spend a couple of minutes adding another blackhole rule to .procmailrc, but I've never really had enough to make it worth my time to actually write an administration program to manage it for me.
Would this work for Joe Sixpack or Sally Soccermom? Of course not. They have a hard enough time keeping one email address at aol.com straight, let alone generating salty-checksum-validated adhoc aliases unique to everyone who emails them (and every website that extorts their email address, etc). But for the world's Slashdot Elite, it's a nice, elegant solution (as long as you've got your own domain name or ten and have either a dedicated server or a hosting account somewhere with shell and script access so you can run Procmail. My email has gone from "worthless due to the avalanche of spam" to "for all intents and purposes, spam-free", and has stayed that way for almost six years now.
Oh, I forgot to mention... the fundamental reason why everyone who emails me is given a unique generated alias is to protect myself against trojans/worms/malware that might harvest the contents of a trusted friend's addressbook. If it happens (like to my dad 3 times already. Sigh. He's actually the reason I came up with this scheme... he kept getting my addresses harvested and ruining them forever), all I have to do is nuke that one specific alias, and tell that one person to use a different address to reach me at going forward. It's a lot easier to nuke an incoming address used by ONE person, and notify that ONE person if something changes, than it is to notify everyone (including banks, websites, etc) that they need to use a new address to reach you.
requiring a physical ID for internet accounts is a bad idea.
i like the reCAPTCHA approach. if spammers want to abuse a reCAPTCHA system, at least they'll be making a positive contribution to society by helping to digitize printed literature. maybe Project Gutenberg or the Google Books Library Project can launch a reCAPTCHA service to put those botnets to good use. if you can't stop them, at least this helps to recover some utility from the problem.
there's also the issue of CAPTCHA porn and the related phenomena of outsourcing CAPTCHA solutions. as long as there are people willing to solve CAPTCHAs for porn, or money to feed their families, then no reverse turing test will ever be foolproof. so the best thing to do is to exploit this CAPTCHA-solving machinery.
why not make CAPTCHAs educational? instead of random words or random excerpts from books, make them arithmetic word problems, geometry proofs, SAT analogy questions, stoichiometry equations, spelling quizzes, etc. this way, the CAPTCHA solvers gain an education from their labors instead of just some cheap porn or a couple of bucks a day. and after solving CAPTCHAs for a few years, they'll be educated enough to land a real job and/or afford to pay for better porn.
this way you turn the spam problem into a way of educating horny teenagers and underprivileged poor in 3rd world countries.
Well,the problem as I see it with the whole CAPTCHA thing is this: even if they manage to find a version of it that is so good that no bot can ever be built that can break it(considering how good some of these bots writers are that is doubtful) then the spammer can either use social engineering or good old cheap labor in countries where you can pay them pennies.
Of course they wouldn't even have to hire anyone with social engineering,just fill an old server with a bunch of porntube style clips(and get extra cash from link sharing) and have them prove they aren't a bot with a little cross side scripting. Then you have plenty of guys happy to do the work for you in exchange for a chance at getting some free pr0n. For extra efficiency you could have their answer "fail" the first couple of times so each user has to give you the answer to three or four CAPTCHAS for each entrance. If they don't want to go to thr trouble then they simply hire day laborers in third world countries and pay them a few pennies per CAPTCHA. I am sure there are still quite a few countries were the cost/benefit ratio of doing so would come out in the spammers favor.
So as long as the spammers can make money off of hErb@l V!@gra and other crappy spam schemes then they WILL find a way around it. Because as long as there are fools willing to part with their money there will be someone with no scruples who will be more than happy to take it from them. So I think in the long run it will be better if the effort was concentrated more on fighting botnets and getting rid of crappy domain registrars than making more and more difficult CAPTCHAS. Because it is getting to the point that some of them are so horribly screwed up that I as a human can't figure the damned things out.
ACs don't waste your time replying, your posts are never seen by me.
That's a good start, but I'm not convinced that simple automation is dead here. This doesn't seem that difficult to me. I've put up live forms that have invalidated 100% of bot submissions, even without CAPTCHA. Granted, impressions are only in the tens of thousands, but still, *combined* with CAPTCHA, a few simple principles ought to suffice, even against concerted, distributed attacks:
0) Obviously, limit submission attempts per session to a humanly achievable rate. Sticky session IDs can be packed into hidden form fields, query strings, cookies, etc.
1) Anything that's worth guarding with a CAPTCHA should require a modern browser (CSS, cookies, javascript, DHTML). In my experience, over half of attempts can be weeded out by using a segregated approach with cookies: user submits -> set some server-encrypted cookie value -> modify value in client-side js -> repost in client-side js -> inspect during next http post.
2) You can still provide accessibility accommodations; just make sure *all* form submissions have frequency limitations that increase in severity with every failed attempt in a single session. What you can't do in cookies or js can still be done in hidden form fields and query string params. For a surprising majority of submissions (i.e. modern browsers or bots trying to imitate them), the simple requirement of a compliant js VM to modify form/cookie/querystring variables before submitting rules out bots right away.
3) For the modern browser version of the form, add numerous honeypot fields; use modern browser techniques to hide them by overlaying them. Making the overlaying element distant from the real one in the DOM tree, and/or add the real element (or all of them, or half of them, or a random assortment) using DHTML.
4) Randomize the IDs & DOM location of both real and honeypot inputs (store a distinguishing hash code or the like in a hidden form field, cookie, or on the query string).
5) Include hidden honeypot CAPTCHA images as well. Observe step 4 here. Also, use large images containing multiple CAPTCHA phrases, and use CSS to crop the image.
6) Vary the obfuscation techniques used in CAPTCHAs, e.g., sometimes fuzzy match on "name the object in the picture" (duck, DUCK, Duck, goose, swan, bird ok, everything else fails), or sometimes use animated gifs and display the challenge progressively instead of in a single frame, or sometimes ask the question in the image and put the answer right there with it! (Cheesy, but that one alone takes most current bots out of the running.)
7) Values in hidden honeypot fields are almost certainly from bots. Ditto for correctly decoded honeypot CAPTCHAs. Log this fact, and record it in a required cookie or hidden form field.
Yes, this is security by obscurity, and it's technically far from foolproof. Still, I would venture that a combination of techniques like this would bring the vast majority of bots' success rates well below the usability threshold. It's not hard to add complexity to a system like this, either. Nor is it hard to accumulate increasingly useful clues as to whether a submission is likely to be human or not.
I need to shut up now; this simple rant is more than enough for a software patent nowadays. Speaking of which, if anyone wants to codify this "method and system of Turing challenge obfuscation," I hereby release the above description under the licensee's choice of either the BSD license, or the "do what the fuck you want" license. Cheers.
Pi Ran Out