AppSentinels

Learnings from the OptusBreach

AppSentinels
October 13, 2022
Optus Data Breach

An Optus Store displaying apology after the breach was disclosed

Disclaimer: AppSentinels doesn’t have first-hand information about the cause of the Optus breach. This blog is based on information collected from various sources on the Internet. References are available at the end of the blog

Chronology of events

Before we delve into the reasons behind Optus breach, let’s see the chronology of events. Data breach updates being followed up https://twitter.com/hashtag/OptusDataBreach and https://twitter.com/Jeremy_Kirk

 

Cause of the breach

According to various reports, Optus customer data was accessed via an API interface that was not secure. (https://www.computerweekly.com/news/252525513/Optus-breach-casts-spotlight-on-cyber-resilience). Apart from unauthenticated API, there was another serious issue related to easily enumerated ID’s (identifiers). These are foundational controls that were found lacking in the API implementation. 

 

a) An un-authenticated API exposing PII data — An unauthenticated API endpoint exposed via one of the subdomains of the telco was exposing PII data of the customers. This is like gate wild open with a message ‘valuables inside’. Any user on the internet can invoke the API and retrieve data by providing basic information like a parameter. Eg: to get details about a customer with mobile number 1234567890 

 

This attack is called BUA (Broken User Authentication and is number two in OWASP API Top-10 list). 

b) The was another API had another parameter enumeration issue. For eg: parameter UserID were numbered 1, 2, 3,…. The API can be invoked by incrementing the identifier parameter and retrieve details about the User. There were NO checks in the API endpoint to ensure only authorized user is allowed access to his/her data.

 

This attack is called BOLA (Broken Object Level Authorization and is number one in OWASP API Top-10 list). 

What is needed to prevent such breaches

  • Having an inventory of the APIs: You can’t protect what you can’t see. What is needed here is a platform that should discover all the API’s along with other characteristics about the API like authenticated, internal or public, dealing with sensitive info etc. If Optus had such an inventory, they could have discovered earlier that there exist weak APIs with access to sensitive data. OWASP API Top#9 [Asset Management] 

 

  • Authentication of APIs: Leaving an API open to world for anyone to invoke can be catastrophic as Optus discovered the hard way. While every application needs API open to world, such APIs should be carefully validated by the organization. A platform that can provide insight to the customer about such a risk would have helped Optus understand their risk exposure. OWASP API Top#2 [Broken User Authentication] 

 

  • Unauthorized Usage: A platform that can learn how the APIs are invoked and understand the application baseline as well as the user-context would have detected an easy target like allowing a user to change the identifiers and access information about the customers he/she isn’t authorized to use.  

Conclusion

APIs are critical part of your software. Weak APIs can result into massive data breaches like what Optus saw, apart from huge brand and financial losses. Protecting APIs is critical for organizations of all sizes. Look for an API Security solution that provides protection against the gaps described in the paper. 

Related Topics