Introduction

Disclaimer: The information in this blog post is provided for educational | |purposes only, intended to raise awareness of cybersecurity issues and promote better online security practices. All identifying details related to specific vulnerabilities and the entities involved have been anonymised or changed. Any resemblance to real companies, organisations, or events is purely coincidental and unintentional. This content is not intended to facilitate illegal activities or harm any organisations or individuals. We do not condone unauthorised access to or misuse of computer systems or information, and we encourage everyone to respect the law and online ethics.

I remember watching Oceans Eleven for the first time.

The movie captures a perfect mix between art, storytelling and the creativity of the human brain - specifically, our ability to perform lateral thinking when working towards a desired goal.

For defenders, lateral thinking provides some valuable lessons when it comes to comparing the way WE see our attack surface with the way THEY see our attack surfaces.

Let’s not forget, though, that movie came out 20 years ago.

This had me thinking, how different would things be if Oceans Eleven was set in Australia in 2023?

This blog is the first in a series of posts where we’ll share lessons from our security research that have resulted in us finding multiple critical flaws in some of Australia’s and the World’s biggest Casinos.

Our Purpose

This post isn’t about pointing fingers or shaming any brands; we aim to share these lessons with other organisations to help them stay one step ahead and see themselves from an attacker's perspective.

With that said, for the rest of this blog, we will use fictional brand(s), namely “The Casino” and the “third-party solution provider”.

Summary of Issues

• A leaky, publicly accessible API exposed complete details belonging to vendors, including emails, phone numbers and user IDs.

• The API exposure, combined with the existence of expired database users, could have allowed attackers to impersonate trusted vendors and potentially gain access to the Casino’s physical locations.

Background

If it wasn’t already obvious, thanks to every casino heist movie in history, casinos are one of those types of businesses where you’re only as secure as your supply chain.

Casinos have lots of moving parts, and with all those moving parts, you end up with lots of people or vendors to maintain.

Whether it's electricians, engineers, security or even builders, the Casino needs a way to manage access for all these people.

Sometimes, the work that is to be carried out by external vendors can involve hazardous operations such as work involving live electricity or work conducted in confined spaces.

In these cases, Casinos can utilise systems and processes which are used to identify the work’s scope and the risks that come with the work.

These systems can also involve appointing the people who are authorised to handle hazardous tasks and the people in charge of keeping the processes as safe as possible.

The Weakest Link

Note: All identified issues were disclosed to the affected parties and have been remediated.

During our research, we identified a mobile application used by The Casino.

This mobile application was designed to allow external vendors who would request permits to perform work at The Casino’s properties by issuing work permits via the mobile application that could then be used by external vendors on-site at Casino locations.

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.

As discussed further in this post, for a casino or any business, dealing with a large number of external vendors can introduce a favourable attack surface for criminals to abuse.

Under the hood

Behind the scenes, we noticed The Casino’s mobile application was calling APIs related to a third-party solution provider, who will remain unnamed out of good faith.

This third-party provider offers risk and safety, contractor management and permit-to-work solutions to many large enterprise clients in Australia.

Note: At the time of writing, we have not seen any evidence to suggest other clients using the same third-party solution provider are vulnerable.

When an employee of a trusted vendor wishes to register, they must provide the name of the vendor company they belong to via a search form.

The application will then do a lookup using a backend API call and return a list of four (4) or fewer matching vendor company names, as seen below.

Underneath the UI, when users enter text into this form, an API call is made to the third-party solution provider; however, unlike the front-end UI, the API was returning all companies that are stored on the backend as opposed to only four (4).

Unfortunately, before this was remediated, any unauthenticated user could have viewed the API directly, which, when requested, would respond containing information on a total of 509 external vendors.

Some of the vendors included in the API output had lost their approval status, according to our interpretation of the API output, as seen below.

For each external vendor, the following information was available to any user:

• Id (Member ID, not PII)

• Name

• Telephone

• Primary Contact

• Mobile Number

• Email

• Casino Property Access (Location specific.)

• Casino Contract Controller

• Status

To understand how this might be useful to someone like Danny Ocean, imagine knowing which direct Casino employee was responsible for managing each vendor and then using that as a pretext for a social engineering attack.

In our opinion, these are personal relationships few people, if any, outside of The Casino should know about.

When it comes to the security of a casino, or any business for that matter, there’s a big difference between assuming consequences and being able to demonstrate them.

