The Optus Breach: How Bad Code Keeps Happening to Good Companies

First, let me be clear that I have no insider knowledge. This is my best guess at what occurred, based on publicly available information here and others indicated in references section below.

On Thursday this week, Australia’s second-largest telecom company, Optus, announced it had suffered a major data breach that had compromised sensitive customer information.

Jeremy Kirk of The Ransomware Files has been progressively uncovering details associated to this incident.

Jeremy Kirk on Twitter: "Someone is claiming to have the stolen Optus account data for 11.2 million users. They want $1 million in the Monero cryptocurrency from Optus to not sell the data to other people. Otherwise, they say they will sell it in parcels. #optus #auspol #infosec #OptusHack pic.twitter.com/1eCINue2oZ / Twitter"

Someone is claiming to have the stolen Optus account data for 11.2 million users. They want $1 million in the Monero cryptocurrency from Optus to not sell the data to other people. Otherwise, they say they will sell it in parcels. #optus #auspol #infosec #OptusHack pic.twitter.com/1eCINue2oZ

As details are still emerging, let’s examine the attacker’s tactics, techniques and procedures.

This attack bears close resemblance to Citibank, Molina Health and Signet/Jared Jewelers documented in detail below

Case Files: Attack like its 1999 (Citibank) in 2012 (Signet/Jared jewelers, Molina Health)

What happened?

1. Information suggests that the data was exfiltrated through an unauthenticated REST API endpoint at http://api.www.optus.com.au (which has since been shut down)
2. Essentially anyone in public domain is allowed to send a request asking the server “fetch contact details for Optus customer with contactid=XXXXXXXXX”.
3. Even worse than that, the parameter in question sounds like it was a directly referenced contactid (with predictable sequence) and that it was included in the URL of the request rather than securely placed within the body in a POST request.
4. As a consequence, the attacker was able to enumerate and exfiltrate 11.2 million Optus customers and their personal information which the server duly returned.

What data was exposed?

1. 11.2 million Optus customers have been impacted by this incident
2. As indicated here, the information which has been exposed is their customer’s name, date of birth, email, and the number of the ID document you provided such as drivers license or passport number. No copies of photo IDs have been affected.

Why did this happen?

1. Lack of authorization checks for every user request. Web portals have several channels of communication like the browser, mobile apps, API services, embedded links in an email that trackback to the portal. Are all these paths following uniform authenticated and authorized controls?
2. Even if authorized, are referential integrity checks performed to ensure that the authorized user is checking his/her data within their tenancy control? Let alone the hacker, it seems like there wasn’t any AAA checks to ensure that customers across tenancy domains in a SaaS environment could access or have visibility across all tenants
3. Using direct object references (predictable sequences) : Contact Numbers are retrieved from databases and they obviously have a primary key id that uniquely identifies each of them. Rather than directly passing the contact number into the response object, one can create a transient and random contact-id and cache map to the real contact-id in the scope of an active request. This fundamentally breaks the predictable sequence which further on could have prevented repeated enumeration by attacker.
4. Sending sensitive information in the URL of a request: When in doubt, send parameters within the body of a POST request. This won’t protect you from this type of attack but it makes the flaw slightly less obvious.
5. Lack of API gateway controls, tenancy validation, rate-limiting and request throttling configuration for every API endpoint that directly/in-directly touches sensitive information. If this request was initiated 11.2 million times, there weren’t any controls in place to raise alerts indicating anomalous behavior.

Ironically, this is one of those types of flaws that’s all but impossible for an automated web application vulnerability scanner to find but incredibly easy for even a savvy 10-year-old to discover.

How can such flaws be identified and thereafter avoided?

Is there a human-assisted expert system available to check your specific application belonging to a specific business domain for design flaws that can be exploited?

Yes, such a system does exist. ShiftLeft’s CORE is a platform built over the foundational Code Property Graph that is uniquely positioned to deliver a specification model to query for vulnerable conditions, business logic flaws and insider attacks that might exist in your application’s codebase.

To request a free trial and demo, please signup at https://www.shiftleft.io/request-demo/

---

The Optus Breach: How Bad Code Keeps Happening to Good Companies was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/the-optus-breach-how-bad-code-keeps-happening-to-good-companies-189bb11bcf42?source=rss----86a4f941c7da---4