Keeping the script kiddies at bay?

The server I administer has been growing in popularity, and recently attracted three low-lifes who, methods unknown, were able to grant themselves *.* permissions. They didn't actually do too much griefing, even through I was offline when it happened. After I banned them and removed the permissions one of them started taunting me from my dynmap chat, claiming to have ssh access, etc. I assumed he was bluffing, but just to be sure I created a new account (ubuntu cli), removed the old one, and switched the password. Blocking his IP address made no difference, the kid has enough knowledge to access and use different IP's (proxies probably), and since his IP's keep originating from the US I can't block whole chunks of IP's without risking my users. Finally I turned off the dynmap chat so I didn't have to deal with him taunting myself and others -

What do the rest of you do to deal with this? Also, other than the answer of him actually having SSH access (which I doubt, since I wasn't locked out) how did he manage to grant him and his friends *.* permissions? I use PermissionsEx...

 

First thing: what backend are you using for PEX? yml or SQL DB?
If you are using a SQL back-end, do you have any sort of web interface that would allow people to access the database outside of the MC server itself?
If the back-end is yml or there's no publically accessible methods to the database (let it be a web interface page and the SQL server is properly firewalled), then the most likely methods of entry is indeed direct server access (SSH) or they had someone on the inside.

The latter situation is precisely why you'd want a plug-in to log commands executed by players.

In any case, if you are really paranoid, passwords should not be trusted. Use public-key authentication for the SSH connection.

 

I think your getting trolled and you just make a mistake with the permissions or one of your admins if giving away admin rights to randoms. I highly doubt that he would claim to have ssh access if he really did and if he did wouldn't he just unban himself again.

Edit: i am not sure if this works in PEX but i remember when me and my friends use to "Greif" we would just be good until on of us got Mod then we would create a new group and give it * permissions, then move my friends into that group, and then they would move me. I think this was only because originally the essentials permissions were set up badly.

 

PEX has very nice controls governing access to change groups and memberships. A well configured set-up can have the moderation team being unable to do anything but promote and demote along pre-defined paths, and that will be all that's required. There's no need in that situation to give anyone but the server developers+ the controls to create or directly alter groups/memberships.

 

Ohh thats good, then it must be somthing else, i wonder if he has any plugins that might contain backdoors? Because that has happened before.

 

Possible, but not exactly the first thing you'll be looking for. Planting a backdoor to modify the permissions architecture would be a challenge, assuming of course that you don't use the same database for all your plug-ins SQL needs and that is assuming of course that SQL is being used to store the permissions data. In all likelihood, back-dooring the permissions system via Bukkit plug-ins is not going to be on the priority list to check.

A more direct approach would be to attack the SQL database by attempting to connect to it directly. That of course is null and void if the port has been firewalled off and the accounts used are configured to allow the connection if and only if the incoming connection originated from the localhost. And once again, null and void if PEX is still in yml mode.

Excluding the possibility of the SSH account being compromised, that leaves as the last major plausible option someone misusing their access to the server and handing out higher privileges inappropriately; which is why I mentioned in my first post it's a good thing to have plug-ins to log all player commands for this very reason so you can check and find out if that happened (and if needs be, know who to reprimand). There's nothing you can really do about that except of course ensuring that only people you trust absolutely have the permissions to make such changes to the server and its operations and ensure that by default, no one can do more than you expect them to need to do. Design a tight enough permissions structure, and in the worst case scenario that all heck breaks loose and you have a rogue moderator promoting everyone, the server won't get porked too badly if at all.

That's partially the reason why I dislike using the ops status that's inherent in the Minecraft server. With good Permissions design, there's no need for it and you know exactly what access people have, whereas at the moment, op status is kind of being used as a parking spot for all access.

 

I'm absolutely sure that it wasn't another user giving them any kind of access - my mods do not have any permissions related to PEX. I just double checked and there are no PEX permissions anywhere in my permissions.yml - I'm the only one who can use it. I do not have PEX using mysql, just sqlite

I did realize that the security hole might be buycraft - I changed my privatekey just in case. Finally, here's a list of my plugins -

Code:

GravelClay, CommandBook, mcbans, Lockette, orbBeGone, AutoPlant, MinecraftViewer, OpenInv, Spout, SpawnBed, HeroSpawn, HeroSneak, BorderGuard, CommandSigns, MobBounty, WorldEdit, ColoredSigns, NoGrief, SimpleReserve, NoGriefLava, iConomyChestShop, mcMMO, HeroBounty, PermissionsEx, bCoolDown, Multiverse-Core, Spoof, HeroicDeath, nSpleef, Dontkickme, BuyCraft, Votifier, AutoMessage, iConomy, MineBackup, Minequery, VoxelSniper, MoveCraft, Curseban, VoxelPort, Permissions, RawcriticsOreObfuscationPluginSpout, RemoteToolkitPlugin, Golder, mxAntiPVPCheat, AntiCreeper, bShortcut, dynmap, ThunderTower, ServerLogSaver, NoGriefTNT, Multiverse-Portals, ChatManager, Modifyworld, Factions, LogBlock, HelperBot, VanishNoPacket

 

Hmmm... Command Signs. Does anyone have access to create elevated permission command signs? Of course it means nothing if you haven't even created the special command handler user for it... (Oh, you may also want to look into ScrollingMenuSigns if you're looking for an alternative/replacement if you haven't jumped to the new maintainer line for CommandSigns)

Might also double-check the settings for the Minecraft Remote Toolkit as that has the option for telnet access to the server.

I'm a little unaware of how BuyCraft works. Is it possible if one had access to the private key they could quickly create a purchase option (for no cost) a permission setting to give them * then delete it? If so, that should leave behind a server console log entry when the permission is purchased.

Also, one last thing. Although I don't advocate security via obscurity, PluginList can be handy to tuck away the existence of plug-ins which users have no need to be aware of (such as your administration plug-ins)

 

Hi, im the developer of buycraft, there is no actual "security risks" if someone gets ure private key, however if they do, they can view information such as your recent purchases, ect ect, but not perform any tasks on the actual server. So it wouldnt of been buycraft.

 

Most epic post ever, when i said backdoor i just meant a plugin that may have a loophole to Op you, for there you can edit your own permissions.

 

Thanks for all the replies -

@lmc - I wasn't trying to slander buycraft or anything, just when considering which plugins have the functionality to elevate users, yours and permissions are more or less it on my server. As far as I know no one could have gotten my private key, but to be safe I generated a new one.

@Takel - I actually only added commandsigns yesterday, so the incident happened before that would have been available. I also double checked rtoolkit, and I have telnet turned completely off.

Hmm. It seems that the security issue doesn't lie within a bukkit plugin, which more seriously indicates a server intrusion - On the other hand if that was the case then I would have expected him to unban himself, ban me, rm *, etc...

 

No problem, didnt take it that way just giving my opinion

 

"sigh" It happened again while I was at work. Two new usernames, unknown if they were the same as before, were able to give themselves unlimited permissions, this time banning just about every regular user and filling the world with admintium. I'm in the process of restoring a backup, but since clearly I still have an issue I was wondering if someone would take a look over my permissions setup and tell me if I've missed something... (everyone is in default except any kind of donors as of now)

Is there a plugin or a way to kick/ban anyone who's not whitelisted who uses a particular command? I'm the only one who should be able to use pretty much all worldedit, voxelsniper, permissionsEx and mcbans commands, and it would be great if I could kick anyone else who tried to run many of those commands, and ban after several attempts.

 

<USER>: group: - mage

Sup with that name?

 

I've been using the mage group as a test for a classes system I was getting ready to roll out, I probably mixed up the order of a pex command and gave user "" the mage group. I can't imagine it's related to the security issue, but I deleted it.

 

heh best to be sure and be safe.
still they are quite a few groups there.
Not to mention the amount of personal permissions for users :/

Could it be then one of your admins/mods have their accounts hacked?
Maybe a suggestion to your mod/admin team to have their passwords changed?

 

The best thing what you can do is, clear all permission groups and start from scratch, carefully going over what/who your giving permission too.

 

And that yep
might be a suggestion to make groups instead of giving persons different permissions?
The whole file is quite confusing to say the least

 

@semibreve42
According to the config file posted, you have 5 people in there with individual permission.* nodes which gives them full access to modify PEX groups and memberships.
Those people are: Ank209; DoctorBrain; oblop; skillerfox3 and mangler29
None of those users have group memberships which if it were my config would indicate something suspicious is happening since that would imply that these people aren't even marked as a moderator and should in no way be allowed to have that kind of power. Ank209 in particular would be second only to yourself in terms of how much control they would have over the world as a whole with full access to worldedit, the ability to directly set iconomy accounts, bypasses to factions and lockette, full commandbook access, and has no specific group membership outside the default.
skillerfox3 and mangler29 have full worldedit access as well.

As mentioned by a few posts above this one, your permissions configuration is messy. Far too many specific individual permissions for players which implies that your groups aren't configured well enough to cater for most use cases and that makes for a very confusing time when auditing since not only do you need to check your groups, but oyu need to check each and every one of the users. In addition to that, some of your groups have redundant permissions as they are already inheriting those permissions from a parent group, which again is messy.

IMHO, Permission configuration should be like having a set of key rings. Everyone is given a set of stock standard key rings, perhaps even multiple sets, which contains the permissions they need and there should be very few loose keys (permissions) because you can't keep track of those easily. There may be special cases but those should remain as special cases rather than the norm.

In short, your permissions config has a major breach of security in it with 5 people having the access to give anyone * access or any permission they could want.

 

@Takel - Thanks for the lengthy reply -

The 5 people who have * access are the "hackers" or whatever would be the right term who managed to give themselves those permissions. Obviously the perms file I'm using now has them deleted, and they are also banned. I just left them into the one I posted here to show exactly what they achieved.

I agree that in many cases my permissions are "sloppy", but in my big list of things that the server needs done, going through and removing dupes is low on my list.

As for the number of individual users who have their own nodes rather than getting them from a group, the reason is that my donation system has a privileges that are limited in time through buycraft, which adds and removes those nodes automatically. I don't really see that as any more or less efficient then having to make a group for each of those nodes, and add and remove the user from that group to add or remove those specific nodes.

In any case my issue stems from the 5 users being able to get all commands, and between myself and Takel and the others who were kind enough to look over my perms setup that while it's not ideal, no one identified a security hole that explains the breach. I'm almost positive at this point that the flaw is not in my server's access either, since I can't imagine why they would not have locked me out, or added themselves to the ops.txt, or just deleted everything, rather than just griefing and requiring a restore from backup.

Unless I'm missing something that leads me back to a security flaw in either bukkit or a plugin I use, which is troubling since (not being a coder) I'm limited in ability to identify the issue. To this end I've added PluginList to obscure what plugins I'm using from my users, and a command logging plugin so that if it happens again, I may be able to identify the flaw.

Thanks all for your time and help -