Minecraft security | Part 3; Identifying risks

Discussion in 'Systems Administration' started by MrDienns, Mar 25, 2020 at 10:45 PM.

  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.


    Preface & warning
    Now, before we start. This part is long. Not in reading, but in executing. Performing the tasks described in this part will take dedication, creativity and especially time. And to put a warning disclaimer; security is everywhere, in all kinds of shapes and sizes. There is no one size fits all, there is no simple check list to run by.

    The problem with this part however, is that it's difficult to identify security risks if you're not actually aware of them. Some of these are easy and I will explain through the CIA Triad. Others are less easy. For example, how can you be aware of SQL Injections if you barely know what SQL is? This is what I mean with dedication and time. If you want to secure your network, you need to gain knowledge. There's no other way of putting it. You need to learn, you need to investigate, you need to research, and you potentially need to test. This may be difficult for some. I will try to help you towards learning this knowledge yourself.


    Identifying risks
    Before we can start improving our security, we must identify what needs to be improved. With the information gathered on what risks we have, we can start planning towards improvements. The identifying in this part will not only point towards information, but also systems itself, how likely they are to be hacked, how they can be hacked, and what kind of impact this would result in.

    A risk can be summarized with an impact and a likelihood. A high likely hood and a high impact is naturally a high risk. Low likelihood and low impact, low risk. High impact, low likelihood, medium risk. There are matrices online which put this into visualization.

    I found this one online, which is nice;

    [​IMG]

    For the sake of this part, let's use this matrix for identifying our risks.

    This all sounds really nice, right? A method of identifying risks, and giving them a certain risk score. This is nice, until you realize that you actually need to build this list. Where do you even start? Some of with, especially ones with complex & larger servers, have a pretty decent technology stack. You can't even begin to consider listing down every single possible security risk in detail. It's just too much. It's too much to list, and it's too much we're not certain about. We can't, with our knowledge on security, start making a list of 6 million security risk items out of thin air.

    Instead, I suggest we identify a few issues based on the higher level. On this high level, we will mostly look at architecture issues & lateral movement. Even knowing that we need to look at things from a high level, where do we start? Luckily in these kind of analysis, we almost always use 3 categories; Confidentiality, Integrity, and Availability. The so-called CIA Triad. And no, this has nothing to do with the Central Intelligence Agency.


    Confidentiality
    We all have data. There's no way around it. We serve a product / service, we have data. Remember that when I talk about data; I also mean software. Custom made software for instance. For confidentiality, we have to evaluate how confidential this data is. How important is it that this data never goes public, or is accessed by an unauthorized person? A no brainer is PII (Personal Identifiable Information). With COPPA and GDPR nowadays, any personal data should be seen as highly confidential. IP addresses, e-mail addresses, etc. Arguably also usernames and UUIDs, though there's not much we can do to hide those from the public now, can we?

    Let's look at the chart above and look at some examples of common data. These examples are just based on some common servers.

    UUIDs / usernames
    As much as I still don't fully agree with UUIDs being personal information, plenty of people say they are. Let's just take it as a perfect example of something that has a very low level of confidentiality. Even if you wanted to keep it confidential, you can't. They're publicly shown and used.
    Likelihood: Always. You can't hide them when they are used.
    Impact: None existent, they're already public.
    Risk: None. Feel free to change my mind (on confidentiality!)

    IP access logs
    Plenty of servers, websites or just about any service log IP address access. In fact, all should. However, do keep in mind that the GDPR for instance has explicitly stated that IP addresses are personal data. They should be treated with maximum confidentiality. If they are accessed by an unauthorized person, you could be in quite some trouble if it happened at large scale (lots of data being leaked, lots of people impacted). I will give this one a likely likelihood, because a lot of people will give moderators or administrators access to IP addresses. For example, in-game through Essentials.

    Being extremely official, if you are a registered company (like me), you should put people under a contract for this, but I won't go into detail here. The impact should be rather low, since I assume nobody randomly becomes a moderator or administrator in the first place. For the analysis, let's follow the law.
    Likelihood: Significant. Typical staff setups & potential unauthorized access.
    Impact: Minor. It's not the worst thing that can get leaked, as IP addresses also rotate from time to time.
    Risk: Low Mid

    Passwords
    Oh boy, here we go. I cannot stress how many people simply do not understand this. Passwords are important. They're everywhere. One could have a valid argument stating that you should use a password manager, which indeed you should use. However, let's not forget we're dealing with kids here. You may have a website, or an in-game registration (such as on cracked servers) which store a password. Again, we're dealing with kids. Seriously, those passwords aren't gonna be strong, we all know that. Kids are just about to explore the internet. They're likely to use the same password everywhere. Would be pretty pathetic if a kid had their online services hacked because their password got leaked because of some stupid Minecraft server, right?

    I'm giving this a possible likelihood. Why? Because people are stupid. Not the players and their passwords, but system administrators and developers. Hell, literally today, @clx_ found a chat plugin here on the site which simply logged the chat into a MySQL database. Turns out it was SQL injectable. Him, me and @MiniDigger then continued to see if we could exploit this. And sure could. We could just type something in the chat, and lo' and behold, the server fucking died. That was fun. We didn't take things further, but we could've easily done a sub query to read the columns from another table or even another database, with potential passwords. We could've also read files from a system, because MySQL can do that for some reason.
    Likelihood: Possible. People are unaware. Lots of 5 star reviews doesn't secure this risk.
    Impact: Significant. Let's protect the kids, please. Also your own (administrative!) accounts.
    Risk: Med High


    Integrity
    Integrity is the risk of data not modifiable, deletable or creatable without restriction by an unauthorized person. Now, in the context of Minecraft, I'm not fully certain how much this actually applies. We could think of our protected spawn as something integer, but we all know that should not be modifiable. I think this also goes quite hand-in-hand with some of the topics mentioned in the confidentiality part, as well as the other 2 parts in this guide; Awareness, and The exploit chain. If anyone has any examples or things to mention here, be sure to let me know, but I think this goes quite hand-in-hand with the overall mindset of "don't fucking let anyone access your things without permission".


    Availability
    This is where the fun begins. You and I both know it; botnets, SYN-floods, Ping of Death, Slow Loris, DDoS attacks! We all love and hate them. They're super cool, but super annoying. Luckily, there's a way to deal with them! I'll go into great detail in a bonus part of this series if it gets enough love. For now, let's assess the situation. You have a technology stack. You may have proxies (Bungeecord), databases (MySQL, MongoDB), websites, etc. Some of these components are crucial to stay available.

    Databases
    For instance, I think most of you will know Dyescape. It's my personal project; a ridiculously massive MMORPG in Minecraft. I'll cut right to the chase; everything in our setup comes from a database. The content (items, quests, potion effects, monsters, drops, regions, shops, skills, guilds, dungeons, professions, etc). It's all actively loaded and synchronized from and to a database. You could probably imagine this database is extremely important to us. That database, under no circumstances, should go down. If it does, it should get back online as soon as possible. And I don't mean that lightly. Sure, our servers can keep on running without the database for some time, but naturally; data can't be saved. The longer we wait, the bigger the impact on players.

    Now, something this crucial, within information management security terms, is called a crown jewel. It's your most important piece of information (systems included). For us, this database absolutely is a crown jewel. For that reason, we must do everything we can to keep it available; up, running, and serving. However, databases in your technology stack are likely to also be crown jewels. Loads of applications need the database in order to function. It reads, it writes, if it's not there, it can't do either. Simple. From websites, to in-game plugins, they'll all completely break if the database is not available. I suggest you to really look at your database setups and how easy they are to be screwed around with. My own database servers are not publicly accessible at all. And I don't mean the database ports, I mean the entire server. You can't ping it. I could give you the IP, and you could literally not do anything with it. Sure, you could try to do a layer 3/4 DDoS attack which may overload the public network, but things don't connect over the public network.
    Likelihood: Likely. Some may have their databases properly secured, some may not. DDoS or simple service denial attacks are super common though.
    Impact: Severe. Applications heavily depend on it.
    Risk: High

    Reverse proxies (bungeecord)

    A reverse proxy is something you connect to, and that proxy, in your name, connects to a back end server that's not directly exposed to you. Or at least, is suppose to not be. Yes, I'm looking at you, people who install Bungeecord without reading the bold-red post-installation security section. While reverse proxies are great in many, many ways, they also pose a few risk.

    Typical Minecraft Bungeecord setups have one security risk in common; they're single point of failures. You may have 10 Spigot servers in the back, but one Bungeecord proxy. If that proxy goes down, the single point of entry goes down, and your entire server becomes inaccessible. It can become unavailable for many reasons; a crash, a restart, or a malicious guy doing malicious things with malicious intent. Regardless, it's never a bad idea to get multiple Bungeecord proxies, for the sake of availability security. Sure, it's overkill if you don't need it, but a single layer of defense should never be considered enough. Bungeecord is super lightweight, anyone reading this thread likely has enough budget to run a few Bungees.

    Some servers like Hypixel, due to their insane size of course, take things to the next level. They have a mechanism where they use a round-robin DNS setup (basically DNS level load balancing) in order to forward users to a set of rotating bungeecord servers. Some go public, people join, then they hide, and new ones show up. They have hundreds of these proxies. Good luck taking those down.
    Likelihood: Possible. Things can crash, things need to restart sometimes, things can be taken down.
    Impact: Moderate. People will be unable to join the server.
    Risk: Medium


    Lurking risks
    These risks are a bit scary, but I want to mention them. As I stated in the previous parts of this security guide; some people are just unaware of security risks. Developers & system administrators alike. I would absolutely recommend you to, if you're serious about your project, to double check everything you install for potential risks. Even if they're not intended, they may be there. There are always risks which are easy to spot. Most common; SQL injections. They're easy to find, easy to patch, and sadly, sometimes easy to exploit with severe consequences.

    I would highly recommend you to, when you use a specific tool such as MySQL, to read up on SQL security risks, such as SQL injections. Then, learn how they are created (in Java for instance) and how to prevent them. Look at the source code of plugins, either on Github if they're open source, and otherwise decompiled. Yes, just decompile them. Nobody gives a shit. Look through the source, look for SQL statements (if the plugin supports it, obviously) and check how they're implemented. I won't go into too much detail, but here's a simple rule of thumb; does the SQL query have user input, which is injected into the query through string concatenation rather than a PreparedStatement (so a normal Statement)? It's likely injectable.

    These are the kind of additional risks that you may need to educate yourself about. Look at the tools that you use, and do a bit of Googling around for security recommendations or pitfalls. You'll likely come across things you can double check in the plugin implementations.


    The biggest risk of all
    Now, after you've read the entire previous wall of text; after reading about so many risks being everywhere, lurking beneath the grass, there is one risk which is far greater than anything. It's risk is so big, and so large, that it's almost impossible to detect or prevent. A security risk which has full administrative access. Think about it yourself. Think about what it could be.

    You.

    The biggest risk of all is simply none other than the living human being placed between a monitor and chair. Sometimes also referred to as "PEBKAC" - Problem Exists Between Keyboard And Chair. It's called social engineering, and it's more effective than you may think. It exists in many forms, and it's everywhere. The difference between typical hacking and social engineering, is how social engineering tends to not be technical at all; it's social. It's uses social exploits within humans to achieve things which shouldn't be allowed.

    I'll post a few serious, but also funny examples.

    Here's a quick, very short video which demonstrates how social engineering could work, trying to have a support employee give you access to some kind of account or even just information;


    A funnier example;


    As stupid as the above look, they're effective. You walk in somewhere, dressed up like you gotta do some work, and some people (which if done well is suppose to be a natural reaction) won't bother.

    Imagine you work in a large IT company where the building doors are locked behind keycards. Imagine someone walking behind you, wants to get into the same (locked off) department. Now, it's a large company, imagine 10,000 people in the building. You open the door, the person behind you wants to also enter. Any normal person would simply hold open the door and be nice, right? Well, what if that guy shouldn't have access to the room? You don't know that, nor do you want to be a douche bag and literally tell the guy "hold on", and fucking close the door in front of him. Nobody does that, nor do I blame people, but it's still social engineering.

    With support employees, be noted that professional companies and employees there are often trained against this. However, that doesn't mean you're not vulnerable to this yourself. Imagine you're a starter, out of budget, trying to make a unique Minecraft server. We've all had the classic "Hello I am from PlanetMinecraft, you have a wirus, please give me admin" person, but we all know that one (hopefully) doesn't fool anyone. But if you're desperately trying to get something unique, you may see a developer hop on your server, offering you a free custom plugin. You get excited, he makes some "features", you install it, and boom, you're fucked; you just installed malware.

    Social engineering is simply everywhere, and it relies on humans making mistakes rather than code being executable. This is particularly scary to those who are inexperienced, or simply unaware of security. At least the awareness is what you should gain from these posts.


    Summary
    Risks are everywhere. They can be quite challenging to identify. I cannot give you a simple checklist that you can run by. You need to gain a certain knowledge on these topics, and where things can do wrong, so you can double check things yourself, such as SQL injections. In addition, you are now introduced to the CIA triad, and how you can look at your overall architecture to identify where risks may lay. As always, feedback is greatly appreciated.
     
    • Like Like x 3
    • Informative Informative x 1
    • Friendly Friendly x 1
    • Useful Useful x 1
  2. This series is by far one of the top 5 threads on this community.
     
    • Winner Winner x 2
    • Friendly Friendly x 1
  3. Andre_601

    Supporter

    I hate to admit this, but I did fall for this when I was younger.
    A "developer" showed up, telling me he could make a jump pad plugin, which is better than the normal ones I used. He gave the jar, I tested it and it worked... But the catch was, that he implemented a "chat command" (Typing specific phrases in chat that the plugin listens for) which gave him OP and such.
    As I said was I quite young and naive at that point and since then started to first check sources of plugins and other kinds of software/files, before using it.
     
  4. Lacks the resources tag.
     
  5. None of these posts have them. I don't think this is a resource though, right? Can't even seem to add one under this forums section.
     
    • Agree Agree x 1
  6. Andre_601

    Supporter

    The resource tag is for resources (plugins, website designs, etc) and not for basic posts... At least that's what I know.
     
    • Agree Agree x 1