Just For Fun: Hacking Your Minecraft Server

WARNING: If you don't play Minecraft, administer a Minecraft server or have a kid who does, you probably want to stop reading right now. This is going to get nerdy and technical very, very fast!

Okay, so this has absolutely nothing to do with information security and everything to do with what happens when your son comes to you with a “huge” problem... Like a lot of kids his age, he is hugely addicted to playing Minecraft and his addiction doesn't stop with just playing the game. He has been running his own Minecraft server (currently CraftBukkit 1.52R-1.0 deployed on Ubuntu 12.04LTS) for nearly two years now and experimenting with just about every server extension (“plug-in”) you can imagine. For my part, I have supported his Minecraft addiction by giving him hardware, teaching him some basic Linux skills and helping him debug when things didn't go as planned.

About a week ago, my son, enterprising young man that he is, determined that he would solicit donations to help defer the cost of running his Minecraft server. In exchange for real world monetary donations, he would award the donating players virtual currency with which they could purchase enhanced permissions and other virtual goods within the context of his Minecraft server.

In order to accept real-world monetary donations, several things were needed. First, he needed a PayPal account. No problem there-- I hooked him up with that. Next, he needed to create an “economy” on his Minecraft server that allowed players to have accounts with monetary balances and to buy and sell things, exchanging virtual currency in the process. For this purpose, my son deployed the BOSEconomy plugin. Once he had the economy plug-in working, he needed the ability to modify user permissions, so another plug-in was needed: enter PermissionsEx. Finally, to accept donations via PayPal and translate the real-world donations into virtual currency, he deployed BuyCraft.

After a couple of hours of work, he had things working. One could donate real money and receive virtual currency on his server. At this point, there was just one problem: How can people who donated money spend their virtual currency? My son had an idea: Create a few little booths to allow players to choose what they want to buy (typically enhanced in-game permissions) by pressing a button. Command blocks, activated by the button, would then award the item to the user and decrement the users account balance.

Great idea, but then he encountered his “huge” problem. Command blocks can only be configured to take a series of actions: add the permission, take the money... with no logical dependency between the actions. Since BOSEconomy allows negative account balances, the net effect was that users could "buy" anything regardless of their account balance. They could run an unlimited negative balance, sort of like the U.S. Government, but without fear of negative consequences. Unrealistic, right? Even though a lot of American politicians don't seem to think so, my son does. And I happen to agree. So when he asked me to help him fix it, I thought, sure, why not?

So, we wrote a custom Java plug-in that corrects that problem by guaranteeing that users have a balance sufficient to pay for the item they are purchasing and, if not, disallow the purchase. How did we do this? By using the Bukkit API and integrating the APIs of BOSEconomy with PermissionsEx with some custom Java code. We called the resulting plug-in cmdShop and you can see the results here. We tested with craftbukkit 1.5.2R1, BOSEconomy 0.7.6.3 and PermissionsEx 1.19.6.   

Feel free to use the code as a template for your own plug-in.  Of course, you will need a Java development environment and various other bits and pieces...  And, if you really need someone to hold your hand (like I did, LOL!), there is always this video and several others like it to help you get through the process.  Yes, they were probably made by a 12-14 year-old kid... but they aren't half bad!  (And, yes, I feel super old right now...) 

Some other good resources are:
Bukkit Plugin Tutorial
Bukkit API Docs
Buycraft
BOSEconomy
PermissionsEx

Ubuntu Linux: Improving Privacy and Reducing Attack Surface

For the past several years, I have been a big fan of and advocate for the use of Canonical's Ubuntu Linux distribution. It is fast, reliable, easy to use and rock solid. I have installed Ubuntu server and desktop versions on laptops, desktops and servers both at home and in large data center environments. I have never regretted this choice even once.

Because I value stability, I typically favor the Long Term Support or LTS versions of Ubuntu which are supported for five years after the release date. Because most of the features I need are found in the very stable 10.04 LTS version, I only recently to upgraded to the 12.04 LTS version. Unfortunately, I quickly found some things in 12.04 that were not pleasing to me. While some were easy to fix (like getting rid of the Unity desktop), some required a bit more investigation.

When I install a new operating system, I like to understand what the “normal” network activity for the operating system looks like after the normal boot cycle and as I use the system. I like to understand during the normal course of operation what network services my system is communicating with and the nature of those communications. Call me paranoid if you want, but knowing what “normal” network activity looks like and being able to explain how that “normal” activity may impact my privacy seems only prudent. As it turns out, Ubuntu 12.04 LTS contains a number of features that seek to enhance the user experience but at the potential expense of user privacy.

