ControlTier wiki infested by bot vandals

[Alex-SF]

I was just made aware the ControlTier wiki has been overridden by bots
that have been modifying pages with spam text.
Maybe we can restore the wiki to a point before the bots changes and
possibly increase requirements to register new users.

[Bogdan Iosif]

Is there anyone with access to the wiki hosting server planning to do something against this bot infestation?

I think it would be too difficult to restore to a point when things were ok. Currently, I'm going through the documentation and I'm willing to weed out whatever obvious spam I can find but not if my my efforts are in vain.

I'm not technically knowledgeable of how it can be done but it seems that upgrading Mediawiki to the latest version and installing something like the ConfirmEdit extension would do a lot towards stopping the infestation ( http://www.mediawiki.org/wiki/Manual:Combating_spam#CAPTCHA )

It's a shame for that info to be left to rot like this, even if ControlTier is pretty much frozen when it comes to new developments.

[Bogdan Iosif]

Is anyone willing to do something about the wiki? Something like upgrading MediaWiki and installing this extension: http://www.mediawiki.org/wiki/Manual:Combating_spam#CAPTCHA

I'm currently going through the docs. They seem good enough to be worth saving from rotting and I'm willing to apply corrections wherever I see spam but I need to know that my work is not in vain.

/Bogdan

P.S: I think a global rollback is harder to do than a page by page restore, spread over time, as needed.

[Anthony Shortland]

This page: http://doc36.controltier.org/wiki/Special:RecentChanges ... seems to show exactly where the vandalism is ... seems we could automatically reverse all these changes, secure the Wiki from "bot" update ... and be back in business!

--
You received this message because you are subscribed to the Google Groups "ControlTier" group.
To post to this group, send email to contr...@googlegroups.com
To unsubscribe from this group, send email to controltier...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/controltier?hl=en
http://wiki.controltier.org

[Bogdan Iosif]

There's a huge number of changes made by bots and there's no easy telling how far back they go. If you rollback when it seems that the bots weren't present (~1 year) you risk deleting some changes that are actually good.

Either way, my opinion is that upgrading and enabling that extension should be done first.

[Greg Schueler]

I've added the reCaptcha plugin to the controltier wiki.  hopefully that will at least stop more spam from entering.  Need to go back and remove all the spam accounts and pages, however

[Bogdan Iosif]

Great!

For easier reversion I saw this: http://www.mediawiki.org/wiki/Extension:Nuke

Also, I see here http://www.mediawiki.org/wiki/Manual:Combating_spam#CAPTCHA mentioned that CAPTCHA can be configured to kick in only during user registration and when certain types of edits are made, such as the ones containing external links. This would be very helpful but I don't have a clue how easy it is to configure.

/Bogdan

[Bogdan Iosif]

The spam bots problems are not over but adding reCaptcha had a big positive impact. Thanks!

The user creation log shows a dramatic drop in the # of new accounts created by bots but it also shows the activity hasn't stopped yet. Just for Feb 8th there are already 3 accounts created and the day is not over yet.

http://doc36.controltier.org/mediawiki/index.php?title=Special:Log&limit=500&type=newusers&month=&year=

reCpatcha seems to stop the bots from editing existing pages but the bots manage to login via existing accounts and even create new accounts and edit their user [talk] page.

There are now 1500+ user accounts and 95+% of them are created by SPAM bots. That's too many, I think, to weed out by manual reporting and deletion. Do you think it would be doable to disable all the accounts and re-enable them on demand when someone asks for it via email or a ticket on Sourceforge or something similar like that?

[Moses Lei]

The number of "real" edits is fairly small within the last few months. Can we establish some criteria for what is a "real" edit, save those edits and then roll back to a backup from a few months ago? Not that that would be spam-free either but it would give us a place to start.

Moses

--
Moses Lei
[ Professional Services | DTO Solutions, Inc. ]
[ mobile: +1 703.901.5969 | e-mail: ml...@dtosolutions.com | aim/gtalk: ml...@controltier.com | yahoo: moseslei | windows live (msn): ml...@dtosolutions.com ]

[Bogdan Iosif]

"establish some criteria for what is a "real" edit" ... this doesn't seem feasible to me. I tried to find an extension that could identify, post factum, all edits containing am external link but found nothing. This would've been a very good start in creating a list of bot users.

Bot registration seems to have started very early on (18:19, 3 November 2009 TYROPLO (Talk | contribs) New user account ‎)

If you can find some way to safely rollback all edits / new pages by a single user X from a script, I will send you, as I go through the docs, batches of users I've identified as bots.

/bogdan

[Anthony Shortland]

