Optus data breach — Interim AppSec Thoughts
As builders, developers and engineers,
what can we learn from the Optus data breach?
We’ll focus on the technical controls — potential people and process failures are all speculative at this stage, thus not helpful. I’m writing this up so that for those that are concerned by this potentially happening to their APIs, I can point people to this rather than repeat my thoughts.
What happened?
On 22nd September 2022, Optus via a press release (https://www.optus.com.au/about/media-centre/media-releases/2022/09/optus-notifies-customers-of-cyberattack) started notifying people that they have suffered a data breach incident from a “sophisticated attack”.
It was quickly revealed that it was NOT a sophisticated attack. A customer profile API which was publicly accessible to the internet without authentication. The attacker simply helped themselves to the publicly accessible data.
Put simply,
Optus left a bunch of sensitive identity documents and contact information lying on a table in a public space. Somebody saw it, and decided to simply take pictures of them.
The API was designed to allow querying of a customer’s profile by supplying a contactid which was enumerable. Additionally weak anti-automation controls to prevent bulk API access does not seem to have been put in-place allowing unrestricted bulk querying of the endpoint. From a detection and response perspective, weak logging, monitoring, and alerting practices allowed the attacker to retrieve significant amount of data before a high data usage alert was triggered, alerting Optus to the malicious behaviour.
Example:
$> curl https://api.www>[dot]optus.com.au/customers/{1..40000000}
The attacker simply used the API and perform requests as intended to retrieve the profiles of 10 Million customers (before they were cut off). These profiles contained sensitive information and identity document numbers with enough details to impersonate the person — allowing criminals to take out loans, and perform other activities in their name, potentially leaving the victim accountable for the criminal’s actions.
To recap:
- Internet Exposed API at api[dot]optus.com.au with no authentication.
- API provided access to customer identity profiles and identity document information.
- Any record could be retrieved by providing a
contactidto the API. - The
contactidis enumerable by simply changing the ID reference number. - Weak anti-automation, logging, monitoring and alerting practices allowed bulk collection of the data.
The attacker used the intended API functionality to query all the data that the API can provide. The pictures below shows the attacker telling us exactly that:
Lessons Learnt & Security Recommendations
What can we learn from the breach to help us do better?
Fundamentally, we’re looking towards more robust
authorisation, authentication, and accountability.
Looking at the OWASP Top 10, we see the common mistakes being made:
- Only authenticated & authorised entities should have access to the records
- Authorisation should be applied on a per-record level.
- Records contained extremely sensitive data with less sensitive data
- Enumerable identifiers used
- Lack of anti-automation — rate-limits and bots.
- Misconfigured API endpoint exposed to the internet
A07 Identification and Authentication Failures
- Absence of access control
A09 Security Logging and Monitoring Failures
- Sensitivity of alerting on bulk data access is too low.
- Lack behavioural alerting — uncommon access behaviour ( if bulk data access pattern is common for such sensitive files, there are other systemic and architectural problems to address ).
3 steps you can take to reduce this risk to your APIs
- Ensure that your API is only exposed to the internet if absolutely necessary. If necessary, ensure that all requests made require strong authentication to be provided with each request — API tokens are good, but using certificates or ephemeral tokens such as OAUTH and JWT is better. More guidance can be found at https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#access-control
- Ensure that there are no enumerable IDs that can be used to query data — use UUIDs or similar techniques to generate unique record identifiers.
- Authorisation scopes should be provisioned based on least privilege.
More…
- Design the API to verify authorisation scope on every request.
- Do a threat model to understand the trust boundaries, and potential abuse of the data the API provides. Use this to determine if the data is even necessary. If so, use this to design better API endpoints, or controls to limit access.
- Publicly accessible API with sensitive data should have very low access rates. Set up alerting on any bulk access activity.
- Any bulk access endpoints required should be made via non-internet facing means — eg via VPC peering or VPN access.
For even more comprehensive guidance on other things you can do to keep your API safe, this OWASP Cheatsheet would be a helpful place to start:
- https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
- https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
If you’d like to secure your APIs better, the OWASP API Security Top 10 (https://owasp.org/www-project-api-security/) is a helpful place to start identifying common pitfalls.
My misc 2c…
I believe we need better privacy legislation. Privacy isn’t just about having “something to hide”, but also protecting trust and people from harm. Without strong privacy legislation that is pro-consumer and that it do not allow organisations to “waiver out”, we will continue to see the abuse, misuse and loss of data. Often, with minimal consequences to the organisation, but for individuals, multi-year life-changing impact on their quality of life.
So, if identity verification is required, retention of the primary identity documents details should be made illegal with significant penalties.
As a society, we must start to think about N-th order effects of our actions. In this case, if we need to assume that 10 million Australians have their identity stolen, how will we now “proof” we are who we say we are with certainty?
Can you now take out a loan against the richest people in the country in their name with the now publicly available information? Food for thought.
Update 2024–06–26
The incident is now before the Australian Federal Court by the Telecommunications Regulator ACMA — Australia’s version of the FCC.
The court filing has more details of what happened. If you’re interested, you can find it here: https://www.comcourts.gov.au/file/Federal/P/VID429/2024/3981938/event/31836639/document/2300547
