spam on wiki.ubuntu.com

Appears to be a spamming account - Fra67ysi is the user name.

Page deleted

Thanks Matthew.

Sorry Matthew - it's been put back, this time by user Der74hva3

Having downloaded the attachment, ripped out the JavaScript and translated from ASCII to text, the JavaScript is loading another JavaScript which is a redirector.

This appears to be a 302 page exploit (explained rather well here http://clsc.net/research/google-302-page-hijack.htm

The posited solution is: "If you discover that you are listed as having hijacked a page in Google, make the script in question return a 404 error and then request removal of the script URL from Google's index".

I just removed a load of attachments from this page:

https://wiki.ubuntu.com/Fra67ysi

There's another page here (https://wiki.ubuntu.com/Gera76ru), edited by the same user name (Der74hva3). I've not deleted the attachments yet - can we leave them while I check them out.

I've deleted them now, they are again re-directors to malware hosts. They are mostly quite outdated and picked up by Firefox but some of them are drive by attacks. This is not a major threat to Ubuntu boxes but it is to anyone redirected searching from a Windows box with un-patched IE and given the search terms it is a possibility (I can imagine that searching for to find if Ubuntu supports iPhones is not an unusual search).

They are again re-directors and this is definitely a 302 Page Exploit. Try searching for some other terms. In the case of "mp3" for example, the restricted formats wiki page is page ranked higher, but the exploit pages are page ranked two onwards.

The user name der74hva3 that is reinstating the pages is in launchpad and their contribution consists of an email address and has five bug reports all consisting of one word - "real".

Check this Google search (http://www.google.co.uk/search?hl=en&client=firefox-a&rls=com.ubuntu%3Aen-GB%3Aunofficial&hs=msH&q=der74hva3%40yahoo.com&btnG=Search&meta=). This address is spamming Linux boards all over the place across many distributions.

See also Question #26722

This one I take it - (https://answers.launchpad.net/launchpad/+question/26722).

Until someone maintaining the server contacts Google, this will continue, the attack is explained in detail above. 302 exploits haven't really been solved as yet.

I don't remember when I registered - have we a captcha system? I know that captcha (Google's) has been cracked but this would improve the situation in the interim.

Cheers,

The bots, their pages and attachements have been deleted. But I'm sure they will be back.
Something should be done in launchpad about it.
I can suggest the following options:
1) put a captcha into launchpad account registration form
2) restrict wiki attachements to non-html ones
3) restrict amount of attachments that can be added by one user at a given time
Any other suggestions?

Hi,

> I can suggest the following options:
> 1) put a captcha into launchpad account registration form

Definitely a start, should prevent most bot registrations. It isn't perfect but it will reduce all but the most persistent.

> 2) restrict wiki attachements to non-html ones

I don't understand why anything other than images is allowed, there is still the vulnerabilities with GIF/JPG of course. There is also the problem of identifying the files being uploaded - extension is not enough as it can be renamed.

> 3) restrict amount of attachments that can be added by one user at a
> given time

Possibly - is there any way to search for the largest number of (legitimate) attachments and propose that should more than a certain number be needed on a page then the page need to be approved by a wiki editor.

> Any other suggestions?

I have got one, which is fairly fool proof unfortunately very time consuming - introduce a method of approving all new pages from new usernames for a certain period of time. At the lowest level, we could restrict wiki edits to 24 hours after first registration or go the whole distance and say, disallow un-approved pages until contributing for a certain length of time.

Unfortunately the advantage of a wiki is that anyone can edit it, which is negated by such a draconian approach. I do think it is reasonable to have new pages by new users approved though.

£0.05 FWIW

Cheers,

Dougie

Dougie Richardson pisze:

>> 2) restrict wiki attachements to non-html ones
>
> I don't understand why anything other than images is allowed,

Archives are often uploaded to wiki - themes, mockups, documents, pdfs, etc.

> there is
> still the vulnerabilities with GIF/JPG of course. There is also the
> problem of identifying the files being uploaded - extension is not
> enough as it can be renamed.

Just check the mime type.

>> Any other suggestions?
>
> I have got one, which is fairly fool proof unfortunately very time
> consuming - introduce a method of approving all new pages from new
> usernames for a certain period of time. At the lowest level, we could
> restrict wiki edits to 24 hours after first registration or go the whole
> distance and say, disallow un-approved pages until contributing for a
> certain length of time.

Yeah, disallowing of creating new pages or uploading attachements for
ie. 1 day after registration would be good.
--
## Przemysław Kulczycki <<>> Azrael Nightwalker ##
# jabber: azrael[na]jabster.pl | tlen: azrael29a #
### www: http://reksio.ftj.agh.edu.pl/~azrael/ ###

