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
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.
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.)
(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.
Comments
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.
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
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.
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.)
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?
2021.009