Yes ... that's what's needed ... rolling back edits by user ... they seem to have a way to do it at Wikipedia: Help:Reverting - Wikipedia, the free encyclopedia  (see 3.1 Bot rollback - http://en.wikipedia.org/wiki/Help:Reverting#Bot_rollback)

Anthony.

Anthony Shortland

[ Developer | ControlTier Open Source Project | mobile: 650.215.3117 aim: anthony....@me.com yahoo: anthony.shortland irc.freenode.net: #controltier skype: anthony.shortland ]

[Bogdan Iosif]

Seems like new user registration from bots is almost under control since the 9th, which is great.

Somehow, the bots still manage to slip through but nothing like it was before.
Do you think they manage to get past captcha by brute force?

20 February 2012
    (User creation log); 08:56 . . AqaqNlegx (Talk | contribs) New user account

17 February 2012
    (User creation log); 17:14 . . KililuVodequ (Talk | contribs) New user account

15 February 2012
    (User creation log); 18:39 . . Siophreak1215 (Talk | contribs) New user account
    (User creation log); 10:48 . . 1HeilPraktiker1 (Talk | contribs) New user account

14 February 2012
    (User creation log); 15:07 . . Hcgus (Talk | contribs) New user account
    (User creation log); 00:00 . . Pelizondo (Talk | contribs) New user account

13 February 2012
    (User creation log); 00:25 . . MinetteShephard226 (Talk | contribs) New user account

12 February 2012
    (User creation log); 00:16 . . NadyaMiles94 (Talk | contribs) New user account

11 February 2012
    (User creation log); 15:57 . . BengeDeleon109 (Talk | contribs) New user account
    (User creation log); 06:16 . . Ella19 (Talk | contribs) New user account

10 February 2012
    (User creation log); 19:48 . . WunderlichNilsen469 (Talk | contribs) New user account
    (User creation log); 12:01 . . GeniaBreeden320 (Talk | contribs) New user account
    (User creation log); 09:58 . . Hdahtesiak (Talk | contribs) New user account

9 February 2012
    (User creation log); 19:21 . . Jpatel (Talk | contribs) New user account
    (User creation log); 19:18 . . Justin.reed (Talk | contribs) New user account
    (User creation log); 16:53 . . BilbreySaldivar315 (Talk | contribs) New user account
    (User creation log); 09:28 . . DeluciaBorchardt69 (Talk | contribs) New user account
    (User creation log); 09:20 . . UpchurchFanelli64 (Talk | contribs) New user account
    (User creation log); 09:11 . . GrassSublett225 (Talk | contribs) New user account
    (User creation log); 08:41 . . ReeFalgoust163 (Talk | contribs) New user account
    (User creation log); 02:47 . . Bowlner1376 (Talk | contribs) New user account
    (User creation log); 02:14 . . MumfordHoran168 (Talk | contribs) New user account

[Anthony Shortland]

Wow that is weird! How do they do that? Human bots? Perhaps we should just lock down user creation completely? Not very wiki-esque, but its not like we're doing many updates.

Anthony.

[Bogdan Iosif]

Maybe they use some exploit for the running version of MediaWiki / captch plugin, or maybe it's just brute force. I don't really know.

The only "standard" thing left to do is to connect the wiki with some IP blacklist maintainer that can automatically reject all input from dynamic lists of IPs known to be used for SPAM. I read a bit about it here: http://www.mediawiki.org/wiki/Manual:Combating_spam#IP_address_blacklists It's not trivial to set up but doesn't look like rocket science either.

Blocking self-registration seems too much as a risk of sending the wrong message to any potential new user.

[Bogdan Iosif]

Greg, Anthony, do you think you can delete directly from MediaWiki's backend database all the users that don't have any pages on their watch-list and haven't made any contributions or have made a single contribution, their user page.

The trick would be to figure out the required SQL queries.

There are just too many user accounts created by SPAM bots to identify and delete them one by one and it seems to me like the above "filters" would yield a large number of rotten accounts.

[Bogdan Iosif]

I started to rollback changes made by SPAM bots and so far it goes smoothly in most cases.

Besides edits on valid wiki pages, the SPAM bots have also added quite a lot of new pages. I can't delete those because I don't have the privilege; nor do I desire it.

Can we work out some kind of procedure I can use to send updated lists of pages to be deleted? I tried renaming pages with a certain prefix, like "2 BE DEL", "TO BE DELETED" or "4 DEL" but this will not work because renaming a page leaves behind the old page with the same name but transformed into a redirect page. So this possibly complicates the work of deleting those rotten pages.

I was thinking that you could add a category "Pages added by SPAM bots" and I could tag the pages to be removed with this category.

Can you think of an easier solution?

[Bogdan Iosif]

In the last ~week I made a large number of rollbacks on all changes made by SPAM bots. With the exception of a few dozen pages, which I plan to go through today, all SPAM edits have been reverted.

I would really like for my work to not be for nothing.

The Recent Changes log shows that today bots were capable of editing pages just like before. Please do something about it.

23 February 2012

• (diff | hist) . . Modeler Guide‎; 07:54 . . (+231) . . Erellon71 (Talk | contribs)
• (User creation log); 07:53 . . Erellon71 (Talk | contribs) New user account

22 February 2012

• (User creation log); 19:37 . . Biacon1029 (Talk | contribs) New user account

[Bogdan Iosif]

I've tagged all uncategorized pages added by SPAM bots with the 'wanted' category: SPAM. See here: http://doc36.controltier.org/wiki/Category:SPAM

All the pages in this category, ~150+, should be deleted

[Bogdan Iosif]

All edits applied by SPAM bots to useful pages in the CT wiki have been cleaned.
All pages added by these bots have been added to the category: SPAM, except for their own user pages.

What is still left to do is to delete all the users created by the bots and their user pages.

[Anthony Shortland]

Nice work, Bogdan. I think Greg, Chuck and Moses have access to do the deletions ... we'll follow up on it.

[Bogdan Iosif]

http://www.mwusers.com/forums/showthread.php?17185-How-to-delete-Spam-amp-Spammers-when-you-have-100-s&s=20825f3c21804a4f48460da4c1a93f39

The above forum page contains a ~recent discussion about SPAM bots & Mediawiki.

There are two alarming statements posted there:

1. reCAPTCHA is known to have been broken and some bots contain the necessary exploits to get around it. There are some alternative CAPTCHA systems that can be used with Mediawiki (one of them seems to be easy enough to setup, FancyCaptcha)

2. Some older versions of Mediawiki are exploitable to perform edits without registering as a user (seems unlikely that this is CT wiki's case)

There's also a quick solution to cut off all the current users so that the bots can't use existing accounts to perform edits. The trouble is that running those queries would also cut off valid users. You could create a support page in the wiki, or something similar, where someone can find information on how they can recover their account.

There's also a solution to cut SPAM by requiring users to login using only OpenID, which seems ok.