Minecraft security | Part 2; The exploit chain

Discussion in 'Systems Administration' started by MrDienns, Jan 22, 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;

    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.

    The exploit chain
    The exploit chain is what I call it. The official term is "pivoting" or "lateral movement", according to @DotRar. Anywho; to those reading this, you may have been in the unfortunate situation of having your server hacked. And I know what you're thinking; how the hell did <insert system that had nothing to do with the hack> even get hacked?! How is it possible that something small in Minecraft, ended up having my Discord, MySQL database, Tebex webshop, etc breached?

    In the introduction of each part, I post the following sentence;

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

    I'm not posting this for no reason. This statement should be taken extremely seriously. We live in a world where technology has become just an addition on top of an ever growing pile of already existing technology. Almost everything we build is built in top of something else. On top of that, everything is connected and integrated into each other. This creates indirect security risks.

    Let me elaborate with a few examples of indirect security risks, which can be exploited through initial exploits.

    Website with 777 permissions
    You may have heard about something called 777'ing your website installation. But, do you actually know what it means, and why it's disadvised to do so? To understand this, we have to look at how Unix (an operating system kernel) works. Also, for your information, practically every single OS is built on Unix except for Windows. In Unix, you can create users and groups. Files created on a system can be assigned to users and groups. You can set up file & directory permissions for users & groups.

    For instance, see the below. I'm pulling my Docker image I use for our XenForo installation. Looking at the XenForo (root) installation, the permissions look like the following;
    Code (Text):
    dr-xr-xr-x         0:0     1.4 MB              ├─⊕ addons
    -r-xr-xr-x         0:0      415 B              ├── admin.php
    -r-xr-xr-x         0:0     1.8 kB              ├── admindav.php
    -r-xr-xr-x         0:0      359 B              ├── css.php
    drw-rw-rw-         0:0        1 B              ├─⊕ data
    -r-xr-xr-x         0:0     1.1 kB              ├── deferred.php
    -r-xr-xr-x         0:0      541 B              ├── fb_channel.php
    -r-xr-xr-x         0:0      416 B              ├── index.php
    dr-xr-xr-x         0:0     3.1 MB              ├─⊕ install
    drw-rw-rw-         0:0      307 B              ├─⊕ internal_data
    dr-xr-xr-x         0:0     1.9 MB              ├─⊕ js
    dr-xr-xr-x         0:0      17 MB              ├─⊕ library
    -rw-r--r--         0:0      455 B              ├── nginx.tar.gz.asc
    -r-xr-xr-x         0:0     1.5 kB              ├── payment_callback.php
    -r-xr-xr-x         0:0      361 B              ├── proxy.php
    -r-xr-xr-x         0:0     1.0 kB              ├── rgba.php
    -r-xr-xr-x         0:0      581 B              ├── sitemap.php
    dr-xr-xr-x         0:0      10 MB              └─⊕ styles
    Those familiar with permissions will know what the left column means. To those who don't;
    • R means read, which has number 4
    • W means write, which has number 2
    • X means execute, which has number 1
    These permissions add up to numbers; 4, 2 and 1. You can configure permissions for the user owning the file, the group owning the file and the You might already see the link between what 777 means now. 7 is the combination of all permissions (4 + 2 + 1). 777 thus means that the group owner, user owner and nobody (anyone that isn't part of the group and doesn't own that file) can read, write and execute that file.

    This introduces a risk, commonly through PHP; payloads. PHP is one of those programming languages that doesn't compile; it resolves at runtime. This has the risk of some code being written, and it instantly being executable. However, being able to write a PHP file to a disk would be necessary in order to even exploit this. Thus, an initial exploit is necessary (write a PHP file) in order to execute the PHP file (chained exploit).

    Not using 777 permissions prevents this. You can't write and execute a PHP file if you can't write and execute it. Simple. When you look at my permissions above, none of them are 777. They're either 666 (read and write), or 555 (read and execute). I could even make this 660 and 550 for that matter. Generally, folders which only contain executable code should be made 550, which allows only reading and executing. Folders which have some kind of data storage (like a cache) should be made 660. It allows read and write, but not execute. This would prevent code being written and being executed. However, for that to happen, you need an initial exploit first.

    Luckily, XenForo is rock solid. They actually recommend 777, which I still don't recommend you to do. There is just no reason to. This is one example of an exploit chain; 777 is not directly a security risk, but if there's another exploit, chances are having 777 makes that other exploit ten times worse.

    Functionalities with faulty implementations
    I briefly mentioned this one in the first part. Let's look at the example of having a Minecraft server setup. Let's imagine we have some features, whatever it may be, and we have them enabled, but they're locked down behind permissions. A permission which practically nobody has.

    Now, since the last part was a bit boring, let's spice things up a bit. Holographic Displays. Quite a popular plugin. Chances are you're using it. Now, did you know that that plugin has a command which allows you to... read a file from the disk... in-game? Yes. Because that's exactly what a holographic plugin needs, right? No, but whatever, God knows why that feature was added. If you're the developer of Holographic Displays (and added that command) and you're reading this; you're an idiot, seriously.

    Here's what apparently went wrong. Look at this commit. Look at the commit message;

    "Restrict file reads to the plugin's folder"
    Read that again. Carefully. Think about what that commit just fixed. There was a command, that allowed you to read the contents of a file. And now, that command was fixed with "restrict file reads to the plugin's folder". In other words, that command could be used to read any file from the system, anywhere, before it was patched.

    Now, let's go a bit further into why this is problematic. Let's again take our example where we get Bungee'd (Bungeecord firewall hacked). Someone logged into an administrator account and has full permissions. Now, that hacker would have to a command which allows him to read any file from the system. Any file. It would allow him to read configuration files of other plugins, which could very well contain tokens or passwords. Passwords to databases, tokens to systems like.... you guessed it, DiscordSRV for instance.

    Next thing you know you see your server in a YouTube video, where not only your entire Minecraft server got hacked because he had full access to all files, but also your Discord server may have been hacked because he got access to a bot token which you had configured somewhere.

    Now, this could have been prevented in two ways. Approach 1; don't be an idiot. Don't add functionalities which literally are not necessary. Or, perhaps better in this case; implement your functionality properly. Why do you need to allow a user to read and write a file? To my knowledge, this was done as kind of a placeholder for servers that have lots of holographic displays. Why didn't the developer of that plugin simply make it so that the command would simply add a small piece of data in a config file somewhere? Then the functionality would've been restricted in a safe manner, and the functionality would still exist. The second approach to not having this happen is design a system (your Minecraft server) that's secure by design, but that's for part 3, 4 and 5.

    Functionalities which shouldn't exist entirely
    In case you thought that implementing a functionality incorrectly was bad enough, there's one case which one could argue is even worse; a functionality that's not needed entirely. And it's from a plugin that's also quite popular; LiteBans. Here's a snippet of the plugin page;

    /litebans sqlexec <query>: ONLY CONSOLE CAN USE THIS COMMAND BY DEFAULT. Allows you to execute arbitrary database queries, and allows you to view the results of these queries in table format.
    Why in the name of God does that command exist? How could you possibly justify allowing free, unrestricted database query access from within your application? Even if it's limited to purely the console by default, it's still an indirect exploit which can severely be exploited further if there's an initial exploit where either the console gets breached, or the feature was enabled in-game and you get Bungee'd. There are people who may have their XenForo installation in the same database. Congratulations, passwords, IP addresses, usernames, and everything else of XenForo leaked, including whatever else you have in that database.

    Such feature shouldn't exist entirely. It is completely unjustified to perform database administrative tasks from within an application. If you need to access your database, do it normally. SSH into your machine, connect to your database, do things there. Don't manage a database from within your application. That's beyond horrible practice and such command shouldn't exist as it promotes such mindset.

    Don't be naive in thinking premium plugins don't have this problem. According to this source, ChatControl Red, potentially also in ChatControl Pro, a premium plugin here on SpigotMC before the author got banned, apparently has a "feature" allowing those with the correct permission to read any file or classes, and dynamically get methods & fields of said classes. I don't think I even have to explain this one. Nobody asked for this feature. I wouldn't even call it a feature; he's opening the door widely for something security to go wrong, very badly. This one is even worse than the above Holographic Displays exploit; and that was one unintentional, this one isn't. An issue has been opened on Github, where you can track the progress to have it be removed entirely. The issue has since been solved, and the feature has been disabled on newer versions.

    These are the kind of things that amplify a simple small, even harmless breach into a large operation where not only the entire server gets destroyed, but people's data gets leaked.

    And with that, I want to ramp up three examples; the tip of the iceberg of what I call the exploit chain. Now, none of the above are guaranteed answers to why you got hacked, but I hope it explains how these kind of things happen.

    Secure by design
    While this is a topic I will cover in part 3, 4 and 5; systems can be secure by design. Let's imagine one of the examples above where someone got full read access to your server files.

    Now, how can we prevent your Discord token from being read by a hacker after gaining full read-access (through an in-game exploit)? Think about it for a second, then read the spoiler below.
    By not having the Discord token be installed there!

    You can't leak what isn't there. It may sound stupid, but think about it. You seriously don't need to have your Discord token be part of your Minecraft plugin configuration in order to synchronise some messages to a Discord channel. I will go into detail of how this can (and should!) work in part 5.

    Split functionalities up between different systems; different components. If everything is controlled from one system (in this case, a Minecraft server), you'd have massive damage if that particular system gets hacked. Let's imagine we have 20 different components for our Minecraft server, rather than 3. Do you think our hack was just as harmful if we had 20 components compared to 3? We can limit the impact of a breach in a system to just that system alone. From that point on, breaches which normally get your entire server destroyed, suddenly become almost useless.

    For my own project; Dyescape, I'm designing the majority of the system in such a way that even if you manage to breach in somehow, it would be pointless. I could give you console access (which, funny enough, I wouldn't even be able to because there is no console), and you still wouldn't be able to do anything. Why? Because there's not a single administrative command in-game. Maybe some moderation at best, but there sure as hell are no commands that allow me to read a file, allow me to execute database queries, allow me to ban all users, etc. You can't abuse what doesn't exist. Simple.

    An advice for the time being, without getting too complex or expensive; carefully read through the functionalities of each plugin. Carefully think to yourself; is this safe? Do I need this? Could this possibly be implemented incorrectly? If you're uncertain; ask! We have a forums for these kind of things. Disable features (and I mean disable, not hide behind a permission!) features which you don't need and may pose a security threat.

    And, as a general reminder, keep your stuff up to date. Someone I know got his server hacked yesterday through the Holographic Displays exploit. That exploit has been patched over 2 years ago. This wouldn't have happened if the plugin was up to date. Check for updates regularly; like, weekly, not only when stuff breaks.

    Hopefully this gives you an idea of how one, relatively harmless exploit, can result in severe damages just because the rest of the system isn't secure. Now, I do know that a fully ideal setup isn't 100% realistic to those who don't have access to the capacity of custom development. However, with this new understanding of certain exploits work, I hope that you'll at least be more careful of the features you have on your server. Disable those who aren't needed. And to developers; don't build functionalities incorrectly, or don't build them at all. Minimize the impacts of breaches by making your systems secure by default.

    And now is a great time to look back at the start of this part;

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

    Next up; Part 3; Identifying risks.

    Comments or suggestions are welcome.
    #1 MrDienns, Jan 22, 2020
    Last edited: Jul 5, 2021
    • Winner Winner x 7
    • Informative Informative x 6
    • Like Like x 3
    • Agree Agree x 1
  2. MiniDigger


    forgot to updated the nav

    one important stuff that should definitely be addressed is:
    Keep your fucking software update to date, always!
    The issue in HD is two years old, yet its still being actively exploited. This is bad.
    A good server administrator checks all his plugins for updates regularly. Like once a week or at least once a month. Not when there is a minecraft update or worse, just if something breaks. You check all the time or you are at risk.
    • Like Like x 2
  3. You're too quick, I already fixed that :p

    Precisely. I wanted to ideally mention this in parts further up, probably part 4, but it doesn't hurt mentioning it practically every part. I'll add it.
  4. You should also write about managing TCP ports and using keys instead of passwords for SSH authentication. I see people not paying attention to these things pretty often until it bites them back.
    • Agree Agree x 2
  5. Yeah, I'll write something about it. I'll have to see if I do it in this part. I want to keep the subjects for each part aligned.
    • Useful Useful x 1
  6. Andre_601


    From my understanding is that file-read thing because of custom animations, which are stored in separate txt files within an animation folder of the plugin.
    So HD somehow needs to read the content of those files. Just restricting it to a config could make it looks worse than it needs to be.
  7. Yesh, part 2 is out.
  8. How would it look worse? Just specify the animation in a YAML file for instance. Could write it to an animation specific config file. But just allowing you to specify the file from the commandline is bad practice, and this exploit is why.
  9. Andre_601


    Personal preference tbh.
    I appreciate having the animations separated into different files than having a long list of multiple entries where I have to follow the syntax exactly, because YAML.
  10. Sure, I can understand that. Though still, the feature should at least try to parse a file to it's expected result rather than just plain text reading the file and dumping the results, because that's asking for problems.
  11. "Pivoting" or "lateral movement" are the actual terms
    • Informative Informative x 1
  12. Suggestion ...
    Please, do spell check, and grammar check your articles in English (USA). (As I have noticed several errors which can lead to mis-understandings.)

    Whilst these checks are not perfect at their job, they will help both yourself and your readers.

    Thanks for your work with this thread.
    • Optimistic Optimistic x 2
  13. This is a proper way of writing a guide. You nailed it. Thank you so much, this was a much better guide than LinsaFTW and Sammwy. Well done. I love the introduction you did. It's better to be aware of what's happening so the issues can be resolved easier. This actually goes into depth, respect to those who actually know what security is and not just say "security" is using a bunch of plugins to secure yourself. People don't seem to realize there's more exploits than plugins preventing these from happening. But, I do want to mention something about Holographic Displays. In the older versions of the plugin, you are able to do /hd readtext and read any files from any directory as long as you have the permission for it. This ends up people who gain op to gain access to people's databases and view any file they like. There is a line limit though, but an exploit is still an exploit. This was patched in the latest version. In the latest version, you are only able to read files in the holographic display paths. Unfortunately, a lot of servers still use the older versions. Loved how you touched upon the discord bots/tokens. Litebans was also something that not a people know about. I'm glad you brought that up. That litebans command is dangerous because it can export all IP addresses that was logged in the server. This guide not only gives a clear introduction of how security and exploits, there's actually labels, so people can understand what's going on and where to look. Towards the end, you made a excellent point. Regardless of a exploit is small or big, it's still consider a exploit.
    #13 ExtremeSpirit, Jan 28, 2020
    Last edited: Jan 28, 2020
    • Friendly Friendly x 1
  14. foncused

    Moderator Patron

    Any thoughts on adding a section on social engineering? Your guides seem to be heavily focused on technical design, which is completely fine, but it is only a piece of the puzzle. Often (arguably, most often) the weakest link in any security chain is the human element and its vulnerability to manipulation (think Kevin Mitnick). I am sure this is not excluded from the Minecraft community (rudimentary example, "I am from ___, and am interested in reviewing your server - may I have OP?").
  15. +1 for this

    I do infosec courses every now and then, in the first one I ever did, one of the things I still clearly remember the instructor (a pentester by trade) saying "If social engineering is allowed in an engagement, I will use it, 100% of the time" and "All of my engagements where I've used social engineering have been successful"
  16. foncused

    Moderator Patron

    Right, just don't be John McAfee and say we can social engineer the decryption keys out of an iPhone. :)
    • Funny Funny x 1
  17. Yeah of course - I think the point was that in a situation where a person who isn't a security expert can easily give you access to something, chances are you'll be able to get access to it.

    In John Mcafee's case, yeah not too likely that any apple employee has easy access to your keys
  18. Social Engineering works only to those who don't take the time to do research on whether or not it's a fraud. In my case, I will never give access to my personal information to anyone until I am 100% sure they are who they say they are. Although, I have heard of several cases where this has worked in the past and even some of my friends fell for this at this point. What's difficult about Social Engineering is in order for this to work efficiently, the person must be very convincing. Manipulating someone into giving you information will not always be so easy, it depends on who the target is. Phishing is one of the most common types of Social Engineering along with Vishing. Reminds me of people saying they are from Planet Minecraft and they need operator access to review the server. That doesn't really work anymore, but in some cases yet, if they are new to minecraft it might work. I do agree however, that people's will to give in to other people's demand with manipulation is quite often. I do agree that Social Engineering would be a nice addition to add here. Good points.
  19. I think I'll cover this in part 3; identifying risks. Giving people you don't know (well enough) certain permissions in a risk, so I can add it there.
  20. MiniDigger


    I work for an insurance. The pen testers didn't even take a hour to get domain admin.
    How? The found some old user id with the default pw (so never used) and called the IT helpline to activate the account and to "restore" access to domain controller.
    I laughed so hard in their presentation, my boss looked angry at me.

    Point is, social engineering is super easy once you found a weak link. This is easier, the bigger the company gets, but it also works for servers.

    For example, saying you want to help a server with performance, writing a malicious plugin, uploading it to spigot so it seems save and making the owner/admin download it. Stuff like that is super easy.
    • Agree Agree x 2