2
\$\begingroup\$

Consider a relatively small multiplayer game server, written by an individual or a small company. Some malicious user wants to boost their character stats by a factor of 100.

What paths of attack might they have and what are the most important safeguards to prevent these attacks?

\$\endgroup\$
  • \$\begingroup\$ I've edited the question to focus it more strongly at game development, rather than at compromising a specific kind of server. This should at least steer it toward on-topic. Of course, edit more if you think it's needed. \$\endgroup\$ – Anko Jun 4 '13 at 8:47
  • 1
    \$\begingroup\$ Good edit @Anko. Still, now the question is off-topic for other reasons, you can imagine write entire books on that subject, which is hardly the scope for practical question here. Still voting to close for that reason. Lisa, please read the FAQ for details on what questions to ask here. \$\endgroup\$ – Maik Semder Jun 4 '13 at 8:53
  • 1
    \$\begingroup\$ The unfortunate part about this question is that it's almost as broad as "How do I make a game". It is incredibly dependent on so many characteristics of your game and the platform it operates on. Difficult to give a real answer I would say. The biggest reason is that for every general purpose preventative measure developers take to prevent such actions, there will almost always be someone that finds an alternative if they care enough. \$\endgroup\$ – Evan Jun 4 '13 at 12:41
  • 1
    \$\begingroup\$ I would argue that a sufficiently useful overview of common attack vectors and defenses could be given to make this question - and its answer - useful. The answers so far aren't quite up to par, though, IMO. \$\endgroup\$ – Sean Middleditch Jun 4 '13 at 17:00
14
\$\begingroup\$

Attack vector 1: The netcode

As already pointed out by Mario, one important factor when designing the network protocol of a client/server application is to not blindly trust the client. You can't control the software which runs on the client machine. You can't even tell that it's your software and not something the user programmed themself. The same limitations apply to anti cheat software. They can't do anything you can't do yourself to prevent hacking your client software. So make sure that the server doesn't allow the player to do anything they aren't supposed to do, like setting their stats to any number they want.

Treat the network input of the client like you would treat the user input on a GUI. Would you make the number fields on the character status screen editable, allow the user to put in anything they want and then go with it? Certainly not. So why would you do that on the server?

Attack vector 2: The database

Most games use SQL databases as backends. Whenever you use an SQL database and deal with data provided from an untrusted source, you have to be weary of SQL injections. This is a common mistake many people make when using an SQL databases and which allows users to do anything to the database they want, including deleting and altering records. Fortunately it's easy to avoid by following some well-known coding practices like prepared statements, ORM wrappers or stored procedures.

Attack vector 3: The infrastructure

The gameserver might run on an operating system which might not be configured for high security, not be behind a properly set-up firewall and might not have the latest patches. This can make it vulnerable for os-level exploits allowing remote code execution or unauthorized logins. How to properly secure a server on the OS level is a topic for http://security.stackexchange.com and/or http://serverfault.com.

Attack vector 4: The human factor

But the biggest security hole of all is always the user.

All other security measures are worthless when an attacker acquires the password to a GM or admin account.

An attacker could use social engineering techniques to impersonate staff members and claim that they forgot their password. They could use spear phishing to trick staff into revealing their passwords or they could trick staff members into installing keyloggers.

The only countermeasure against this is to educate all staff members about proper security practices.

Some of your staff members could also be susceptible to bribery or blackmail (or just be idiots), especially when they are unpaid volunteers from your community. This problem can be partially mitigated by 1. having a rigid code of conduct explaining what a staff member can and can't do in a certain situation and 2. properly log all admin actions making it impossible to abuse privileges without you finding out.

\$\endgroup\$
4
\$\begingroup\$

Another interesting question where I can cite that awesome quote I've found on the internet a few years ago regarding the creation of multiplayer games:

The client is in the hands of the enemy.

Whereas the enemy is the player trying to cheat or "hack".

Overall, there's no 100% perfect way to avoid hacking, cheating or botting.

One of the easiest way to avoid such issues is - as said in the quote - to never trust the client.

Neverwinter Nights 2 offers a perfect example for this. It had horrible net code. I helped running a roleplay server a few years ago and it was really, really hard to do so right after the first expansion has been released. What happened?

