Hacking Computer Games

For this blog post I’m going to explain where the password list came from that I tried cracking on a train, which presents a cautionary tale about how to be careful about how things can easily go awry.

Confession time

First off I need to make a bit of a confession: Although I’m nearly 40 I still like to play computer games on a regular basis. I’m not talking about X-Stations or Playboxes (or whatever else they’re called). I game on a PC, with a mouse and a keyboard. Proper old school fashion. So imagine my unadulterated joy at being assigned to test a bunch of games!

PC gaming has gone through a bit of a sea-change in the past few years, as the AAA titles are mainly being created for consoles, then a gods-awful port is created for the PC. This combined with the fact that Internet connections are cheap, fast and common mean that there has been a resurgence in the indie game market.

So, this means that the game industry has gone back to those heady days in the 1980s where scores of coders are writing simple, cheap games in their bedrooms.

But, there is a problem with this, which the most observant may already have seen: you have a host of coders writing stuff which is then distributed to a large number of game players; but, there are no centralised QA or code review processes to ensure thing like the security of the games are taken into account.

This would not always be a problem, except the world is into social media: Internet based high score tables, achievements and dribbling about your position on Bookface are currently in vogue. This means that we are in a state where:

1. Games are written by people who don’t necessarily understand secure coding
2. Games are cheap, often bought in bundles, so a large amount of people play them, even briefly
3. Games talk to places on the Internet and need to identify users

Cautionary Tale

Here’s the background to the job. Once upon a time some college somewhere in the US wrote a game as part of a project. Through a selection of twists and turns this games turned out to be better than expected and became a commercial offering.

At some point the concept of an online scoreboard was mooted and was coded by members of the team, this was added through a direct method that worked well: a direct connection to a MySQL database.

The game then got released through Steam, when it first started pushing independent games, way back in 2010.

Years pass and the MySQL database that stores the scores and the username gets expanded for other purposes, such as storing the configuration for a wiki. The project team also go the same old way that college people go; divisions occur and people fall out of contact.

At this point an intrepid security consultant is hired to review the game before it goes through any more iterations. Of course he plays the game first, and plays it whilst wireshark is running in the background. Noticing the connection to MySQL he gets digging…

A quick analysis of the main executable leads us to a server, username and password (redaction has been performed to protect the guilty):

From here we could see:

1. Server (outlined in green)
2. Username (outlined in blue)
3. Password (outlined in purple)

Also of interest is the SQL, the most interesting bit being the query to get the password:

At this point, the pen tester’s spidey senses start tingling; there’s an implication of an unencrypted password here.

So what did the consultant do next, well he connected to the database using the credentials in the game and found to his delight some plain text credentials (again redaction has been put in place to hide information that could be identifiable):

Of more interest were other databases that were in the MySQL server, which included a table of usernames and hashed passwords, with email addresses. There’s no screenshot of this as I’d have to redact virtually everything.

The outcome

Following this I had a good chat with the game’s author which resulted in creating a patch; moving the MySQL server to a dedicated instance and hashing the passwords with the MySQL password function, to protect from any curious script kiddies.

Although this is not a perfect solution (see my previous post for why), it stops trivial cracking.

Learnings

So, what can the world of indie computer games do to stop their user’s credentials being open to anybody with a text editor and a MySQL client?

• Never connect directly to a database over the Internet.
• The biggest single item is to ensure that you understand the security implications of any communication that you have in place. If you don’t have the necessary tools within your team, contract out, or use a third party library that has had a level of security testing. Never roll your own unless you know what you’re doing.
• Never connect directly to a database over the Internet.
• Future proof your design; just because you have access now does not mean that will happen in the future.
• Never connect directly to a database over the Internet.
• Separate your endpoints by function to prevention sideways escalation.
• Never connect directly to a database over the Internet.

For the user: don’t create user accounts if you don’t need to, if you do, create a throwaway account with a one-time password and email address. Either that, or use a password vault. This means that a compromise of some game you played once 4 years ago does not cause your email account to be compromised.

Also, never connect directly to a database over the Internet. I may have repeated this a bit, but it is vitally important and yet more famous games still end up doing it, like the Super Meat Boy fiasco in 2011.