HackedIN: Double or nothin'

How I hacked two of Australia's largest Casino's (legally).

Disclaimer: Both Casino's have long since patched these issues.

Don't do crime.

House of cards

When most people think of a Casino, they think of high security, underground vaults, and an overall intimidating complexity.

But with great complexity comes great security consequences.

It’s easy to think of a casino as one big money-making machine.

But the reality is, under the hood, casinos are run by many individual moving parts, all relying on each other equally to function.

This complexity represents an opportunity for hackers while resulting in obscurity for the people tasked with protecting the casino.

Eyes on the table, not on the door

To add to the already complex ecosystem is the fact that many of the responsibilities lie with external contractors, whether that be software developers, electrical engineers, or any other kind of vendor who is responsible for designing, delivering or supporting one or more parts of the ecosystem.

While all eyes are on the tables, in my experience, far less focus is on the people and technology that holds it all together.

Root cause

Although I won't share specifics, I can discuss the root cause (what exactly caused these casino's to be vulnerable) in detail.

This way as a reader you can understand how a criminal might exploit this in the real-world.

In both of the two examples I will share, the vulnerability existed thanks to a lapse in security of a third-party-developed mobile application.

Casino 1 - █████ ████ ████

To provide some context around the first example.

At the time I found this (2019), social gaming was big business.

The mobile application was created for patrons to play digital versions of various games, including but not limited to slot games.

Although winnings earned using the mobile app could not be converted to "real money", the game did offer an alternative type of virtual reward that was apparently awarded to players randomly and not related to the amount of real money spent or in-game winnings.

These alternative virtual reward points could then be traded for various goods within the casino premises.

After downloading the app, it didn't take long to go from client-side analysis to confirming a backend exposure.

Here's how it played out step by step.

1. Installed mobile app
2. Found development domain api.casino.3rdparty-dev.com
3. Found exposed Git repo on third-party API developers web-server api.casino.3rdparty-dev.com/.git/config
4. Analysed exposed source-code
5. Found API keys, additional vulnerabilities, SSO/OAuth secrets and credentials for various services used by the backend API server, including production assets related to member database and royalty points
6. Notified impacted parties and ensured the issue was resolved.

Casino 2 - █████ ████

This mobile application was targeted not to patrons, but to third-party vendors.

The application was designed to allow external vendors to request for permits to perform maintenance work at █████ ████ properties.

For example, if an external electrical engineer needed to request access to The Casino’s camera system or request access to cabling within the roof of a casino for repairs, according to the description of the application, the contractor would have to submit a permit to work application which would either be approved or denied by a team within the Casino’s contractor management area.

Here's how the attack path went.

1. Installed mobile app
2. Analysed API calls made by the app to and from the API server
3. Found a way to list all members (vendor companies) who were registered in the backend (Id, Name, Mobile Number, Email, Casino Property Access (Location specific.), Casino Contract Controller Status)
4. Checked e-mail domains of registered vendor businesses to see if any of the businesses had shutdown
5. Found a Victorian building company that had been de-registered and claimed the business domain that had been left to expire
6. Created a mailbox that belonged to the shutdown business (which hadn't been removed from the casino vendor management system)
7. Issued a password reset to the mailbox that I now controlled
8. Had the ability to access the Casino's vendor request portal including but not limited to request access to the Casino's data room
9. Notified impacted parties and ensured the issue was resolved.

The Takeaways

1. Mobile App Security Audits: Regular, in-depth security audits of all mobile applications associated with your infrastructure. This is NOT ONLY the mobile applications themselves, but all of the infrastructure that belongs to the developers who built your app.
2. Securing API Endpoints: APIs are often the backbone of mobile apps. Orgs should enforce strict security on API endpoints. This involves implementing robust authentication, monitoring API traffic for unusual patterns, and encrypting the data transmitted between the app and the servers.OWASP's API Security Top 10 is a good start.
3. Vendor Domain Management: In the case of Casino 2, an expired vendor domain was exploited. Casinos should maintain an up-to-date registry of all external vendors and regularly verify the status of their domains. If a vendor goes defunct, their access and associated domains should be promptly revoked or monitored for unusual activity.

To summarise, hackers won't just target you directly. They'll look at every moving part of your ecosystem and systematically attack them until they get in.

Make sure you do that first.