Long-lived spam via Yahoo! search

Back in May, I noticed some spam in my Moin Moin wiki, and fixed it.

As this Yahoo! Site Explorer view of taint.org demonstrates, Yahoo!’s search is still showing these results, partly; despite the spam content being long deleted (example ), they still show the spam title and URL, despite the fact that the title and text no longer contains those spam keywords.

Annoyingly, I’m still seeing referrer clickthroughs from search.yahoo.com to these deleted pages from lusers looking for porn, as a result. Come on Yahoo!, fix your search to notice the title change at least, so people don’t think the pages still contain porn!

Tags: , , , , ,

Comments (4)

Moin Moin attachment spam

Here’s a new trick used by the web spammers — attachments on a Moin Moin wiki. The taint.org/wk RecentChanges list illustrates it well:

2007-05-07  set bookmark
[UPDATED]       UserPreferences         04:17   Info    ?StepStep [1-21]        
  #01 Upload of attachment ‘big-cocks.html’.
  #02 Upload of attachment ‘big-cock.html’.
  #03 Upload of attachment ‘big-boobs.html’.
  #04 Upload of attachment ‘big-ass.html’.
  #05 Upload of attachment ‘bdsm.html’.
  #06 Upload of attachment ‘bbw.html’.
  #07 Upload of attachment ‘bang-bros.html’.
  #08 Upload of attachment ‘bangbros.html’.
  #09 Upload of attachment ‘baby.html’.
  #10 Upload of attachment ‘asian-porn.html’.
  #11 Upload of attachment ‘asian-girls.html’.
  #12 Upload of attachment ‘anime-porn.html’.
  #13 Upload of attachment ‘anime-girls.html’.
  #14 Upload of attachment ‘angelina-jolie.html ‘.
  #15 Upload of attachment ‘amature.html’.
  #16 Upload of attachment ‘amatuer.html’.
  #17 Upload of attachment ‘adult-videos.html’.
  #18 Upload of attachment ‘adult-stories.html’ .
  #19 Upload of attachment ‘adult-games.html’.
  #20 Upload of attachment ‘69.html’.
  #21 Upload of attachment ‘3d.html’.

Great. Lots of spam. This first started appearing on Feb 27 2007, in a multi-upload attack on a single page (”FindPage”), from IP address 212.26.129.162; then reoccurred on Apr 27 and May 7 from the (insecure open proxy) proxy.drevlanka.ru.

Annoyingly my “subscribe to wiki changes” patch doesn’t catch this – these aren’t gatewayed through as “changes” via mail for review. I need to fix that in my copious free time. :(

Also, the RecentChanges RSS feed doesn’t list them, although the HTML form does.

So unfortunately, the only way I can see to block this is either to review by visiting the RecentChanges page in a web browser regularly (how retro!), and delete them retrospectively, or simply to turn off attachments entirely – which is what I’ve done, by editing “wikiconfig.py” and adding:

    actions_excluded = ['AttachFile']

It looks like quite a few other wikis around the web are running into the issue too :(

Tags: , , , , , ,

Comments (2)

HOWTO block editing of pages in Moin Moin

A useful Moin Moin anti-spam tip, via Upayavira at the ASF: adding ACLs to pages so that only certain users can edit them. This is an easy way to interfere with the wiki spammers who get past the existing (quite good) Moin Moin anti-spam subsystems. They tend to aim for the common Wiki pages, such as WikiSandBox, RecentChanges, and FrontPage, so if you make those pages uneditable, that’ll cause them more trouble — and hopefully cause them to move on to easier targets, instead of defacing your wiki. Here’s how to do it (at least for Moin Moin >= 1.5.1).

Open a shell on the machine where the Moin Moin software is installed. Edit your “wikiconfig.py” file (in my case this is at /home/moinmoin/moin-1.5.1/share/moin/jmwiki/wikiconfig.py), and change the “acl_rights_before” line to read:

    acl_rights_before = u"JustinMason:read,write,delete,revert,admin"

Replace “JustinMason” with your wiki login name, of course.

Create an administrative group of trusted users. Do this by creating a page called “AdminGroup” containing

#acl All:read
These are the members of this group, who can edit certain restricted pages:
 * JustinMason

Now, for the sensitive pages (like FrontPage etc.), edit each one and add an access-control list line at the top of each page containing:

#acl AdminGroup:read,write All:read

That’s it. Users who are not in the AdminGroup will no longer be able to edit those pages. That should help… at least for a while ;)

Update: you should also use this in wikiconfig.py:

    acl_rights_default = u'Known:read,write,revert All:read'

This blocks non-logged-in users from writing to pages.

Tags: , , , , , ,

Comments