This is important because when risks cannot be effectively demonstrated, organisations tend to leave themselves exposed due to not seeing real-world threats.

Staring at the API output…

[ { "id": "DataG0202",
   "name": "Datagatornetworks",
   "telephone": "0400 111 222",
   "primaryContact": "Jane Doe",
   "primaryContactMobile": "0400 111 222",
   "primaryContactEmail": "jane@datagatornet.com.au",
   "casinoProperties": [ "sincity" ],
   "casinoContractController": "Terry Benedict",
   "status": "Approved" } ]

I began to wonder…

If a criminal was to find this information, what would they actually do with it?

If I could answer this question, not only would this demonstrate impact, it would provide enough real-world context for stakeholders to address the issue before it was exploited by malicious parties.

I quickly realised, if a criminal wanted to impersonate any casino-approved vendor, they would likely aim to impersonate a vendor who might have access to the network or some other form of technical access.

Looking through the company names, a few stood out; for privacy reasons, I won’t use real company names, but for imagination's sake, you can imagine a scenario where an attacker was looking to impersonate a vendor with network access.

If this was the case, they would be more attracted to vendors with company names like:

• John’s Electric Co

• E-Spy CCTV Pty Ltd

• Datagator Networks

Using the company names and other information returned by the API, I attempted to learn more from the websites of the exposed vendors.

Most of the websites were generic, however, one of the vendor's websites did not load at all.

At first I thought nothing of it, but that’s when it struck…

I then asked myself, what would happen if one of these vendor companies, who were users of the third-party permit application, went out of business and their domain name expired along with their email and everything else?

In general, allowing users with expired emails to remain in any database can expose applications to a higher risk of unauthorised access.

By allowing an expired domain to remain associated with an active application account, attackers can easily register the expired domain, recreate the user's email address, and subsequently issue password resets to hijack the account.

This could lead to unauthorised access to user data, application settings, and critical system functions, potentially resulting in serious consequences for both the application users and the organisation that owns the application.

But why would an external vendor that services a casino let their domain expire?

It just so happens this company went into External Administration in late 2022 as confirmed when looking the company up on the Australian business register.

Interestingly, although the company went into administration in 2022, at the time of finding this API exposure, it was already March 2023 and according to the list of vendors returned by the third-party API, the company appeared to remain as an approved vendor.

Was the list of approved vendors stored by The Casino’s third-party solution out of date?

Meaning, even if the vendor (DataGator Networks) was listed as an approved vendor in the third-party solution’s database, maybe The Casino had a more up to date listing and would not allow this vendor to access the application.

To understand this impact, as well as to prevent any attacker abusing this, I proceeded to register the expired domain datagatornetworks.com.

With complete ownership of the expired domain, it was possible to set up a valid mailbox and receive e-mails.

To test this theory and demonstrate real-world risk, I had to submit a vendor registration request and supply our name, mobile, email and vendor company as seen below.

As there was no documentation explaining how vendor registrations would be processed, I could only assume the following two possibilities:

1. Registrations would be processed manually by Casino staff or;

2. Registrations would be processed using an automated process that might only check the requesting users e-mail domain.

Keep in mind, according to the API output from the third-party solution, the only user that existed within the vendor’s account was jane@datagatornetworks.com.

Knowing this, and to truly test the above assumption, I submitted a registration request using a new user john@datagatornetworks.com.

Within a short period of time, a registration approval email was delivered to the newly created email address john@datagatornetworks.com as seen below.

With this access, it was possible to login to the now insolvent vendors account.

Although no further actions were performed, theoretically I could have done the following:

• Managed external vendor details

• Applied for vendor permits including onsite Data Hub Room Access at the casino

• Viewed previous permit history

Below are some sample screenshots of what an attacker would see after they had taken over the expired vendor domain and account.

How could this be exploited?

Although a high risk attack for anyone planning to abuse this issue, one potential avenue for an attacker would be to request a permit for the PERMIT88 - Data Room Access and use this to gain further network level access by impersonating a trusted external vendor onsite.

You might be thinking that attack is far-fetched, but it wouldn’t be the first time a criminal tried and succeeded in pulling something like this off.

For example, there has been at-least one documented incident where attackers had targeted CCTV systems maintained by an Australian casino resulting in an unconfirmed $32 Million dollar theft as alleged by various media sources.

Although it’s impossible to know what level of access an attacker could gain from the Data Hub Room, given the naming and context of the application, it is not unrealistic to assume this access could give an attacker the opportunity to physically compromise various components of The Casino’s infrastructure.

