Minecraft security | Part 1; Awareness

Discussion in 'Systems Administration' started by MrDienns, Jan 21, 2020.

  1. Note: This series isn't finished yet, and I may refactor pages severely the upcoming days.

    A comprehensive series of posts explaining why Minecraft servers get hacked, and what you can do to prevent it. This post will speak of several things which are almost always the case in those classic YouTube videos where servers get hacked. I will explain in detail why this happens, how this happens, and what you can do to prevent it. This is a post designed towards everyone; from (public) plugin developers, to system administrators, to the professionals who have full custom networks.

    In cyber security, you shouldn't asked yourself if you get hacked, but when.

    These posts consists of the following parts;

    Introduction
    I am writing this because I (too often) see servers get hacked. Now, this on it's own, while problematic, isn't necessarily alarming. What is alarming to me is how, and why they get hacked. For that reason I'm writing a multi part security blog (or whatever you want to call it) raising awareness to pretty much all. Note that this guide isn't specific to Minecraft; this is software development and system administration in general. This is the first part in the series.


    Awareness
    Be really honest with yourself in this part. You most likely have something running (probably a Minecraft server). Have you ever sat down for quite some time and had a good, deep thought about how secure your network is? How it could be hacked, and what would happen if you get hacked (in terms of damage) and how you would tackle a breach? Most likely not. That's where the first problem comes in. If you did think about it, congratulations, you're on the right path.

    Unfortunately, many people don't realise that the lack of security attention will result in security risks. It's inevitable; unless you're actively thinking about security while building or maintaining your setup, you're very likely to create risks.


    Assess the current
    The first step in this is to start an assessment. Look at your entire setup (yes, everything, as large as it may be) and investigate how exactly things are integrated with each other. Which things are connected, what are some shared services or databases? This is crucial to know for the next section. When doing this assessment, create a layout of how everything works and how everything is connected. One could use an UML Component Diagram for this.

    Exploit chain
    The reason why we do this is further explained in part 2; the exploit chain. Without spoiling too much, it comes down to one exploit causing another. The minor breach in system A could result in a breach in system B, C, D, etc. This is what many people simply do not realise. A perfect example is the permission system. Many administrators which configure the MC server will think that a certain functionality is safe because it's locked down a permission. This is true, until you figure out that you misconfigured your bungee and someone could simply OP himself. At that point, your permissions are no longer preventing anything, and the fact that your bungee connection got breached (initial exploit) thus now results in further exploits (chained exploits).

    This is what I call the exploit chain (there's probably an official term for it) which I will cover in detail in part 2.

    Example
    Below is an example. We have a classic Minecraft server, with a BungeeCord setup, three different gamemodes (factions, towny and skyblock). It consists of databases, a web shop (Tebex) link, and a Discord synchronization (DiscordSRV). I suppose this is as generic of a setup as one could imagine. Any tips or additions to this, be sure to suggest them below.

    Let's view the below image of how things are connected in this scenario (most likely!);
    [​IMG]

    We have a BungeeCord, connected to all Spigot servers. All Spigot servers are also connected to the same database server and the same database (like a MySQL database). They're also both connected to Tebex and Discord. For the sake of this section, let's assume both Discord and Tebex are integrated to the max; synchronized console to Discord, and being able to manage your store from in-game in Tebex. We are assuming this because I believe this is the most common.

    Now, I want you to take this image and paste it somewhere in paint or anything which allows you to easily draw on this. I want you to draw a red cross (double line) through connections which shouldn't exist at all, and a single red line through connections which should be modified (integrations or functionalities which should be disabled).

    Review the current

    In the spoiler below is my view on it. Somethings may surprise you.
    [​IMG]

    Now hold on, I can already see you cracking your knuckles, preparing to go full out in the comment box below. But hold on, let's carefully look at this. This is where awareness comes in.

    Look at these functionalities, and really think to yourself which of these is necessary. This may differ for everyone; one person may have more custom development capacity compared to others. However, point remains; both should review things and and question if things should work this way.

    The happy-flow mentality
    Many people will set up their Minecraft server in a happy-flow strategy. They'll start setting up things, and once it works, they stop. It works, it runs, you have players, your job is done. Right? No. We're all (at least I hope) aware of the classic Bungeecord "exploit" where players can directly connect to your Spigot server through a spoofed Bungee proxy if you didn't firewall your setup properly. As ridiculously old this technique is, it still works even today. This should prove the above mentality of lots of people.

    The problem is that the most obvious and straight forward setup is usually not the best (or, at least not the most secure). Think about what I mentioned earlier with your permission problem and you getting Bungee'd (a verb to indicate you got Bungeecord firewall hacked). You may think that things are fine with just some permissions. You leave a functionality enabled, but you hide it behind a permission. It works, it runs, you have players, nothing is wrong. Yet. Untill you get Bungee'd, and your permissions are all bypassed.

    This goes for everything you can then do from within your Minecraft server; manage your Discord server, access private user data, read personal data from your webshop, modify your webshop, execute SQL queries or read files from the disk (yes, some plugins are stupid enough to have such functionality).

    Spigot plugins
    While Spigot is lovely because of the plugin mechanism, this does introduce a big risk. Spigot is great for modding because of plugins. But, let's think about this for a second. A plugin, what is that exactly? In a sense, it's just some code which automatically got executed by some other code. By definition, that is extremely risky. All hacking pretty much comes down to making a machine do what you want to do. Some more unexpectedly or complex than others, but it comes down to the same thing. The fact that a plugin is in the end nothing but some code being automatically invoked, is risky. You as developer and administrator should keep this into account. Why you should keep this into account has a developer is explained in further parts. You should always be careful with the plugins you install.

    @Optic_Fusion1 has a list of all of the malware he found on Spigot. Would be interesting if he could share some numbers on how much malware he found, and what this malware does, and how it works. Also be noted, malware can spread! If you don't setup your permissions properly, one plugin could just write another Jar file, effectively moving the malware code to a new Jar, which may help hide its malicious intent.

    Not only is this risky from a code perspective, but also from a configuration & data perspective. More about this in part 2, 3, 4 and 5.

    Summary
    This first section may be a bit hectic in it's writing, but that's because I want to raise awareness, and that's the summary for the first part. Look at your setup, and most important, be honest with yourself. Reviewing your technology stack, how it's all integrated with each other, and ask yourself if you really need it. Don't use something just because; use it because you genuinely need it. Not a single soul on this planet genuinely needs to synchronize his Minecraft console to a Discord server. I'll pay you $100 if you can convince me otherwise.

    Next up; Part 2; The exploit chain

    Comments or suggestions are welcome.
     
    #1 MrDienns, Jan 21, 2020
    Last edited: May 12, 2020
    • Like x 12
    • Winner x 9
    • Agree x 2
    • Informative x 2
    • Useful x 1
  2. This is simply brilliant.
     
  3. Very interesting read. I'm looking forward to the next post.

    In isolation, as the only post available in this security series so far, I'm not sure if it necessarily succeeds in increasing my awareness. Besides the diagram exercise in the middle, most of this post (or at least the second half) seems to be merely hinting at what your security prescriptions will be in future posts. As it stands, I think there needs to be more elaboration as to what readers are being made aware of.

    What I'm really trying to get at is--and perhaps it's entirely because the remaining posts aren't available yet, but--this first segment feels somewhat incomplete. In other words, I don't feel like it has much to say on its own. If the goal is to get the reader to analyze, or at least consider, their network's layout, then I think that should be the primary focus rather than annotating when specific problems will be addressed in future posts.

    Don't mistake these critiques as condemnation - I agree with most of what's been written. My criticism is more for how it's been structured.

    However, I certainly don't agree with this characterization of DiscordSRV:
    The implication of calling DiscordSRV "insecure by design" is that it was created to be insecure on purpose. While it may contain optional features that significantly increase security risks, there is nothing inherently insecure about its primary goal of facilitating chat between a discord server and minecraft. If your problem with DiscordSRV is its console channel, then I think it would make more sense to mention that specifically than denouncing the plugin entirely. Especially when roughly 2/3 servers running DiscordSRV don't even use the console channel.
     
  4. Yeah, I agree. I wrote this quite quickly last night so the writing isn't great. I'll have to see on how to improve things while also staying on topic for the other parts.

    If it sounds like I make it look like its insecure on purpose then I will rephrase it. However, purely the console feature isn't what makes it a bad (or atleast, not ideal), even if it can be disabled. I'll elaborate later.

    Don't get me wrong, DiscordSRV doesn't do something "wrong", it's just not ideal. I'll explain in part 2.
     
    #4 MrDienns, Jan 22, 2020
    Last edited: Jan 22, 2020
    • Friendly Friendly x 1
  5. @Rezz I've rewritten a decent chunk of the above. Mostly the bottom part. Would highly appreciate it if you could read it again and provide additional criticism if you have any.

    @Optic_Fusion1 I expanded a bit on the section which explains why a plugin based software (like Spigot) is risky. Again, it's great for functionalities and I wouldn't have suggested any other way, but it's a risk also. I tagged you above where you could maybe provide some numbers. Could be interesting.
     
  6. My AntiMalware database contains a total of 218 files, 217 of them are malicious plugins and 1 of them is a malicious skript. One of the plugins has been on spigot since 2016, which i only found sometime in 2018, showing just how easy it is for a malicious plugin to stay on spigot. Some more notable examples is the ForSoft incident.
    As for what these malicious plugins do, well it depends. A good example is the following image
    upload_2020-1-22_4-26-50.png

    Sometimes it's just a simple Force-OP, other times it's a variety of commands like the image above, there's one or two that's worse though.

    Edit: Shameless self promotion
    My AntiMalware will detect a large variety of malicious plugins (there are some false-positives sadly though (Mainly Force-OP))
     
    #6 Optic_Fusion1, Jan 22, 2020
    Last edited: Jan 22, 2020
    • Informative Informative x 1
  7. "Now hold on, I can already see you cracking your knuckles"

    Oooh so close, I was so close to comment after cracking my knuckles :)

    Thanks for writing this out.
     
    • Funny x 2
    • Like x 1
    • Agree x 1
    • Winner x 1
    • Friendly x 1
  8. Hi, I am preventing internet access to all potentially dangerous ports.
    My project is currently using 8 dedicated servers and I still do not see how it can be done even better.
    Here is one of my iptables rules:
    iptables -t raw -A PREROUTING -p tcp -i eth0 -m multiport --dports 3306,1099,3000,19999 -m set ! --match-set allowips src -j DROP
    All spigot servers are also closed externally.
    I can also offer topics for discussion, such as installing plugins with obfuscation, preventing DDoS and bot attacks.
     
  9. You're on the right track. Limiting external connections is definitely one of the first steps to take. In an ideal world, you would have some kind of virtual network where you have some of your dedicated servers. For example, I'm running the majority of my project in Kubernetes (not everything at the moment due to lack of hardware power on the cloud plans).

    For your information, if you're unaware; Kubernetes of a containerised (Docker) orchestration cloud platform. It allows me to deploy software through containers very easily. I can then setup firewalls (internally, within this environment) which states what pod (a set of containers) is allowed to connect with each other. For instance, let's say I have a setup with a BungeeCord, a Spigot and a MySQL container.

    I can setup my internal firewalls in such a way that Bungeecord pods are only allowed to connect to Spigot, and Spigot pods are only allowed to MySQL. Not only that, I can state who'se allowed to open the connection. Only BungeeCord is allowed to open a connection to Spigot, and only Spigot is allowed to open a connection to MySQL. Spigot is not allowed to open a connection to Bungeecord, and MySQL isn't allowed to open a connection to anyone. This is another step you could take in firewalling, though I'm not 100% sure how this works with raw IPTables, so you may have to do some research. In Kubernetes it's nice because it's backed by service discovery, meaning it's all automated.

    On top of that, you could create some kind of virtual network which limits access to certain machines on layer 3/4 (I think). Professional hosting companies offer this. For example, OVH offers it, but it's a tad limited at the moment (it doesn't work with Kubernetes yet). This is another step you can consider doing.

    While these are indeed interesting topics, I had not planned to cover such topics in this series. I could very well add a part dedicated to this, but that would be part 6 earliest. So far the goal is to first inform people on full blown breaches, having their networks being taken over, passwords leaked, etc.
     
    • Like Like x 1
  10. Why does this need its own topic exactly?
     
    • Like Like x 1
  11. I probably meant a separate small paragraph.
     
  12. I could see a use for this. Some advanced malware may use reflection to invoke methods on some kind of plugin. For instance, a piece of malware that invokes some code from LiteBans, DiscordSRV, anything. It's Java after all, so that's possible. If it's obfuscated, you can't really base any malware on it. Or at least, make it a lot more difficult. At least I suppose that's something @MihailSen could be thinking of.
     
    • Like Like x 1
  13. MiniDigger

    Supporter

    installing software which code you dont know is a risk.
    installing software which code you physically cant properly inspect due to obfuscation is just asking for trouble and should be avoided at all possible cost.

    thats everything that has to be said about obfuscation. just avoid any software that uses it.
     
    • Agree Agree x 1
  14. The idea more comes from obfuscating it yourself, not using obfuscated tools. Like, taking an open source plugin, obfuscating it yourself with your own obfuscation logic. While this is pretty overkill, I suppose that's what was being meant.

    Anywho, part 2; https://www.spigotmc.org/threads/minecraft-security-part-2-the-exploit-chain.414155/#post-3666419
     
  15. Fair enough.

    For those that aren't aware, I'd also like to bring up my own thread https://www.spigotmc.org/threads/list-of-found-malware.389467/ .
    i link pretty much any malware i find on it
     
  16. your so brilliant.
     
  17. It's a lot better now with the revision - everything is more focused and clarified. (y)
     
    • Like Like x 1
  18. Thanks. Be sure to check part 2 :D
     
  19. Andre_601

    Supporter

    Nice post...
    But I want to address a specific thing in it: The image.
    On the image do you show the connections, which is fine, but you leave out a few things. For example you you mention that in your example the console(s) are synced with Discord and tebex can be changed from the server... But your image only shows a direction from the servers to the different parts, while most, if not all do work in both ways (i.e. execute console commands from Discord when setup or changing the store on your site while the plugin updates the information it has and of course the database not only receiving but also giving information)
    I personally would change those arrows to either just lines or add arrow-heads at the other end too, to show that it goes in both directions.

    And many server networks may also have a connection from bungeecord to the database and vice-versa (e.g. by using the bungee version of LuckPerms for permission management on the bungeecord).
    This of course isn't always the case, so maybe add a pointy line to the image and mention this?

    Other than that a fairly decent post.
     
    • Like Like x 1
  20. Sure, I'll address that later today.

    I considered adding it. But the fact that 3 servers already connect to the same database should prove the point already :p