spam on wiki.ubuntu.com
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Invalid
|
Medium
|
Unassigned | ||
Ubuntu Documentation |
Invalid
|
Undecided
|
Dougie Richardson | ||
Ubuntu Website - OBSOLETE |
Invalid
|
Low
|
Matthew Nuzum |
Bug Description
I performed a google search using the string: "site:wiki.
All the links in the Google results are simply links to a single binary to download.
Since I'm not sure if this is just harmless but annoying SPAM or if it indicates something much worse I'm going to mark it as a security vulnerability to be safe.
Dougie Richardson (dougierichardson) wrote : | #1 |
Changed in ubuntu-doc: | |
importance: | Undecided → Critical |
Matthew East (mdke) wrote : | #2 |
Page deleted
Changed in ubuntu-doc: | |
status: | New → Fix Released |
Dougie Richardson (dougierichardson) wrote : | #3 |
Thanks Matthew.
Dougie Richardson (dougierichardson) wrote : | #4 |
Sorry Matthew - it's been put back, this time by user Der74hva3
Dougie Richardson (dougierichardson) wrote : | #5 |
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://
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".
Changed in ubuntu-doc: | |
status: | Fix Released → Confirmed |
Phil Bull (philbull) wrote : | #6 |
I just removed a load of attachments from this page:
Dougie Richardson (dougierichardson) wrote : | #7 |
There's another page here (https:/
Dougie Richardson (dougierichardson) wrote : | #8 |
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.
Dougie Richardson (dougierichardson) wrote : | #9 |
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".
Dougie Richardson (dougierichardson) wrote : | #10 |
Check this Google search (http://
Przemek K. (azrael) wrote : | #11 |
See also Question #26722
Dougie Richardson (dougierichardson) wrote : | #12 |
This one I take it - (https:/
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,
Przemek K. (azrael) wrote : | #13 |
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?
Dougie Richardson (dougierichardson) wrote : RE: [Bug 224971] Re: Google reports many erroneos entries when searching wiki.ubuntu.com | #14 |
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
Przemek K. (azrael) wrote : Re: [Bug 224971] Re: Google reports many erroneos entries when searching wiki.ubuntu.com | #15 |
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[
### www: http://
Matthew East (mdke) wrote : | #16 |
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.
Diogo Matsubara (matsubara) wrote : | #17 |
Since this is about dealing with spam on the wiki, I'm moving the Lauchpad task to the launchpad-
Matthew Revell (matthew.revell) wrote : | #18 |
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.
Changed in launchpad-documentation: | |
assignee: | nobody → rinchen |
importance: | Undecided → Medium |
status: | New → Confirmed |
Joey Stanford (joey) wrote : | #19 |
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://
Matthew East (mdke) wrote : | #20 |
I don't think the move to launchpad-
Joey Stanford (joey) wrote : Re: [Launchpad-doc] [Bug 224971] Re: spam on wiki.ubuntu.com | #21 |
On Fri, May 16, 2008 at 12:07 PM, Matthew East <email address hidden> wrote:
> I don't think the move to launchpad-
> 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?
Dougie Richardson (dougierichardson) wrote : | #22 |
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:/
Sorry if I sound negative, I don't intend to be.
Przemek K. (azrael) wrote : | #23 |
Blocking html attachements on wiki or blacklisting the attachement pages in robots.txt would probably solve this problem.
Dougie Richardson (dougierichardson) wrote : | #24 |
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://
Matthew Nuzum (newz) wrote : | #25 |
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.
Changed in ubuntu-website: | |
assignee: | nobody → newz |
importance: | Undecided → Low |
status: | New → In Progress |
Dougie Richardson (dougierichardson) wrote : RE: [Bug 224971] Re: spam on wiki.ubuntu.com | #26 |
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
Rui Boon (ruiboon) wrote : | #27 |
Hi. Although the user has been deleted, its attachments are still present. (https:/
Przemek K. (azrael) wrote : | #28 |
"?action=
Lam Pak Ting (lampakting) wrote : | #29 |
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?
Brian Burger (bburger) wrote : | #30 |
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:/
https:/
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
Alan Pope 🍺🐧🐱 🦄 (popey) wrote : | #31 |
On Wed, 2008-06-25 at 05:40 +0000, Brian Burger wrote:
> https:/
> https:/
>
> 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.
Dougie Richardson (dougierichardson) wrote : | #32 |
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.
Matthew Paul Thomas (mpt) wrote : | #33 |
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://
Dougie Richardson (dougierichardson) wrote : | #34 |
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://
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.
Przemek K. (azrael) wrote : | #35 |
I've already said that in earlier comment:
The string "?action=
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.
Dougie Richardson (dougierichardson) wrote : | #36 |
@Przemyslaw, cheers - how long would that take to do?
Przemek K. (azrael) wrote : | #37 |
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
Dougie Richardson (dougierichardson) wrote : | #38 |
@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.
Changed in ubuntu-doc: | |
assignee: | nobody → ddrichardson |
importance: | Critical → Undecided |
status: | Confirmed → Invalid |
Joey Stanford (joey) wrote : | #39 |
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.
Changed in launchpad: | |
status: | Confirmed → In Progress |
Matthew Nuzum (newz) wrote : | #40 |
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=
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.
Changed in ubuntu-website: | |
status: | In Progress → Invalid |
Joey Stanford (joey) wrote : | #41 |
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.
Changed in launchpad-foundations: | |
milestone: | none → 2.1.10 |
status: | In Progress → Fix Released |
Przemek K. (azrael) wrote : | #42 |
Bug #59695 had recently an attachement added by user who has the same nick as one of the above mentioned wiki spammers - der74hva3
Jintan (jintan-malwarecrypt) wrote : | #43 |
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?
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
Michael Lustfield (michaellustfield) wrote : | #44 |
I just removed this guys crap.
Would it be possible to get a hold of the ISP this guy is using? https:/
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.
Michael Lustfield (michaellustfield) wrote : | #45 |
I'm switching this back to Confirmed since the issue still exists. We need to rework something to help against spamming as a whole...
Changed in launchpad-foundations: | |
status: | Fix Released → Confirmed |
Jintan (jintan-malwarecrypt) wrote : | #46 |
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
Michael Lustfield (michaellustfield) wrote : | #47 |
I like this thought.
That website has a downloads link which in turn means a downloadable database set.
http://
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://
Joey Stanford (joey) wrote : | #48 |
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.
Changed in launchpad-foundations: | |
assignee: | rinchen → nobody |
Przemek K. (azrael) wrote : | #49 |
Wiki is still getting spammed.
This time it's user https:/
Pages: https:/
Can't you just block adding of attachments by new users? (less than month old)
Przemek K. (azrael) wrote : | #50 |
These are most probably russian spam bots because all new pages that they create contain the russian word "Опишите" ("describe").
Przemek K. (azrael) wrote : | #51 |
https:/
https:/
Another one - empty user page with lots of html attachments.
Przemek K. (azrael) wrote : | #52 |
They're back - same users, same pages.
Dougie Richardson (dougierichardson) wrote : | #53 |
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.
Michael Lustfield (michaellustfield) wrote : | #54 |
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.
Changed in launchpad-foundations: | |
status: | Triaged → Invalid |
Jintan (jintan-malwarecrypt) wrote : | #55 |
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.
Appears to be a spamming account - Fra67ysi is the user name.