How to block this spambot?

beschizza

The bot edits an old thread's OP, as user 0. That's all it seems to do.

Here's how its edits show up in the edit log:

And here's how they show up in the database:

I've added the most obvious IP address range to the ban list like so, but it doesn't seem to stop it at all!

Any suggestions? I'm running Vanilla 2.1.5

peregrine

@beschizza said: The bot edits an old thread's OP, as user 0. That's all it seems to do.

look in your Role table and determine the roleid of Guests

usually it is roleid 2

yours may be different.

then check your UserRole table with phpmyadmin.

if you have a userrole with UserID 0 change the RoleID to 2 (assuming your guest role is 2)

UPDATE GDN_UserRoleSETRoleID= '2' WHERE UserID =0

peregrine

Also verify that your user table does NOT have a userid with the userid of 0

the first admin normally is userid 1

also run /utility/structure to ensure permission table structure is up to date.

x00

There should never be a user 0. Did you import from a a different forum? This can be a schema corruption.

beschizza

Thank you for these suggestions!

In the GDN_Role table, the RoleID of guests is 2.

However, there IS a GDN_UserRole with UserID 0 -- it has the RoleID 2 of guest.

The Guest role permissions appear to be orthodox -- they can only view profiles and threads.

In the GDN_User table, there was no user with UserID 0.

When you click on the spammer's name in a way that would normally take you to the profile, it tries to go to /profile/0/ with "Whoops! User not found."

The admin account is UserID 1.

This was indeed imported from another forum, PHPFox. This is a rather obscure proprietary system with no available conversion scripts, and I had to do the import "by hand" by hacking at the SQL until it conformed to a functional Vanilla database.

It's been rolling for about a year without problems, though one oddity of the switch was that every discussion acquired an empty OP, with the original OP as the first comment. And it is these empty new OPs which this bot is able to edit (including the discussion title)

You can see the forum at elfquest.com/forums

I closed the targeted thread, but the bot found a new one to edit at elfquest.com/forums/discussion/1506/x/p1

x00

This becuase you probably had a system where all the post were a single table, whereas vanilla you put the OP in the discussion table and the remaining comments in the comment table.

I have no idea how faithful your conversion was. It could have a number of security issues.

The problem is the application works a certain way, and if you don't have deep-seated knowledge of that it can difficult.

beschizza

/utility/structure reports the following:

x00

What you can do is run a query so that all imported discussions uses an admin InsertUserID and change the Body to something alluding to the import.

x00

Btw this i not just a random spam attack, in this case the spam has taken the time to target you specific weakness, even if the spamming itself is automated.

beschizza

I'll give the query you suggested a try!

Would exporting the database using the official export function, then reimporting it to a fresh installation of vanilla, be likely to close any "bespoke vulnerabilities" created by my amateur conversion?

x00

Not really that format lacks real schema. It should nor be used in upgrading, but for some people get confuse between conversion and upgrading.

On of the problem with that format is you 0 or empty strings when you should have NULLS.

Visit

/dashboard/role/defaultroles

peregrine

these are the default permissions of guest for a fresh install of vanilla 2.1.5 . see if for some reason your permissions are different.

e.g. do you have 1 in columns that aren't in the images.

continued ...

continued ...

peregrine

@beschizza said:
/utility/structure reports the following:

I assume you ran the "run structure and data scripts" and scanned again as well.

beschizza

@peregrine I did, and it now reports that all is well.

beschizza

Our guest role seems to be even less permissive than the defaults, with 1 only in the "Garden.Profiles.View" column.

I noticed, though, that while though there is no RoleID 0 in GDN_Role, there is a PermissionID in GDN_Permission's for RoleID 0 that is extremely permissive. Is that normal?

In GDN_User, should be numbers in the "Admin" column correspond to RoleID's? If so, as most of mine are set to 0 rather than NULL, maybe they are gaining the privileges of that GND_Permission RoleID 0

peregrine

did you try adding the banned ip range to .htaccess to see if that helps.

http://www.htaccess-guide.com/deny-visitors-by-ip-address/

beschizza

Good idea. That will be my last resort if I can't quite nail down this particular issue. (also, perhaps, disabling the ability to make retrospective edits?)

@x00 Here is my default roles page: https://us.v-cdn.net/5018160/uploads/editor/qe/uaxfi011fvy9.png

peregrine

I noticed, though, that while though there is no RoleID 0 in GDN_Role, there is a PermissionID in GDN_Permission's for RoleID 0 that is extremely permissive. Is that normal?

it is normal in the sense that a fresh install of vanilla 2.1.5 will have that row.

In GDN_User, should be numbers in the "Admin" column correspond to RoleID's? If so, as most of mine are set to 0 rather than NULL, maybe they are gaining the privileges of that GND_Permission RoleID 0

in vanilla 2.1.5 - the root or first admin created will have a 1 in the admin columns

any other admins will have a 2 in the admin column

any non-admins will have a 0 in the admin column

peregrine

@beschizza said:
Good idea. That will be my last resort if I can't quite nail down this particular issue. (also, perhaps, disabling the ability to make retrospective edits?)

x00 Here is my default roles page: https://us.v-cdn.net/5018160/uploads/editor/qe/uaxfi011fvy9.png

save it a few times.

beschizza

"save it a few times."

Done! And thank you for confirming that 0 is the default for the admin column.

peregrine

what is curious is what method are they using to edit the posts.

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.

you might also consider copying the 2.1.5 source over again, in case something was not updated sourcecode wise.