It’s time to delve back into the expert hacking world of Cyrex’ security engineers as they tackle security vulnerabilities and hunt down bug bounties in their spare time! We’re joining Hazem Elsayad again, our Lead Offensive Security Engineer for the Cyrex team, as he documents his impressive progress on his blog, Hacktus!  

This time, Hazem leads us through some more games-related bugs. Let’s see what he has for us!  

Exploring Chests or Boxes: Unravelling the Secrets

In the digital realm of gaming, chests and boxes are akin to Pandora's Box, each unveiling unique rewards and surprises. For instance, you're generally allowed to open a 'Golden Box', but what if, with a simple modification in the request, you could access the coveted 'Diamond Box'? This minor alteration not only permits players to access content they're not supposed to yet but might also allow them to do so at a significantly reduced cost, disrupting the game's intended economic balance.

A standard request to open a "Golden Box" might look like this:
{
  "action": "openChest",
  "chestType": "Golden"
}  

However, by changing the ‘chestType’ to "Diamond," players can manipulate the outcome:  
{
  "action": "openChest",
  "chestType": "Diamond"
}  

This small adjustment could enable players to bypass intended gameplay progression and resource allocation, offering an unfair advantage or altering their gaming experience.  

Debug Endpoints: Hidden Passageways Within the Code

Debug endpoints are like hidden corridors within a game's architecture, intended for developers to troubleshoot and test. However, when these endpoints remain active in a live environment, they become secret tools for players to exploit. These can range from altering player stats to revealing hidden game mechanics, potentially giving some players an unfair edge or breaking the game's immersive experience. Imagine stumbling upon a debug endpoint that allows you to modify your character's attributes:  

POST /debug/modifyAttributes HTTP/1.1  
{
  "userId": "player123",
  "attributes": {
    "strength": 100,
    "speed": 100
  }
}  

Access to such an endpoint can drastically alter the game's competitive landscape, enabling players to modify their avatars beyond the game's standard limitations.  

IDORs: Unintended Consequences of Poor Validation

One of the humorous scenarios we often come across in Cyrex involves an IDOR, where a game lets you execute a modification or enhancement that's supposed to be confined to your account. Yet, if there's a tweak in the user ID within the request, it mistakenly influences another player's account

Consider a scenario where you're supposed to upgrade a building:  

POST /api/upgradeBuilding HTTP/1.1  
{
  "userId": "12345",
  "buildingId": "67890",
  "currency": 1000
}  

By merely changing the ‘userId’ to that of another player, you could potentially charge the cost to them, leading to unauthorized resource transfers:  

POST /api/upgradeBuilding HTTP/1.1  
{
  "userId": "67890",
  "buildingId": "67890",
  "currency": 1000
}  

DOS Attacks: Exploiting System Limits for Disruption

Long Usernames/Names: When games do not enforce backend validation for the length of usernames, players can create excessively long names, causing stress on the server and affecting the gameplay experience for others. This can result in server slowdowns or even crashes.  

POST /api/createUser HTTP/1.1

Host: examplegame.com

Content-Type: application/json

Content-Length: [length]  
{
  "username": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...",
  "password": "SecurePassword123!",
  "email": "user@example.com"
}  

Long Messages: Without limits on message lengths, players can flood chat systems with extensive messages, overwhelming the chat interface and potentially causing backend issues due to the excessive load.  

POST /api/sendMessage HTTP/1.1
Host: examplegame.com
Content-Type: application/json
Content-Length: [length]  
{
  "message": "Lorem ipsum dolor sit amet, consectetur adipiscing elit... (extremely long text)",
  "userId": "123456",
  "roomId": "654321"
}  

Manipulating Transactions for Unforeseen Gains

A peculiar yet exploitative aspect we've encountered involves transactions where the game fails to validate whether the ‘currencyPaid’ value is negative. When a player is supposed to pay a certain amount to receive or upgrade an in-game item, flipping the amount to a negative number could, ironically, increase their in-game currency instead of deducting it.

A typical upgrade request might look like this:  
POST /API/upgrade_house
{
  "houseId": "98765",
  "currencyPaid": 50000
}  

But altering the currencyPaid to a negative value could unexpectedly credit the player's account:  
POST /API/upgrade_house
{
  "houseId": "98765",
  "currencyPaid": -50000
}  

This action could result in the player receiving additional funds, turning what should be an expenditure into a gain, due to a logic flaw in the game's transaction processing system.  

Game Bugs Galore

It always evokes a feeling of pride from us at Cyrex when we see one of our team excelling so thoroughly in their own time. We’re always astounded by the talent on display whenever our team gets into their work. If you’d like to see more of Hazem’s work, you can check out his blog here: Hacktus. Or you can follow him on LinkedIn, where he also shares his security insights.  

If you’d like to get involved with Cyrex and utilize an entire team with the talent, expertise, and skill shown by Hazem, get in touch with us today for the industry leading results in penetration testing and load testing!