How did the Optus data breach happen and how to avoid it?

In September 2022, Optus, one of Australia’s leading telecommunications providers, experienced a data breach that exposed the personal information of almost 10 million customers. This incident marked one of the largest cyberattacks in Australian history, leading to high concerns regarding data privacy and security practices in the country.

This article will focus on the following questions:

• What Security flaws did Optus have leading to the data breach?

• What are some countermeasure methods Optus could have used, to avoid the security breach?

In the following, you will find the 5 security flaws of the data breach at Optus.

The first major security flaw in the Optus breach was the usage of a public-facing API (Application Programming Interface) that facilitated access to sensitive internal data. Public-facing APIs are designed to enable external systems to interact with a company’s services, but when these APIs are not properly secured, they can become a gateway for attackers

What are public-facing APIs used for?

Secure public-facing APIs, like for example the Google Maps API or the Weather API, provide limited, non-sensitive data to external systems. They are designed to isolate any shared data from core business operations, making them inherently safer.

Why are public-facing APIs a problem in this case?

Unlike secure APIs, the Optus API exposed sensitive customer information and lacked essential safeguards. This made it vulnerable to attackers who could locate it through internet scans.

How could attackers exploit this API?

Without authentication or data isolation, attackers could directly connect to the API and retrieve confidential customer information, bypassing internal security measures.

The second major security flaw in the Optus data breach was that the API was not secured. It therefore granted access to highly sensitive customer data. While the first issue revolved around the API being public facing, the critical problem here was its lack of proper access controls, which allowed unrestricted access to confidential information.

When an Optus customer accesses their account through the Optus mobile app or website, APIs facilitate communication between the frontend and the backend systems to retrieve the necessary data. These backend processes often handle sensitive information to load customer profiles.

In this case, the exposed API provided attackers with direct access to the following types of personal data, which are particularly valuable for identity theft and fraud:

• Driver’s license numbers

• Phone numbers

• Dates of birth

• Home addresses

An analysis of public Domain Name System (DNS) records later revealed that this API was likely public-facing and accessible to anyone on the internet for up to three months.

The third security flaw in the Optus data breach was the use of incrementing customer identifiers. In the digital world, unique customer identifiers—composed of random sequences of numbers and letters—are used to differentiate accounts securely. Best cybersecurity practices dictate that these identifiers should be random and unrelated, to prevent hackers from identifying patterns.

Optus customer identifier: In this case, customer identifiers followed a predictable pattern, differing by an increment of 1. For instance, if one customer’s identifier was 5332, the next would be 5333. Once the hacker gained access to the database, they could write an automated script to retrieve every record simply by incrementing the identifier.

This automated approach accelerated the data theft process, allowing the attacker to exfiltrate sensitive customer data at scale. The predictable design flaw enabled the Optus breach to occur faster and affect more customers than would have otherwise been possible.

Apart from API and customer ID vulnerabilities there were more security problems: In 2018, a coding error weakened access controls on certain Optus domains, making them less secure. Although Optus fixed this issue on its main website in August 2021, it failed to apply the same fix to a secondary website that was accessible on the internet. This secondary domain remained vulnerable until the breach was discovered in September 2022.

This oversight left a significant security gap. Public-facing domains are a common target for attackers, and any unpatched flaw increases the risk of unauthorized access. In this case, the coding error made it possible for attackers to bypass access controls and access sensitive data.

Overlooking secondary or less-visible domains can leave critical vulnerabilities open, which attackers can exploit with ease. Regular audits and thorough testing are essential to ensure that security updates are applied everywhere they are needed.

This lack of proper oversight extended to the secondary domain, which played a key role in the breach. Although the domain was not actively in use, it remained online and unprotected for an extended period. Despite being unnecessary for daily operations, it was neither secured with proper access controls nor decommissioned, creating an easy entry point for attackers to exploit.

Even when not in active use, such domains can still serve as attack vectors if vulnerabilities exist. To mitigate these risks, companies should regularly audit their digital assets, promptly decommission unused domains, or apply the same level of security as active systems.

To prevent data breaches similar to the Optus hack and mitigate the risk of reputational damage, organizations can adopt different security strategies you can find in the following:

The OWASP API Security Project is a regularly updated resource that highlights known API security risks. It is essential for cybersecurity teams to routinely monitor this database to identify and address vulnerabilities that could impact their business. It covers a wide range of potential risks, for example:

• Broken Object Level Authorization (BOLA): Gaps in user access permissions allowing unauthorized data access.

• Excessive Data Exposure: APIs returning more information than necessary, increasing the risk of sensitive data leaks.

• Security Misconfigurations: Misaligned settings or defaults that expose sensitive APIs to attacks.

• Injection Flaws: Attackers exploiting APIs to inject malicious commands or data.

The OWASP API Security Project highlights unauthenticated APIs as the second most common API vulnerability. These APIs do not require a username, password, or any other authentication method to establish a connection, leaving them highly vulnerable to exploitation. This type of weakness played a central role in the Optus data breach.

In some cases, APIs are intentionally left unauthenticated to maintain compatibility with legacy systems or for testing purposes. It’s likely that Optus left its API unauthenticated for similar reasons. However, no matter how critical testing or legacy system requirements may be, deploying any API—whether internal or public-facing—without authentication is a significant security risk.

How to Prevent Unauthenticated API Exploitation

To safeguard your APIs, every connection request should be secured with Multi-Factor Authentication (MFA). MFA adds an additional layer of protection by requiring multiple forms of verification, making it one of the most effective and straightforward ways to block unauthorized access to APIs and user accounts.

Identifying Hidden API Vulnerabilities

An API security policy is only effective if all APIs requiring protection are accounted for. But what happens if your organization is unknowingly exposed by a public-facing API, as was the case with Optus?

Hidden or overlooked APIs are difficult to detect using standard scanning tools. The most effective way to uncover them is through penetration testing to expose vulnerabilities such as:

• Weak authentication mechanisms: Systems accepting plaintext passwords or poorly hashed credentials.

• Exposure to credential stuffing or brute force attacks: Exploiting stolen usernames and passwords at scale.

• API parameter manipulation: Revealing sensitive authentication details in URLs or responses.

In conclusion, the Optus data breach underscores the critical importance of implementing robust cybersecurity measures and regularly auditing digital assets. The failure to secure APIs, enforce proper authentication protocols, and address overlooked vulnerabilities on secondary domains contributed significantly to this incident. By adopting industry best practices, such as those outlined in the OWASP API Security Project, and prioritizing comprehensive security strategies, organizations can safeguard against similar breaches, protect sensitive customer data, and most important maintain trust of their users