RSS
 

Posts Tagged ‘town of salem’

BlankMediaGames/Town Of Salem Data Breach (2020 Update)

06 Jan 2020

Overview

Town of Salem, a video game produced by BlankMediaGames was breached around 1 year ago on the 3rd of January 2019. It is reported that the total row count of that database that was breached is 8,388,894 which included some 7,633,234 unique email addresses.

Shortly after this breach in early 2019, hackers attacked and successfully cracked ~2.4 million passwords from the breach due to the weak MD5 encryption used. These cracked passwords were initially sold on the black market but were later released to the public on public forums.

Shockingly however, these passwords were never reset as part of the breach. Exactly one year later, a huge number of accounts are still working with the same credentials that were exposed during the breach. This has led to malicious bot writers creating Town of Salem bots with the only purpose of joining ranked games to:

  • intentionally game throw,
  • post hate speech/racial slurs,
  • spam chat to advertise,
  • impersonate other players in hopes of getting them falsely reported/banned,
  • afk / idle

Validating the breach (1 Year Later)

The cracked dump included 2,418,341 cracked entries in email:user:password format.
I decided to write a script to categorise these breached accounts. This script would iterate all user:password combinations and attempt to authenticate with the main Town of Salem game server at live4.tos.blankmediagames.com:3600. There is no login rate limiting in place so we could bruteforce the credentials at full throttle.

For each authentication attempt, one of the following responses was sent back by the server:

  • LOGIN_SUCCESS (successfully authentication)
  • LOGIN_FAILED (invalid credentials, password has been changed since breach)
  • LOGIN_BANNED (account is banned)
  • LOGIN_PASSWORD_CHANGE_REQUIRED (account has been marked as requiring a password change)

We are only interested in accounts that return LOGIN_SUCCESS as these are the only accounts that can be used by bot makers to ruin games.
Running a quick scan shows that many of the very first entries are still authenticating successfully.

Out of the 2,418,341 accounts scanned, it was discovered that as of 29/12/2019:

  • 961,874 accounts returned LOGIN_SUCCESS
  • 1,048,665 returned LOGIN_FAILED
  • 29,159 returned LOGIN_BANNED
  • 378,643 returned LOGIN_PASSWORD_CHANGE_REQUIRED

Responsible Disclosure

These findings were reported to BlankMediaGames via email.
Shapesifter13 (community manager) also reached out via Discord to help fast-track the process (thanks!):

Resolution

On 03/01/2020, the Town of Salem game servers were restarted for an update to address this issue:

It is important to note that it appears that BlankMediaGames were already addressing this issue coincidentally at the same time I was researching it and they moved a lot of accounts from the LOGIN_SUCCESS state to the LOGIN_PASSWORD_CHANGE_REQUIRED state. However, they did not initially address every exposed password I had access to in the first batch of database patches.

After the patches, previously cracked passwords now require the user to go through the password change recovery process.

Hopefully this resolves the problematic botting situation in Town of Salem for now.

Timeline

29/01/2019 – Obtain breach dump to perform analysis
01/01/2020 – Finish running script and gather results. Report to BMG via email.
03/01/2020 – BlankMediaGames perform database patch addressing majority of leaked passwords.
10/01/2020 – BlankMediaGames perform database patch addressing remaining leaked passwords.

 
3 Comments

Posted in Exploitation

 

BlankMediaGames/Town Of Salem XSS

03 Jan 2020

While looking on the BlankMediaGames.com website (creators of Town Of Salem) I came across an api.php file which one inside one of the folders listed in the sites robots.txt  file.

The file in question is:

Upon visiting the page we get the following output with a 200 response code:

At first I thought this was a hidden API but it turns out to be nothing more than a simple echo script. I suspected the script takes in some input as GET or POST parameters so we use a script called parameth to bruteforce the GET and POST parameters using a dictionary attack.

We run the script with the following parameters:

The argument --sizeignore  allows us to ignore responses that have a particular size (in our case 19 bytes). Typically we’d use the response code to filter out default responses but in this case the response code was always 200.

We find the following inputs:

Therefore, the two input GET parameters are hello and request. These parameters are echo’d to the page without any input sanitation meaning the original PHP script would look something like this:

As a result this script is vulnerability to XSS:

Output:

Timeline

01/01/2019 – Reported to BMG
03/01/2019 – Patched by BMG.

 
No Comments

Posted in XSS