I suspect that this problem won't arise when our wiki software is updated - future versions of Moin should have a much more robust anti-spam system.

Since this is about dealing with spam on the wiki, I'm moving the Lauchpad task to the launchpad-documentation project. For Launchpad related spam, please see bug 45419, which covers a general mechanism to deal with spam in Launchpad.

We don't suffer from this problem on the Launchpad Help wiki right now but it's certainly possible.

We currently use ACLs to prevent write access on sensitive pages or those where we've experienced vandalism. However, if upgrading MoinMoin is a route to better spam protection, then that will help us avoid future spam problems.

Assigning to Joey for Launchpad as he's looking into the potential for upgrading the moinmoin version of the LP help wiki.

In addition to the OpenID advantages which will cut down on spam, it's also possible to enable features in Moin to prevent spam.

See http://moinmo.in/CategorySpam for some ideas.

I don't think the move to launchpad-documentation project was appropriate. The bug raises issues about how the Launchpad user registration system can help improve these problems. I'll move it back to the launchpad project.

On Fri, May 16, 2008 at 12:07 PM, Matthew East <email address hidden> wrote:
> I don't think the move to launchpad-documentation project was
> appropriate. The bug raises issues about how the Launchpad user
> registration system can help improve these problems. I'll move it back
> to the launchpad project.

I see this as a multi-part problem under the heading of Spam Prevention.

1) How do we prevent spam in the wikis?
   * openid
   * moin anti-spam items
   * Use of acl locks to prevent defacing or intentional malicious
activity (this happened on help.lp.net which is why we have these
there today)

2) How do we prevent spam in LP?
 * Capture page when you contribute to anything public except when
some extra identity condition is met (e.g. What facebook does - mobile
phone verification since there is a monetary factor involved there)

3) Deleting / Hiding spam in LP
 * add mechanism to flag, hide, and potentially remove spam

4) Identification of spam and spammers
 * flag post as spam which raises a spam count on a user in LP which
in tern flags the account for review by a LP admin
 * How do we check this on large wiki's like Ubuntu's?

With respect, all these points are totally valid but will _not_ alter this bug. Anyone searching Google for Ubuntu Wiki articles will hit the spammed articles. This issue makes use of a vulnerability in how Google handles 302 errors, not Moin or any server side software we run.

> 3) Deleting / Hiding spam in LP
> * add mechanism to flag, hide, and potentially remove spam

Hiding spam? In this case that will only improve the situation for the bots in question because it will reduce visibility for users navigating the site but still allow direct linking from Google - where the search is launched from.

> 4) Identification of spam and spammers
> * flag post as spam which raises a spam count on a user in LP which
> in tern flags the account for review by a LP admin
> * How do we check this on large wiki's like Ubuntu's?

