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; Part 1; Awareness Part 2 The exploit chain (current) Part 3; Identifying risks Part 4; Reducing risks Part 5; Preventing risks 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. 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 X means execute, which has number 2 W means write, 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. 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. Spoiler: Answer 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, reaches 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. Advice 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. Summary 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.