Content

Web-Based Games: Playing to Lose

One common way of attracting visitors to a web site is to make it look attractive by incorporating animated graphics and interactive features written in Java, Flash and other common browser plug-in programs.

Some go a little further to make the site 'sticky' and provide games for people to play. Others have extended the concept and run competitions based on these games.

In 99 percent of cases, the organizers have to rely upon the score being provided from the game itself and whenever this happens, the game is wide open to abuse. Indeed, there are sites that specialize in detailing which games offer the best prizes and how the scoring works. This article outlines examples of sites at risk and some of the techniques in use.

Posting the score

Most web-based games involve some form of client software that the user downloads, most commonly written using Macromedia's Shockwave Flash technology. The game is played upon the user's system and information is sent back to the server, commonly in the form of a HTTP request that adheres to the configuration of that user's system, e.g. if the user's system is configured to use a proxy, it will go through the proxy, which makes the game vulnerable to fraud.

A good example is the Shockwave Flash Peeball game at www.peeball.com. The prize for getting the highest score is a DVD player. Although most hackers will by now have a system with a DVD drive, a DVD player is always welcome as a saleable commodity. The Peeball game uses a standard HTTP POST to submit the user's final score and details for the high scoreboard. On a Windows system, this adheres to the standard internet options settings. By using a man-in-the-middle proxy such as Odysseus, it is possible to modify the submission before it's sent - effectively allowing you to set the score of your choice.

However, this in itself is not enough. By playing the game a few times, it is easy to spot that all valid scores are multiples of five. Submitting scores that follow this convention makes it difficult to argue that someone cheated. But surely the organizers would think something is odd if a submission makes the top of the high score table and nothing else? So if he's smart, the attacker can easily write a quick script that slowly creeps up the scoreboard. The attacker then appears to have played a series of games where the scores aren't on the table, then starts at the bottom and moves slowly up. This would be difficult to dispute unless the winner was asked to demonstrate his or her 'peeball skills' - which doesn't prove that the 'contestant' couldn't reach that score anyway.

What about games written in Java that use standard socket calls? As such these would be much more difficult to proxy through. Using a sniffer such as Ethereal or Sniffer Pro, attackers can isolate the requests that are made, reverse engineer what is happening and submit their own request. This is more difficult when done over SSL but are you really going to provide an SSL certificate just for competition results? The same can apply to any protocol. Add to this the fact that both Java and Flash games are trivial to decompile and that binary executable-based games can be disassembled and no one could blame you if your site never used competitions again.

Game abuse is combination of two factors: the skill required to abuse the game and how useful the prize is. Would a hacker reverse engineer a custom protocol for a baseball cap? Probably not. Would they do the same for a holiday for four to Las Vegas at around the same time as the hacker conference, DefCon? Definitely. It's also worth taking into account how much the prize is worth. A few free cinema tickets hardly warrants the extra cost and time involved in securing a competition game, but an all expenses paid round-the-world trip could end up with all kinds of embarrassment to an organization, or even the cost of court cases, should the prize be disputed.

Making sure the right person wins

The only real solution is not to trust user-submitted information. By all means accept it but don't trust it, and instead try to validate the authenticity of that information. Consider the following situation:

A fictitious company, SimianTech, is struggling to sell copies of its poorly implemented home PC firewall software. So it runs a competition in order to generate interest, where the first prize is an all-expenses paid trip to Disney World. Unfortunately, they're using a badly designed Flash-based game and the winner is determined by the highest score. SimianTech suspects foul play when the competition is won at the last minute by a new player, 'z3r0 kl00' who scores 31,337 points. Is this genuine, or is it an attempt to cheat?

In this case you have to rely upon the scores being submitted back to the server either at the end, or throughout the game. The important thing is to confirm whether or not the high score is genuine. The first check is the score. If the score is unrealistic, then someone may be rigging the game.

The second check will be in the HTTP server logs. How many times has that IP address requested the submission? How many times has that IP address requested to download the game? Is it regular, or does it happen at seemingly random intervals? Does the score slowly increase, or does it increase rapidly? Does the score go down as well as up? Has the same name been registered from multiple IP addresses, in what appears to be the same or a similar geographic location? All these questions need to be asked. If any of the responses to those questions look odd, then your suspicions are probably valid.

If the owner's server is using tools such as Webtrends or Analog, it can be easier to spot access patterns over the long term. Once suspicious activity has been found, the contestant could be asked to prove they are capable of the score in front of the appropriate people. Of course a racing game with a top lap time of under a second is easy to discount but lower, more realistic scores may still qualify for the prize.

Creating defendable games

As mentioned earlier, most games cannot be defended against manipulative attacks. Certainly no game that relies upon user input for scoring can. There are certain games that can be defended from attack, namely those that only require user input to set the game up, but where the game itself is controlled on the server. A good example of this is roulette. You bet on your color but the server determines where the ball will land. If a game server informs the client how many lives it has, then stopping the user from 'dying' every time their character makes a mistake becomes more difficult. Setting a realistic score-ceiling within the game may help identify obvious cheaters, but it shouldn't be set too low in case someone actually achieves it.

Tips for businesses using online competitions

  • Assess the cost of securing the application versus the costs incurred by online competition fraud.
  • Try to avoid designing simple games that rely upon user-submitted input, such as scores.
  • For larger or recurring competitions, security assessments are strongly advised.
  • Utilize trend-analysis software to identify fraudsters.  

Not all games work this way. A quiz-based game that requires someone to get the answers correct in the quickest time is something that can be scripted. The entire question database is reverse engineered by making repeated requests for questions. The attacker populates an array of these with the correct answers, then uses the script to automatically submit the correct answers, and retrieve the next question. The rest of the time taken to do the quiz is down to bandwidth, and any delay the attacker may wish to implement between submitting answers. Although no score is provided, it is possible to defeat the system in this manner. More complex games such as chess or Othello are more difficult to attack, but if the prize for beating a computer at chess is IBM's Deep Blue, the one sure bet is that an attacker will find a way to beat your game, fairly or otherwise.

Raise the bar

In the end, it's up to the game designers to ensure that the bar is raised sufficiently to stop cheats taking advantage. Businesses should ask themselves whether or not it's important who actually wins the competition prize, and if it's worth spending more money ensuring that the game is safe from fraudsters. If all that matters is collecting email addresses then it probably isn't worth it. But if it's a competition that's run regularly, obvious cheating may cause some embarrassment for the company hosting the competition.

Steve Lord is consultant X-Force Security Assessment Services, Internet Security Systems (www.iss.net).

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.