MattCASmith

Here’s one more writeup from the SANS Holiday Hack Challenge! The slot machine hack was one of the showpiece challenges this year, so I thought I’d put together a quick blog post to guide you through the process of identifying and exploiting a vulnerability in the game.

The challenge

Our task is clear enough. We’re given a link to an online slot machine and the following request:

Test the security of Jack Frost’s slot machines. What does the Jack Frost Tower casino security team threaten to do when your coin total exceeds 1,000? Submit the string in the server data.response element.

Let’s follow the link and take a look at the slot machine. It’s fairly typical for such games (at least as per my understanding following a short trip to Las Vegas for Black Hat and Def Con). You can choose various options before placing a bet by hitting the Spin button. Your credit is updated based on the outcome.

Since our objective is to hit more than 1,000 credit, we could just play the slots for a long time to try to get lucky. But that would take forever. Instead, let’s take under the hood to see what we can hack…

Observing requests

Like any web application, the slot machine must be communicating with a server behind the scenes to make playing the game possible. By using the Burp Suite proxy’s intercept function, we can hold requests and responses between the web browser and the server to give us time to review their contents and see what’s going on when we place a bet. Here’s what is sent when we hit the Spin button…

This looks like a pretty standard web request. We can see that this is a POST request, which means that the client is transmitting information to the server (slots.jackfrosttower.com). We can see that the request provides some cookie information, details about the page we’re on and our user agent, and so on. This is all pretty normal for this kind of request. But what about that last line?

betamount=1&numline=20&cpl=0.1

Comparing these variable names to the GUI, we can ascertain that this is our browser telling the server how much we’re betting, the number of lines we’re betting on, and the cost per line. Interesting. By tweaking these values, we might be able to:

• Change the bet amount to a bigger stake than we can actually afford
• Bet on more lines than actually exist on the slot machine
• Adjust the cost per line to alter the slot machine’s financial calculations

From here, it’s a matter of trial and error. Attempting the first two potential exploits returns a Server Error response. That leaves only one option - but how can we use the cpl variable to our advantage?

Crafting a malicious request

So here’s the plan: We’re going to set cpl to a negative value to confuse the game if this input isn’t validated. For example, if we set it to -100 and there are 20 lines to play, that spin would cost us -2,000 credits to play and therefore actually increase our credit by 2,000 (and any winnings from the spin).

To do this, we hit the Spin button on the slot machine’s GUI. Burp Suite intercepts the request. We must very quickly change the cpl value to -100 and hit the Forward button before the spin times out.

It looks like the server doesn’t check that cpl is set to a valid value before executing the spin. All goes to plan and when the play is complete our credit is now in the thousands! Mission complete - almost.

Our task was actually to find a value in the JSON response once our credit exceeds 1,000. To do this, we can take a look for the relevant request and response on Burp Suite’s HTTP history page. Sure enough, in the data.response field, we can see the following message from casino security:

And that’s our flag: I'm going to have some bouncer trolls bounce you right out of this casino! Hopefully we have enough time to submit it and take the credit for our hacking first.

If you found this walkthrough interesting, please consider following me on Twitter, and don’t forget to sign up for the next SANS Holiday Hack Challenge circa December 2022!