As for flagging spammers a clearly publicised mechanism for reporting is essential - I raised the question of this particular account as a question (https://answers.launchpad.net/launchpad/+question/31868) over two weeks ago and there is as yet no response. This may simply be that I asked the wrong team but that is the problem when it comes to the project as a whole, it is not always clear who does what.

Sorry if I sound negative, I don't intend to be.

Blocking html attachements on wiki or blacklisting the attachement pages in robots.txt would probably solve this problem.

Have we seen any progress on this issue? I ran the original search term again, despite the removal of the orginal offending account, there is still (malicious) spam on the top results.

Robots.txt is unlikely to solve this issue, perhaps future page locations but not current ones - I refer to http://clsc.net/research/google-302-page-hijack.htm again.

Currently in progress is the upgrade to a newer version of moin. (This is in testing now) Moin 1.6 and newer have excellent spam prevention and spam management features and should limit the scope of this problem.

Hi,

> Currently in progress is the upgrade to a newer version of moin. (This
> is in testing now) Moin 1.6 and newer have excellent spam prevention
> and
> spam management features and should limit the scope of this problem.

It will limit the scope in so far as detection of new pages being raised as spam but is it capable of dealing with the page rank issue?

Cheers,

Dougie

Hi. Although the user has been deleted, its attachments are still present. (https://wiki.ubuntu.com/Fra67ysi?action=AttachFile) These html files are filled with keywords that are picked up by the search engine bots. They contains obstructed javascript that redirect users to another site. Should these attachment be deleted as well? Thanks

"?action=AttachFile" should be blacklisted in robots.txt - then Google bot won't download these attachments and won't push up the pagerank of the spammer's sites.

Could we have a mechanism that the Documentation Team is informed whenever a new wiki page is created, so that the team can have a quick review on that page?

On Tue, Jun 24, 2008 at 8:41 PM, Lam Pak Ting <email address hidden> wrote:
> Could we have a mechanism that the Documentation Team is informed
> whenever a new wiki page is created, so that the team can have a quick
> review on that page?

https://help.ubuntu.com/community/RecentChanges
https://wiki.ubuntu.com/RecentChanges

There's an RSS feed for both pages, although I have to confess I can't
remember how to get to it - it's not as obvious as it should be.

You can also just subscribe to RecentChanges and get emails everytime
it updates... that would be a lot of emails...

Brian

On Wed, 2008-06-25 at 05:40 +0000, Brian Burger wrote:
> https://help.ubuntu.com/community/RecentChanges
> https://wiki.ubuntu.com/RecentChanges
>
> There's an RSS feed for both pages, although I have to confess I can't
> remember how to get to it - it's not as obvious as it should be.
>

Add ?action=rss_rc to the end of those urls.

> You can also just subscribe to RecentChanges and get emails everytime
> it updates... that would be a lot of emails...

Not it isn't. I am subscribed and I get none, because that page itself
doesn't change.

Quick question to Matthew Nuzum, has anyone from the site team spoken with Google? Their cache is still supplying the spam files with our name on the search results.

That's because ... the files are still on our Web site. I don't see why anyone would need to contact Google -- they already provide copious instructions on how to remove items from their index <http://www.google.com/support/webmasters/bin/answer.py?answer=35301>. The easiest method, of course, is not to have the resources on your Web site in the first place.

Hi MPT,

This came by way of a bot, both usernames (der74hva3 and Fra67ysi) are still active in Launchpad. Their strategy is straight forward, register, enter a comment on a few posts (which is always one word - "real") use their Wiki page then upload malware in the form of obfuscated JavaScript to be found by searching Google and being picked up by this 302 exploit (http://clsc.net/research/google-302-page-hijack.htm) to displace genuine search terms to the malware uploaded to wiki pages.

The reason for consulting Google is to address the displacement of genuine search results by malware results - the suggested course of action for dealing with 302 exploits.

Its listed as a low priority by the website team, yet we still have malware being distributed in connection with our name, after much pontification (since the first of may) we still cannot close this bug because it is _still_ true.

I don't want to offend any one and certainly mean not to be rude but this needs to be addressed, the fact remains that even if we nailed every one of these files we would still have a page ranking problem linking to missing files!

First, we could look at the type of username registered in Launchpad - they are always in the same format of three letters, three numbers, three letters, sometime with an extra number (they're all over Linux boards on the net). Second, could be search the site for one word posts, consisting of the word "real" - I've noticed this is the only word ever used (its on Linux Questions too). Lastly, we should consider either moderation of new members for wiki access (which is probably counter productive) or introducing a delay between registration and uploading files to the wiki is allowed.

I've already said that in earlier comment:
The string "?action=AttachFile" should be blacklisted in robots.txt - then Google bot won't download these attachments and won't push up the pagerank of the spammers' sites.
This is an easy and 100% sure fix.
This will remove all wiki page attachements from google though.
It will solve this issue because Google bot will refresh it's cache after a few days, and then these spam pages will get a lower rank.

@Przemyslaw, cheers - how long would that take to do?

Well, it could be done in a couple of seconds. It's just a matter of configuration of the webserver on wiki.ubuntu.com
You should probably ask about it on launchpad-users or ubuntu-website mailing lists, or on rt.ubuntu.com

@Przemyslaw, cheers but I'm not going to that level of hassle! Surely given the website team are subscribed to this bug then this is in their domain!

My interest in this was purely as it was filed as a documentation team bug, to which end I intend to set it to invalid because it isn't really our issue. This bug is subscribed to two other teams that can deal with the issue more effectively than the doc-team can.

We're (not Launchpad but Canonical) in the process of upgrading wiki.ubuntu.com. Once that's upgraded the new moin spam "engine" will kick in as will openid so it should significantly cut down on spam. At that point I'm going to close out my task. Unsure what to make of the Ubuntu Website task though. I've pinged Matt N about it.

Last I've checked (about 3 min ago) you could not use regex to match in robots.txt (please show me documentation to prove I'm wrong on this). I've asked around and our version of Moin doesn't provide much to prevent this either.

The only thing I can even begin to suggest is to use a RewriteCond to check %{QUERY_STRING} for action=AttachFile.*(htm|html|js)$ and do a redirect to some help page explaining the types of attachments allowed.

That regex is rough and would need to be rewritten to handle the re-ordering of params but should work for most cases since it matches the ordering that moin uses by default.

I will point this out to the proper people who can configure the apache server to see if they're willing to enable it.

I'm marking this is as fixed released from the Launchpad point of view because the Ubuntu wiki was updated with OpenID and moin 1.6.3. If this ends up being a problem (i.e. new spam is created after this date) then we can trace it to a particular user and can open up a question on Launchpad to point out that a user is spamming.

Bug #59695 had recently an attachement added by user who has the same nick as one of the above mentioned wiki spammers - der74hva3

I am not familiar with the procedures here, but as I followed the term " der74hva3" to this ubuntu site I see this ongoing dialog on the subect. Spambots are posting in other forums the redirected porn/malware links still from the "der74hva3" folder here, using the Get functions in the Attachments folder:

Der74hva3?action=AttachFile&do=get&target=131

I emailed the webmaster, but will post this as well to bring attention to the need to remove that "Der74hva3" folder, as well as the "Get" attachments.

If posting this information here is incorrect for the purpose of this page my apologies in advance.

Jintan - malwarecrypt.com

I just removed this guys crap.

Would it be possible to get a hold of the ISP this guy is using? https://launchpad.net/~enri75ac6 We could perhaps have him banned from his ISP which could at minimum give him a little slap in the wrist saying we're sick of it?

I'm getting in touch with the launchpad guys to see if we can have his account removed. That would at least stop the pages from being recreated under that account and would help stop google search results.

I'm switching this back to Confirmed since the issue still exists. We need to rework something to help against spamming as a whole...

Good you have corrected the issue. Methods like IP blocking or contacting ISP's are not likely to help. IP's change extremely rapidly using many different techniques, and the Host vendors are also usually already seven levels deep and unreachable, through other quasi-legal business practices. Email banning is also fruitless. Increased restrictions on levels of access, and human review and intervention (like you have done) seem to be the most efficient methods. If possible, have a human review each new registration and web search the email name and IP address. Most often the email name/address, in some form, has been already associated with spamming and the IP's will show on websites like stopforumspam.com. It is how I located the problem here. Jintan

I like this thought.

That website has a downloads link which in turn means a downloadable database set.
http://www.stopforumspam.com/downloads/

Perhaps this could be used in the registration process. If a users IP, Email, Domain, or User Name are found in that list, then we can offer them a link of appeal in which their registration information will be sent to an administrator that can choose to either approve or deny the user and contact them to get a little more information from them.

An approved application could be logged somewhere (wiki) with an explanation of why. I imagine this would look like a table with a date, admin, user, reason blocked, and a link to the email conversation (uploaded). A denied application could follow the same process.

If this were ever implemented, it would need to take a modular verification approach. This way we can choose to stop blocking based on IP if it proves to be a problem.

It would also be nice if we could file reports when removing an account. If an admin bans/removes the account for spam it could forward the information we have to that site. http://www.stopforumspam.com/add

I'm unassigning this from myself as it is a Foundations team item. I believe the current issue is now is how to have better authentication mechanisms and spam handled inside Launchpad. I think we already have a bug for that.

Wiki is still getting spammed.
This time it's user https://edge.launchpad.net/~dway72aa2
Pages: https://wiki.ubuntu.com/Home https://wiki.ubuntu.com/air
Can't you just block adding of attachments by new users? (less than month old)

These are most probably russian spam bots because all new pages that they create contain the russian word "Опишите" ("describe").

https://wiki.ubuntu.com/gr76gtee7
https://edge.launchpad.net/~gr76gtee7
Another one - empty user page with lots of html attachments.

They're back - same users, same pages.

They're going to keep coming back too. I've been saying this since the outset - it is a bot that is doing it. Look at the comments posted by these "users" one word, which makes little sense in most contexts. As I suggested previously, either a delay between registration and posting being attachments being allowed or a restriction on registering with Launchpad using an ID in the format used by the bot might be worth considering.

I just wanted to point out that I performed the same search and found that the results were very concise. There are more step to go and there always will be. I'm just curious if this bug is in a state to be closed.

Apparently I am still subscribed to this thread, so got the email notification on the last comment. Since I analyze malware I wanted to follow the links mentioned, but all the Google hits I received were to legitimate Ubuntu Wiki pages. I suspect the links to binary downloads are instead due to the computer being infected with one of the redirect malwares being spread lately. With zero intent on spamming the site, you may want to consider reviewing this computer at MalwareCrypt, or any of the reputable malware removal help sites.