reCAPTCHA and MediaWiki under automated attack?
Michael Mol
have recently seen pharmaceutical spam getting through. I don't know
about erights.org, but up to this point I was requiring captcha
challenges for anonymous edits and account creation, but not for edits
by registered bots or users.
At first, rosettacode.org was only getting one spam account per day,
but the number of spam accounts seems to be steadily increasing. I
don't know if they're using human solvers for the captchas or if
they've found some systemic weakness, but it's gotten to be a
problem. I've since dropped the skipcaptcha privilege for registered
users, and we'll see what that does to the spam levels.
Just the same, it's a disturbing trend.
The usernames created by the spammers follow the pattern of [0-9][0-9]
[0-9] buy (drug name).
i-imagine
and seems to work for me.
1) Remove the <noscript> alternative for the reCAPTCHA
2) Use scripting to create your submit buttons
A great example is here: http://recaptcha.net/fastcgi/demo/ajax
Yes, we would all like all users to be able to access our sites but in
my case (photo and art galleries) users need to have JS enabled to
access all of the site's features. In the case of of the biggest
example - I can use Google w/o js in my browser, but Google Maps would
be of my reach.......
My server logs clearly show that "suspicious traffic" (i.e. directly
linking to a reg. page) from "suspicious net blocks" never loads any
of the page's js. When I have looked into reports of "reCAPTCHA
hacked" the sites mostly seemed to have a reCAPTCHA like yours, with a
<noscript> reCAPTCHA.
It seems that there are now services advertising for captcha solving
by humans at pennies per unit. If by using virtual machines and/or
low-cost computers with no extra features the spammers might have a
workable business model .Increasing the degree of difficulty on the
captcha is not practical, but increasing the degree of user/browser
interaction required should increase the cost of computing resources
needed for many humans to solve many captchas. Maybe if the webmaster
can increase this degree of computing difficulty his/her site will
then become a less desirable target.
All of this is based only upon a few months of observation and
learning.
I wish you luck!
Michael Mol
>
> This might not be a popular suggestion, but would be easy to implement
> and seems to work for me.
>
> 1) Remove the <noscript> alternative for the reCAPTCHA
>
> 2) Use scripting to create your submit buttons
>
> A great example is here: http://recaptcha.net/fastcgi/demo/ajax
That's a rather short-term solution. It's not terribly difficult to
automate processing of Javascript on web pages; I know someone who
does it for printing and other purposes.
reCAPTCHA uses a public/private key system, right? If that's the
case, it shouldn't be *possible* for even someone performing a
man-in-the-middle attack to simulate a successful challenge.
The question then becomes, *how* are they able to trick the MediaWiki
reCAPTCHA extension into thinking there was a successful challenge?
>
> Yes, we would all like all users to be able to access our sites but in
> my case (photo and art galleries) users need to have JS enabled to
> access all of the site's features. In the case of of the biggest
> example - I can use Google w/o js in my browser, but Google Maps would
> be of my reach.......
Rosettacode.org primarily has textual content. There's nothing about
the site that makes it unsuitable for the visually impared.
>
> My server logs clearly show that "suspicious traffic" (i.e. directly
> linking to a reg. page) from "suspicious net blocks" never loads any
> of the page's js. When I have looked into reports of "reCAPTCHA
> hacked" the sites mostly seemed to have a reCAPTCHA like yours, with a
> <noscript> reCAPTCHA.
>
> It seems that there are now services advertising for captcha solving
> by humans at pennies per unit. If by using virtual machines and/or
> low-cost computers with no extra features the spammers might have a
> workable business model .Increasing the degree of difficulty on the
> captcha is not practical, but increasing the degree of user/browser
> interaction required should increase the cost of computing resources
> needed for many humans to solve many captchas. Maybe if the webmaster
> can increase this degree of computing difficulty his/her site will
> then become a less desirable target.
The biggest attack I've seen up to this point was where high-demand,
low-reputation sites such as porn and warez ask the user to "prove
they are human" and solve a CAPTCHA from someone else's site. But
that was a front-page article on Slashdot years ago...
>
> All of this is based only upon a few months of observation and
> learning.
>
> I wish you luck!
--
:wq
i-imagine
Odds are that a human being solved the reCAPTCHA. You are right - "man
in the middle" should not work.
A spammer could pay someone to to do their dirty work. The process is
actually advertised on Google.
Shipping an image off to a remote location for captcha solving should
not be too difficult.
From where and by whom is a question you could answer by looking at
your logs.
If you don't want to try changing to the api version then maybe
consider another layer of spam protection such as Askimet.
reCAPTCHA Support
Looking at the logs on your site, it seems the user is trying to create "landing pages" for a spam campaign rather than to advertise to your users. By using a well established domain such as yours, the spammer's messages are less likely to be filtered.
Based on our logs, it seems that the user you are dealing with is manually typing a small number of CAPTCHA solutions. High-quality landing pages are extremely important to spammers, therefore they will often create these pages manually or semi-manually. In fighting spam, one generally needs to use a level of effort propotionate to the spammer -- for bulk spam (eg, millions of emails or spam comments) automated techology does quite well. On the other hand, manually generated spam (sending out a 10-20 spam links a day) requires manual moderation as the manual spammer can easily bypass automated measures.
- Ben
reCAPTCHA: stop spam, read books
http://recaptcha.net
pauli0212
>
> Yes, we would all like all users to be able to access our sites but in
> my case (photo and art galleries) users need to have JS enabled to
> access all of the site's features. In the case of of the biggest
> example - I can use Google w/o js in my browser, but Google Maps would
> be of my reach.......
enabled.
If your site requires JS, your site is broken.
(It is OK to offer enhanced usability with JS, but JS should never be
*required* for any important functionality.)
Requiring users to enable JavaScript is not fighting against spam, it
is fighting *for* spam.
By forcing users to enable JS, you force them to open a security hole
that allows attacker to hijack their computer. Vast majority of spam
these days is sent by bot networks of hijacked computers.
--
Pauli
i-imagine
- yes, asking users to turn on client-side software exposes them to a
greater risk, as does making any connection to the outside world
- yes, users should be able to get some basic navigation and means of
communicating with a website which is what I provide. Visitors are not
"forced" to do anything, they have the freedom to click somewhere
else.
- however, to extend your point about "broken", would you say the same
about the previous example of Google Map?
- today's web is relatively dull and boring w/o js*, most users have
it enabled and a general compromise is to cater to most users although
we would like to be able to please all users
- Although I can't describe with clarity here it seems that server-
side vs client side for content delivery, client interaction, etc. is
settling into what we have today. Going back to a 100% server-side
work load scenario just doesn't seem to be in the cards.
- the original points were about how bots and other malicious looking
traffic never seemed to load scripts
JR Carver
* I do testing/browsing with everything (java, javascript) turned off
in my Seamonkey.