Account creation in Neverwinter Nights 2 has been (not sure it's been changed) the perfect example of how not to do it. Just to note, the game offers two different modes of multiplayer gameplay: Either characters saved on the local player's machine or characters saved on the server. The first approach allows easy cheating, so we didn't use it. However, the second approach hasn't been a lot better:

At account creation, the game created the character and uploaded it to the server. That doesn't sound very secure and it isn't. In fact, this caused quite some unintentional issues. If an expansion player created some character with expansion features and logged into a non-expansion server, the server couldn't handle that suddenly "invalid" character data and simply crashed.

What should have been done instead is something a bit different: The client should tell the server what to create. But in the end the server determines how/what he creates and whether it accepts the parameters given. This is how pretty much any modern MMORPG handles its character creation process and other mechanics. If you still happen to pass some invalid value, you'll just receive an error message rather than see your character being created with invalid stats.

As you specifically asked to magically gain 100 points of some attribute or anything like that: If done right, there's nothing you can do without having access to the actual server. If all calculations (like damage) happen on the server, you simply can't influence or modify them.

Something like the injection you mentioned can have some - but at most minimal - effect based on how the game is written:

Let's assume upon login, the server sends the client some data package "permissions". This will tell the client what the player is allowed to see, for example spawn points or transitions usually not visible to the player. Using traffic manipulation, you could use a program to modify that package so the client thinks you're actually allowed to see that stuff (for example), yet this won't change how you appear to other players or the server (because that data should be verified by the server before being accepted and/or passed on).

\$\endgroup\$
  • \$\begingroup\$ Have you any link where injection is well explained for beginners? \$\endgroup\$ – Lisa Ann Jun 4 '13 at 11:00
  • \$\begingroup\$ Not right now, although it's essentially like catching some snail mail, using some white marker and changing some word or number, then passing it off to the initial recipient. \$\endgroup\$ – Mario Jun 4 '13 at 11:08
2
\$\begingroup\$

Ok, I can tell you that I had access to the opensource wow server code, and the worst thing for me was fixing the loop holes which gave some not "noon programmers" the ability to manipulate packets, the unofficial opensource servers have thousands backloops and they do not check the packets. On contrary I am sure that you wont do any harm to anyone, because an advanced skill in programming to do such stuff. And in the question you haven't mentioned networking which is all about handling packets. That is how wall hacks work, speed hacks if the server allows something and it will not have a bottlecap of some sort, there is no reason why the hacked client shouldn't send 10x more packets that are responsible for player forward movement. So in this case the player would be able to move 10x faster.

Keep in mind, that tinkering with somebody's server will get you into trouble. In the civilised world you are not allowed to do harm or manipulate data without the owners permission. (Applies to DDOS attacks too). All the incomming packet data, that exceeds the norm is logged in 95% of sittuations. And the player who does that gets a permanent ip-ban.

Search google for "packet manipulation methods".

Still, if somebody wants to go work as an "anti hacking programmer" this is the perfect way to learn about it. And never do it on somebody's server because I can tell you that it is extremely hard to avoid getting your actions logged. If you do it on somebody's server you will most likely be banned from the server and you might even get a real life "ban"...

\$\endgroup\$
  • \$\begingroup\$ Thank you for your answer, Mikolaj. Before accepting your answer, what can you tell me about the following topic (which I guess is related to the main one): I heard about something called "injection" that is like extracting games' "parameters" and modifying them. Is it just a rumor? \$\endgroup\$ – Lisa Ann Jun 4 '13 at 9:03
  • \$\begingroup\$ breakthesecurity.com/2010/12/… \$\endgroup\$ – Mikolaj Marcisz Jun 4 '13 at 9:34
  • \$\begingroup\$ I do not know about it. \$\endgroup\$ – Mikolaj Marcisz Jun 4 '13 at 9:37
  • 2
    \$\begingroup\$ Just to note, the typical wall hack changes how walls are rendered and/or renders additional hints based on data already being on client side. Wall hacks usually don't modify anything on the networking side (they might use incoming packets to get their data though). \$\endgroup\$ – Mario Jun 4 '13 at 10:18
  • \$\begingroup\$ There are two types of wallhacks Mario, a wallhack that makes you see through walls, and a wall hack that makes you walk through them. Haven't noted that, sorry for leaving that part. Though the most common one is the x-ray \$\endgroup\$ – Mikolaj Marcisz Jun 4 '13 at 13:38
0
\$\begingroup\$

There are a few attack vectors to consider here, not just those with the intended effect (some malicious player wants to boost their stats) but also other effects as well.

As the other answers have eloquently put, never unquestioningly trust the client. Because there is no way to tell on the Internet what has happened to your client (if there is a bug in the client or the network, if the client has been modded, or even if it is your client at all), a server must always sanitize a client's inputs, making sure they are plausible and correct, before using them. There are several aspects to this:

Keep the network out of it: As much as possible, encrypt all of your network communications using SSL certificates and individual symmetric keys for each client. That way, when you receive messages from a client, you can at least know that they are unequivocally that client and that their messages have not been compromised by the network. (You still can't usually trust the client, though, but it is easier if they can trust you.)

Make sure that the API you provide to clients is exactly and only what they need: For instance, do not provide a call on the data server that updates a character's stats directly. Instead, provide simple, normal game actions to the client, and allow the server to calculate when stat changes should happen.

Make sure that the calls to your server/receiving client APIs make sense: You should first make sure that a message received from a packet corresponds to a client API call at all (and thus have a data format that allows you to verify this), then make sure that the arguments provided make sense and that it makes sense for the client to make this call at this time. For instance, a player who doesn't have a shotgun should not be sending calls to fire one. (NOTE: Many higher level netcode APIs in consumer game engines like Unity and Unreal will check if incoming messages match one of your expected message types, but will not check the contents for you.)

Enforce all prerequisites: In general, if any part of your code ever makes any assumption about the arguments, you should already be enforcing those assumptions with assertions, which will safely terminate your program if they are not met. Whenever you receive any network messages, you are guaranteed very little about their contents, so at that point you should ensure that the network message meets all of the assertions in all of the code in which it will be used (which is probably your entire code base).

Beware of DoS attacks: If a rogue client can't get their way, they can just take the server down with them and ruin it for everybody else by simply overwhelming the server with faulty packets. You can never perfectly safeguard against this, but you can increase your tolerance for it by simply refusing to honor requests that are sent from the same client too frequently.

Secure your server in other ways, too: Keep in mind that there are other ways to access your game server for administrative purposes - for instance, you might use SSH or Remote Desktop to log into it and fix things, or it may contact a data service. Be sure that those channels are secure, too, because an attacker may attempt to compromise your server by going through one of these backdoors.

If all else fails, keep good backups and logs and allow user reporting: If you cannot prevent a rogue action, a good backup will allow you to roll it back with little to no collateral damage. Also allow players to report the condition, and you can read the server's logs to investigate what happened, find the cheater, and act accordingly. (Be sure to keep your reporting system secure, too!)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.