Probably the most dangerous in terms of privacy is the zeitgeist application installed in 12.04. According to the zeitgeist documentation, “zeitgeist is a service which logs the user's activities and events (files opened, websites visited, conversations held with other people, etc.) and makes the relevant information available to other applications. It serves as a comprehensive activity log and also makes it possible to determine relationships between items based on usage patterns.” The information collected is stored in a subdirectory of the users home directory and is available to other applications via either the Zeitgeist API or via the Dbus API. No technical restriction is placed on how those applications consume this data or where this data goes once it is consumed by an application. The dangers for abuse here should be obvious. We can protect ourselves from this potential abuse by removing zeitgeist and purging the data that has already been collected in the user directories.

Another danger to privacy not at all unique to Ubuntu or other Linux distributions is the danger of memory contents containing potentially sensitive information being sent outside the organization through crash database submission programs. In Ubuntu, the crash database submission program is contained in a package called “whoopsie”. A good description of how whoopsie works can be found here. Not every crash results in the submission of a memory image, but if one is submitted, it could potentially contain sensitive memory contents. If you are using a stable release such as 12.04 LTS, your need to run this package should be very minimal. By removing the whoopsie package, the potential to transmit sensitive memory contents outside the organization is eliminated. If you find that you need crash submission functionality at a later date, you can manually install the package and remove it once the problem is solved.

After these issues were solved, I noticed two IP addresses that frequently had persistent open TCP connections from my system. These IP addresses were 91.189.94.25 and 91.189.89.144 which correspond to mulberry.canonical.com and mistletoe.canonical.com, respectively. Using the command netstat -pnt, I could see that the process opening these connections was the ubuntu-geoip-provider. That makes sense since these machines also have a DNS record that maps the IP addresses above to geoip.ubuntu.com. But what are these connections? And why are the persistent? And what data is moving across them? As it turns out, this process is part of a GeoClue implementation which as been integrated into Ubuntu (and several other Linux distributions).

Some investigation reveals that GeoClue “is a modular geoinformation service built on top of the D-Bus messaging system. The goal of the Geoclue project is to make creating location-aware applications as simple as possible.” Essentially, through these persistent connections, you are allowing Canonical's servers potentially to track your geographic location. That may or may not be a bad thing, but you as a user should know and have the opportunity to determine how you feel about it and adjust settings accordingly. Unfortunately, Canonical has not made this easy nor to do they call attention to the fact that this is happening at all. Worse yet, they don't make it easy to remove the packages containing this feature as there are several reports stating that various features of the Gnome desktop were broken on removal. What is a guy to do in this situation? Easy answer: block network communication to these IP addresses using iptables (a firewall implemented by the Linux kernel).

As a last measure, if we are going to configure iptables to block outbound geo-ip traffic, good security practice also dictates that we harden our host and allow only inbound traffic corresponding to services we actually need. Most people need, at a minimum, secure shell (SSH) so we will start with just allowing SSH inbound. Also, we will add a rule to disable IP forwarding so that we don't inadvertently become a path for others to use to forward malicious or unwanted traffic. By doing these simple things, we have dramatically reduced the attack surface or our operating system for any external attacker.

So, now that we know what we want to do, how do we do it? Again, it is simple. Download the pangolin-lockdown-utility script.  First, read it to understand exactly what it does. All of the actions are clearly explained in the comments. Once you are comfortable with it, you can execute it as is or modify it to create additional inbound rules, etc. If you execute the utility as-is, you will have a system that limits inbound traffic only to SSH, restricts outbound geo-ip traffic, turns off IP forwarding, doesn't transmit potentially sensitive images of memory outside of your organization and doesn't track the files you open, conversations you have or websites you visit. Seems like a vast improvement to me. But, hey, I am the paranoid one, right?

Googdiff Updated

Quite a while ago, I posted a utility called googdiff which helps you monitor your online identity or the online identity of your business as revealed by Google’s front page search results, helping protect you from so-called “Blackhat” Search Engine Optimization (SEO) “consultants”.  

Due to some changes in the format of Google's HTML output, the original version I released had stopped working.  A couple of small tweaks were all that was required to fix the problem and I have posted an update here.