.svg "2024_Full_Logo_Full_Color_SVG (1)"){kind=logo}
Why Bother with Video Game Security?
Video games are more than just entertainment. Gaming is a massive industry which by some accounts is estimated to be worth $256.97 billion by 2025. So in terms of sheer market value there are a lot of reasons (256 billion of them) that companies would want to invest in the security of their video games and the supporting systems that go along with them. But there are some more nuanced reasons as well. Reasons why an insecure (multiplayer) video game can impact the stakeholders bottom dollar, the players experiences, and even in some cases the player’s personal information are enumerated below.
Reduced Player Base
Rampant hacking in an online game which depends upon an active player base to sustain revenue can lead to many players simply becoming frustrated with the state of the game and opting not to play it. This could also lead to new players choosing not to take up a certain game.
Competitive Cheating
Several video games these days have thriving competitive communities surrounding them. These events can generate a lot of money for those involved. From the game developers through new sales, competitive players through sponsorships and prize winnings, advertisers and event holders, and likely more. If a game can be hacked to allow players to cheat to get a competitive edge with things like aimbots and wall hacking then the competitive nature of the game is diminished.
Theft of Player Personal Information
Many games today contain access to a lot of information about a player. The biggest threat to personal information loss is through third party services that the game can integrate with. These systems could expose access to player email addresses, and even credit card details through various means. When an application interfaces with other systems it becomes a potential vector through which to access those systems and the data therein.
Increased Attack Surface
As with any networked software, multiplayer games and their supporting systems create additional attack surface for an organization and its users. In the worst case scenarios, a vulnerable game client could be used to gain code execution on a player’s computer, and exploitation of vulnerable game servers could lead to breaches of a company’s network. All of the same reasons that you would and should care about securing your web apps, native apps, APIs, and mobile apps also apply to securing multiplayer video games.
Accessibility of Game Development Tools
Game development knowledge and tools are more accessible today than ever before. I mean basically anybody can churn out a low quality game in a relatively short period of time. Just browse steam and you’ll see just how many people are trying to make games.
This poses an interesting conundrum for the security of games. Many small indie developers are solo dev shops or likely can’t afford dedicated security personnel. Yet there are a ton of small multiplayer games out there. It’s important not only for large development studios to be educated on information security best practices, but also for the small indies out there just trying to bring their ideas to life. While a smaller studio might not be able to afford regular penetration testing, putting the knowledge out there for them to be educated and aware is just as important.
There are certainly more reasons to secure video games than I care to list here. But I’m sure you get the idea. An insecure video game can impact the bottom line for stakeholders and can potentially have a negative impact on the users, depending upon the nature of the vulnerabilities and the systems and data that the game interacts with.
In this blog post series I’m going to walk through the process of pentesting a multiplayer first person shooter game and discuss some of the security measures that should be employed by game developers in order to mitigate vulnerabilities and their negative impacts in multiplayer video games.
The Tutorial Stage
For this blog post we are going to be hacking on a version of the Unity FPS Sample project that I’ve modified to be deliberately vulnerable to a few common security flaws that can be found in video games. You can find the original sample project here – https://github.com/Unity-Technologies/FPSSample. I will be providing a compiled client and server build along with the second post in this series for those of you that want to follow along.
A Little Lesson on Server-Authoritative Game Architecture
Alright, so how do multiplayer games even work? Good question, there are a lot of ways in which two or more players can play together over a network. The main ones are….
Dedicated Server
In this network architecture the game clients all connect to a central server which simulates some or all of the game logic. In a fully server-authoritative setup the client is only responsible for rendering graphics, playing audio, and sending player input to the server, which then responds with a new game state that the client uses to update the presentation.
Client Hosted
This is a technique that is more commonly used on consoles in which one player is the server as well as a player. This has some benefits for developers in terms of saving on infrastructure costs as there is no need to host and maintain expensive dedicated servers. However, there can be lots of negative impacts to the player experience:
- Higher lag due to all player connecting through what is typically residential internet
- Possible play advantage for the player deemed as the host
- Weaker security model as the server is run within a client device
Peer-to-peer
This type of game network architecture is most commonly seen in real-time strategy games and requires that every peer send and receive data from every other peer, trusting that it hasn’t been tampered with. This is largely due to the need to often simulate a large number of entities in the game and it’s difficult and time consuming to keep the state synchronized among multiple players. Because of this, instructions to the clients are typically replicated back and forth between peers and the game state is updated locally on the client using those instructions.
We’re just going to focus on a version of the Dedicated Server model with dubious client-side prediction and data validation. Remember, they’re not bugs, they’re features 🙂
Equipping Our Loadout
In order to discover, analyze, and ultimately exploit the security flaws present in this game we are going to need to enlist the help of several awesome tools to do so. In this series we’ll be using the following tools:
- Wireshark – capturing traffic for initial analysis
- Scappy – automation of network level attacks
- dnSpy – .NET assembly editor for cracking open the game (has Unity support)
- (maybe) Ghidra – A general purpose reverse engineering tool to have in our back pocket, just in case
Queuing Up
So, that was a pretty brief introduction to what this series is all about. Stick around for the good bits in the coming weeks / months (this series is an ongoing effort on my part). Follow me (@84d93r) and Secure Ideas (@secureideas) on Twitter for updates and all that good stuff. Also check out my vulnerable MMO project, DVMMO, and follow its development if you’re interested in Game Development and Information Security! Catch you later 😀