HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

How to block this spambot?

2»

Comments

  • peregrineperegrine MVP
    edited November 2014

    also what plugins, theme, and applications are you using, perhaps they are introducing a hole ???

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • They were probably posting directly.

    grep is your friend.

  • beschizzabeschizza New
    edited November 2014
    you might take a look at your apache (if that is your server) logs and see what that ip address is actually doing with regard to posts, editing , etc.
    

    Aha! I found some suspicious activity corresponding with the edits. There seems to be a cycle of access for each suspicious IP: every half an hour it hits editdiscussion, then tries to sign in, and then seems to do some browsing.

    e.g.

    I've attached some example logs for suspicious IPs -- all have the same pattern, I think!

    The one 188.143.232.123 seems to be most interesting as it also POSTS, and doesn't do any superficial browsing

  • beschizzabeschizza New
    edited November 2014

    I'm running a cosmetically customized version of the DRresponsive theme at http://vanillaforums.org/addon/dresponsive-theme

    Plugins enabled are:

    All Viewed

    Button Bar

    DefaultAvatar

    Emotify :)

    Flagging

    ImageUpload

    LatestPostList

    Quote selection

    Registration Restrict Logger

    Sign Logger

    Split / Merge

    Stop Forum Spam

    Vanilla Statistics

  • you might want to see if the problem continues, and take note of discussion id or comment id that is changed by the miscreants and compare against the apache log the ip address from the change log and try to match the times, so you can drill down to what they are doing and see if you can create the same issue based on what they are doing.

    meanwhile you could add to:

    http://vanillaforums.org/discussion/26703/plugins-themes-that-work-and-dont-work-in-vanilla-2-1/p1
    spreadsheet

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • where is the site?

    grep is your friend.

  • No bother I found it

    grep is your friend.

  • beschizzabeschizza New
    edited December 2014

    Update: The advice here helped enormously and I think I've closed the vulnerability. Thanks again for the help, @x00 and @peregrine !

    Due to the database import (from the weird old proprietary forums), many threads had an InsertUserID of 0.

    These threads' OPs (author "Unknown") could be edited simply by accessing /vanilla/post/editdiscussion/n where n is the DiscussionID. The client would get the edit thread form,even if they weren't logged in, and could make edits to those thread-starting posts.

    Changing the InsertUserID to a legit user (I gave them to the System account) seems to have fixed it. These threads can no longer be edited by anyone -- the user must log in and have an appropriate role.

    UPDATE GDN_Discussion SET InsertUserID = 2 WHERE InsertUserID = 0;

    (However, logged out users can still get an edit form if they go to a DiscussionID that doesn't exist. I don't know if this is normal Vanilla behavior. It doesn't let them create a discussion or do anything, but it does yield an error message that reveals column names if they try and post.)

  • peregrineperegrine MVP
    edited December 2014

    (However, logged out users can still get an edit form if they go to a DiscussionID that doesn't exist. I don't know if this is normal Vanilla behavior. It doesn't let them create a discussion or do anything, but it does yield an error message that reveals column names if they try and post.)

    my guess:

    yes its normal I believe in vanilla 2.1 , I think its a bug. it probably shouldn't display a form.

    I think it is fixed in master.

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • Great help here. I woke up this morning to our pockets turned on. A UserInsertID 0 had enabled admin to see pockets and adjusted editing time.

    Could the same User ID "0" allow for modification of dashboard items.

    I too completed an migration about a month ago and had UserRole for UserID 0 set to 0 which had very high permissions.

    I've sine changed it to 2 and changed all InsertID to a legit user. There is no UserID 0 though.

    How would I confirm I've closed this hole?

  • Which version are you using?

Sign In or Register to comment.