The incident began in the late September of 2022 when the Australian telecommunications company Optus disclosed that a major data breach had occurred within their system, exposing around 9.8 million former and current customer's personal details. The extreme quantity of people involved makes it the 2nd largest data breach in Australian history as of writing.

The data exposed included customer's:

The severity of the incident lead to several regulatory investigations, class actions and new government cybersecurity policies across Australia. As of writing, the law firm Slater and Gordon is currently conducting a class action against Optus for allegedly breaching Australian law and its own policies by failing to protect its customer's data and destroy or de-identify former customer's data. This class action is joined by 100,000 current and former customers looking for compensation. These class actions and legal compensations have not been fully completed as of writing, so the exact monetary loss Optus will face is not yet known, but it is calculated by the Queensland Government that they lost $1.5 billion worth of brand recognition alone after the breach.

As for new laws and regulations, the breach has served as a key motivator and backdrop for change: the Office of the Australian Information Commissioner has introduced a multitude of new changes, introducing harsher penalties that can reach above $50 million. In 2024 the Cyber Security Act 2024 was made law, introducing security standards for smart devices, ransomware payment reporting and a cyber incident review board. Alongside these new regulations, the National Office of Cyber Security was founded in April 2023, providing more dedicated resources to managing the country's cyber security.

But what underlying weaknesses caused this breach to happen? and why did they lead to such a significant breach?

Secondary test API domains are not uncommon in the digital world, they act as useful tools for replicating the conditions of a system or digital environment allowing for efficient testing, debugging and vulnerability assessments without disturbing the original system. However, improper configuration or management of these systems figuratively 'opens windows' for attackers to exploit. 

In the case of Optus they made a fatal mistake by failing to incorporate authentication within this test domain, allowing connection with anyone without the submission of a username and password. To go alongside this, Optus encountered an access control weakness in 2021 shared between the main domain and the secondary domain that had been present in both since 2018. They fixed the error on the main domain but didn't update the secondary domain, leaving it exposed.

This level of exposure wouldn't normally expose user data, only the inner workings of the Optus system, as test domain usually operate using a synthetic dataset to avoid data exposure. However, Optus had connected the actual customer information dataset to this test API, exposing all the sensitive information through this secondary API that lacked authorisation measures and contained an access control vulnerability that had been left unfixed. 

Alone this vulnerability is dangerous, but normally attackers cannot reach the API and exploit due to being private facing and reserved for confidential personnel during testing phases. This is where mistake 2 enters the picture - the ladder left next to the open window.

APIs are split into 2 distinct categories: public facing and private facing. Public facing APIs are open to anyone on the internet who can locate them. Usually they are designed for the purpose of connecting free services with external systems allowing for interaction between the user and the service - An example being weather apps, which share temperature, humidity and other weather data to users. Private APIs conversely are designed to perform internal business functions and are restricted to internal networks to protect said functions - A prime example being management of sensitive user information a company has collected from its customers.

This is where Optus made another critical mistake, as the previously discussed undefended secondary test domain was public facing, not private facing, exposing it to everyon on the internet. APIs run using back-end processes that return designated information from connected databases or code. Each process has an associated API endpoint, which are easy to find with common internet scanning tools, meaning it was a matter of time before someone came across the secondary test domain and determined the processes it could perform. Without username and password authentication the endpoints could be called freely by the attacker, returning sensitive information right into their hand.

At this point the system was already fully exposed and leaking sensitive information to the attacker, but it was made worse through Mistake 3, which turned the leak into a flood.

In order for a database to function, each record needs it own unique identification number that the system can call upon to reference it. Following best cybersecurity practices ensures that these identifiers are completely unique an unrelated to each other so that if one record becomes exposed, it doesn't reveal another record, causing a chain of data exposure. This slows attacks down, specifically data harvesting as attackers cannot find and harvest records as quickly, and brute force methods are impossible in most cases.

Optus generated customer IDs incrementally, meaning the first record would have an ID of 1, the next 2, and so on. To reveal the danger of this lets do a tiny bit of maths:

• If we were to label all possible numbers that could be the proceeding or preceding identification number when using incrementally generated IDs, there is only one possible number the proceeding or preceding ID can be; as it would just be the number +1 or -1. This is extremely dangerous as it means after finding an ID the next ID can almost be found instantly. If we compare this to randomly generated IDs, we see a massive change.
• To label all possible numbers that could be the proceeding or preceding identification number when using randomly generated IDs, we find that it depends on the length of the number and how many possible characters can be used. Lets say we have an ID of length 10 that can have upper-case and lower-case letters or numbers. This leaves us with 62 possible options for each of the 10 character spaces. If we compute this number it comes out to be 8.3929937e+17 (62 to the power of 10) - This is how many numbers an attacker must guess / trial in order to find an ID at any given moment. It is physically impossible to find.

This showcases the drastic impact of Optus' mistake. What could have been a wall that slowed the harvesting of data, instead expedited it, contributing to the massive number of approximately 9.8 million impacted people.

So, how do we prevent these weaknesses? Or at the very least minimise them?

Always authenticate sensitive protocols or information with strong passwords. This should be combined with the cybersecurity practice: Principle of Least Privilege - Providing only the minimal level of privilege in a system to a user that they need to complete their task or role. This ensures that all data is adequately protected, while simultaneously limiting access and control over it.

Never use real data in any test situation; whether it be a penetration test, vulnerability assessment or secondary domain. These situations are meant to focus on the system and have no benefit from using real data, only inviting privacy breaches. Create synthetic data to replicate records and use it to prevent any data leakage or exposure

When managing multiple API domains maintain proper management over all assets. Ensure all domains receive every update, and maintain identical equivalence between each other. If an old system gets replaced; remove or delete the old one to prevent attackers from using the unprotected domain as a back door around security. This ensures that there are no weaknesses or holes to exploit, while saving resources and ensuring test domains remain relevant and accurately represent system capabilities during threat assessments.

Remember the difference between public and private APIs and use them appropriately. Public APIs are available to everyone on the internet and should never contain sensitive or confidential information to avoid potential data exposure. Instead the data should be appropriately incorporated in a private API so that all business services and confidential data remains secure and untouchable by outside influences.

As discussed earlier, randomly generated IDs are mathematically proven to stem the flow of data harvesting by dramatically slowing how fast and feasible it is to expose database IDs. This form of generation should always be utilised and made as complex as possible. It is incredibly simple to do and exponentially improves the defensive capabilities of databases, becoming infeasible for brute force attacks.

Installing a threat detection system provides an excellent warning system should a system become compromised. Modern IDS systems are constantly being developed and improved, becoming more efficient. A network IDS could be installed to monitor for suspicious API calls, allowing attacks to be spotted earlier and allowing the exposed API to be taken down quicker - In turn giving attackers less time to cause damage or steal data.

Ultimately the best way to prevent attacks is to find weaknesses and vulnerabilities before attackers do and the best way to do that is with vulnerability assessments and penetration tests. These replicate the environment and mindset of attackers providing a real world test for your system along with accurate and detailed findings.

At DCO Enterprise we offer web domain vulnerability assessments, so if you are interested in any potential vulnerabilities your public APIs or other web applications may have, reach out to us through the contact page on the website navigation bar or email us at info@dcoenterprise.com.au. Alternatively you can head straight to our shop and purchase one of our services now, so that you can Assess Before You Stress!