Attack Path Recap

1. Exposed API Endpoint

After modifying the API request, the API would return complete details for all Casino vendors without authentication.

2. Domain Takeover

As the external vendor had gone into voluntary administration, it is presumed the business owner allowed their domain to expire, leaving it open to takeover via domain registration.

3. Account Takeover

Due to assumed inconsistencies between Casino records and third-party vendor management records, the business that was in voluntary administration was still listed as an approved vendor and therefore was approved to add new users to the Casino’s vendor work permit system.

4. Casino Access

Theoretically, an attacker could have applied for, and used an approved work permit for access to the physical Casino including but not limited to access to the Data Room.

Homage

As a side note, and to show some homage, remember that scene in Oceans 11 where Danny Ocean and Rusty are reviewing the structural diagram of the vault under the Bellagio.

When looking through the same mobile application we found some interesting assets.

One file in particular was named diagram-plan.pdf which if we we’re reading it right, and we’d like to think that we we’re, was some form of floor plan or structural diagram for The Casino.

Timeline

• Dec 12, 2022: Attempts to contact various security stakeholders

• May 2, 2023: Established communications with The Casino’s Chief Information Security Officer (CISO)

• May 2, 2023: Responsible disclosure report The Casino’s cyber team

• May 3, 2023: The Casino acknowledges report

• May 15, 2023: API Exposure remediated and no longer exposes vendor information

Working with The Casino was a great experience, they effectively resolved the disclosed vulnerability within an acceptable time period.

Takeaways

Implement privacy-by-design for your APIs

As a security best practice, we highly recommend organisations to incorporate a privacy-by-design philosophy while developing their APIs. A comprehensive API security design review is pivotal in addressing potential vulnerabilities and enhancing the overall security posture of any application.

Key areas of focus during the review should include vulnerabilities like Broken Object Level Authorisation, Broken User Authentication, Excessive Data Exposure, Insufficient Resources and Rate Limiting, Broken Function Level Authorisation, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, and Insufficient Logging & Monitoring.

Addressing these critical points can help organisations prevent unauthorised access to sensitive data, safeguard user accounts against compromise, reduce the risk of data breaches, and ensure optimal system performance. An effective API security review should not just stop at identifying and rectifying issues, but also integrate continuous monitoring and auditing procedures to promptly identify and remediate newly discovered vulnerabilities.

By giving priority to these aspects of API security, organisations can substantially decrease the likelihood of encountering cyber threats, maintaining a strong and secure infrastructure. This, in turn, fosters trust among users and stakeholders, thus boosting the credibility and reputation of the organisation.

Keep track of your users

Regardless of whether it’s only a risk if an attacker can view member details, by ignoring user accounts associated with expired email domains, organisations significantly elevate their risk of unauthorised access and account takeover via domain registration takeovers.

Letting an expired domain remain associated with an active application account can pave the way for attackers to easily register the expired domain, replicate the user's email address, and issue password resets to hijack the account.

To immediately mitigate this risk, organisations should conduct thorough user account audits to identify any accounts associated with expired domains, and promptly deactivate or flag such accounts for review.

Active user management is not a one-time activity but should be an ongoing process. Organisations must ensure regular audits of user accounts, monitor for any signs of suspicious activity, and promptly act upon any potential security threats. By adhering to these practices, organisations can significantly reduce the risk of account takeovers and maintain a secure, trustworthy environment for their users.

Implementing stronger authentication

Enhanced authentication methods, including but not limited to multi-factor authentication (MFA) and liveness detection, can significantly reinforce the security of applications against attackers aiming to hijack expired email domains and subsequently take over customer accounts.

The integration of facial verification as part of the registration and password reset processes can ensure that the user is indeed the legitimate owner of the account, even in cases where an attacker has control over the associated email address. This type of authentication uses biometric data to validate the user's identity, providing an additional layer of security that effectively counters domain-based attacks. Biometric data is considerably more challenging for an attacker to forge or impersonate, making it a powerful tool in securing account access.

Incorporating facial recognition into the application's authentication process not only elevates the overall security posture of the system, but it also instils greater confidence among users. They can be assured that their personal information and account access remain safeguarded against increasingly sophisticated attacks. By prioritising stronger authentication methods, organisations can provide a secure environment that significantly reduces the risk of unauthorised access and boosts user trust and satisfaction.