Closed Bug 986832 Opened 11 years ago Closed 11 years ago

Deal with spam/"hacking" attacks on wikimo (2014-03-22)

Categories

(Websites :: wiki.mozilla.org, defect)

Production
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2014-Q2

People

(Reporter: kairo, Unassigned)

References

Details

We had some issues with both conventional spam attacks (once again) and something where people do "defacing" edits on existing pages with "mozilla hacked by xxx" messages in the last days, ongoing today. I just spent 2 hours just blocking users and deleting edits/pages coming from that. Can we temporarily suspend creation of new users or something? Unfortunately, even in this case we'd need to deal with a long list of users without edits that have been created in the last hours, probably by those spambots.
BTW, kudos to XtC4UaLL from the German community for alarming me on the attacks today and helping with undoing some edits.
Here's two random examples of the kind of content: Defacement: http://wiki.mozilla.org/index.php?title=Special:Undelete&target=Directory&timestamp=20140322114854 Spam: http://wiki.mozilla.org/index.php?title=Special:Undelete&target=How+To+Protect+With+Coupons&timestamp=20140316074626 I have seen spam pages going back to the start of March, btw (but ongoing today) - the defacement stuff I only see coming up in the last couple days. I also saw some such spam deletions by clouserw and ckoehler, and AlisonW has previously done a ton of that, so CCing them as well.
I also just e-mailed all of IT for info on state/escalation paths as I know them today for "humans who can help deal" and some known remediations on such. In an attempt to forgo head-scratching as to what-to-do from our end.
Defacement is new. Since I came onboard last June until I stood aside at the end of Feb the amount of pure vandalism (as opposed to spam) was less than ten events. Compared to as many as 1,500 spam pages being created per day. The fastest / easiest way to prevent this (indeed prevent all* spam) is to edit LocalSettings.php in the wiki root to require the "confirm" flag / user right [1] in order to edit or create a page. The 1,912 people[2] who have validly edited the wiki between (roughly) 2012 and February have this flag[3], This does, of course, stop the MozWiki being open to all to edit; it makes no change to the ability of everyone to read it. This is, in essence, the reason it wasn't implemented last August when I started putting the possibility in place by registering 'valid users'; a formal method of requesting an account would be required. As a guideline, except for the period around the Summit last year, most weeks see only around five new users (and most of them are reps, which probably provides the mechanism) ---- [1] See http://wiki.mozilla.org/MozillaWiki:Account_confirmation [2] Some new users have been adding themselves to the list, however they show up immediately on nuke (http://wiki.mozilla.org/Special:Nuke) namespace 'user' as they won't have been created by the WikiSupport account (which all valid confirmations have been) [3] Listed at http://wiki.mozilla.org/Category:VerifiedUser * except, of course, anyone who has previously been 'good' going over to the dark side.
Whups. That second line should, of course, have read "was fewer than ten events." Apologies!
I think ultimately we might want to think about tying the login to wikimo both into Persona and Mozillians, possibly only allowing vouched Mozillians to edit pages - but that would need a few decisions as well as the possibility to even tie MediaWiki into those technologies.
BTW, the user creation log at http://wiki.mozilla.org/Special:Log/newusers (for those who can see it) is quite disconcerting, that spambots continues to create more users than it is posting actual spam messages. That said, the defacing seems to have calmed down for the moment (but I only believe it when it continues to not happen).
We've been using http://github.com/cvan/django-potato-captcha on Marketplace with some success. Basically adds form fields to the submit and removes them in JS. Bots don't do that so we just discard. Otherwise could do simple captcha stuff too - text only, like, "Blue, burrito, man, dinosaur, yellow - how many colors are in that list?" -- I've been seeing those more and more lately and I'd assume they are pretty successful for now
When I was looking at the details of the new 'spam' accounts being created it became reasonably clear that there were people doing it, not 'pure' bots, thus why captcha options have, effectively, failed. Maybe 1 in every 15 fake registrations gets used to create spam within the same day, the others get used at some future date - if at all.
(In reply to Alison Wheeler [:AlisonW] from comment #4) > The fastest / easiest way to prevent this (indeed prevent all* spam) is to > edit LocalSettings.php in the wiki root to require the "confirm" flag / user > right [1] in order to edit or create a page. The 1,912 people[2] who have > validly edited the wiki between (roughly) 2012 and February have this > flag[3], I think we need to do this, if only temporarily while we put better anti-spam procedures in place. I'll file a bug for it.
Depends on: 987187
Well, as I said in comment #6, I wonder if we should actually try to get the wiki integrated with mozillians.org and then only allow vouched Mozillians to edit. I know that sucks to some degree as it creates hurdles for being able to get community involvement in the wiki (I look at the "Firefox Club" stuff coming along all the time), but I think it may be necessary evil in the long run.
OK, the defacement hasn't completely stopped but the rare occasions of it now either only upload a "hack by" image or put messages like that on their own user page - that's really 1337 hacking! The spambot has been active at least since some time in February and we have tons of pages around from it, probably targeted at bumping search engine score for the links on there by looking somewhat like legitimate pages (though almost 100% off-topic on this wiki). As long as new stuff comes in, it's not very motivating to go in and try to eliminate the old ones, though. The bot creates probably around 30-50 pages per day (personal guesstimate), I've been doing about 2-3 sessions per day for the last week or so to keep up with that and kill it all as it comes in. It creates way more users than pages though, so a huge part of http://wiki.mozilla.org/Special:RecentChanges is actually the logs of creating those empty users that it can go back to at a later date and use for adding more pages. (In reply to Alison Wheeler [:AlisonW] from comment #9) > When I was looking at the details of the new 'spam' accounts being created > it became reasonably clear that there were people doing it, not 'pure' bots, > thus why captcha options have, effectively, failed. How do you determine that? The user pages all follow a handful of very simple schemes and often have nonsense in it, names mentioned in the page never match user names, and sometimes they even contain a stray %url placeholder. Of course, I don't see into the actual user registration flow, but the pages look very automated to me. In any case, dealing with this on a daily basis is tedious, we should really do something fast to stop this stuff.
(See also: bug 987187 comment 8 and bug 987187 comment 9.) We can actually set it up so that users in certain groups will get an extra CAPTCHA when editing a page if their edit adds one or more URLs to the page. This could help deter those spammer looking to up their link count. Also, I imagine defacement from protest/h4xx0r groups is a separate issue (which usually involves real people) that we can handle separately at a later date.
I just noticed that newer versions of MediaWiki (1.21 and 1.22) have attempted to improve their anti-spam features. So it might be worth getting off of LTS for that reason. See: * http://www.mediawiki.org/wiki/MediaWiki_1.21 * http://www.mediawiki.org/wiki/MediaWiki_1.22
I'm going to pass this off to the relatively new Wiki Working Group. They've already got things underway for dealing with spam on wikimo, and it'll be better to keep things under one group rather than have us doing something unilaterally while they're doing something else.
Assignee: server-ops-webops → nobody
Component: WebOps: IT-Managed Tools → wiki.mozilla.org
Product: Infrastructure & Operations → Websites
QA Contact: nmaul
The installation of the ConfirmAccount extension in bug 1008487 effectively stopped all spam issues. I think we can consider this handled for now.
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 1008487
No longer depends on: 987187
OS: Linux → All
Hardware: x86_64 → All
Resolution: --- → FIXED
Target Milestone: --- → 2014-Q2
Version: other → Production
You need to log in before you can comment on or make changes to this bug.