Optus Data Breach – Why Vulnerable APIs are to Blame

For those that haven’t heard, Optus, the second largest telecom company in Australia, exposed over 11.2 million customer records including names, physical and email addresses, birth dates and, for some, government issued id numbers such as drivers license or passport numbers. Yoikes.Optus hasn’t provided many specific details so far but there’s plenty to consider.

What is known is based on news reports and posts from the attacker under the pseudonym of ‘Optusdata’ on a known data leak forum. The consensus is that the attack involved an API used for testing which was unknowingly exposed to the Internet. If the accidental network exposure wasn’t bad enough, the API lacked any authentication checks. That is, anyone on the Internet could make data requests to this API without providing any credentials or token to prove their identity. There was another issue as well, specifically the lack of unique identifiers. This allowed the attacker to easily request millions of records by simply changing an ID number (reported to be the ‘contactid’), by 1.

Given the collection of issues surrounding this breach, let’s discuss what should organizations do to avoid or at least quickly discover and remediate similar issues. 

Know what you have

To secure something, you must first know what that something is.  “You can’t fix what you can’t see” is the phrase here.  For APIs, this means getting an inventory of APIs  – all of them. The inventory should include the hostname, path/URI and HTTP method for each API, as well as  a classification of all data flowing into and out of each API. By having a comprehensive inventory, security choices move from guesses to data-backed decisions. The OWASP Foundation, a software security international charity, has an API Security Top 10 list of the most important API security issues.  Having an inventory is OWASP API #9 – “Improper Assets Management”.

If Optus had such an inventory, it would have been clear that there was a lack of controls around the attacked API With such knowledge, Optus could have focused resources on shoring up that gap.

Restrict access to APIs 

For  non-production APIs – especially non-production – network access should be limited to only those clients which absolutely need access. 

Given that APIs represent a thin layer over existing stores of data such as databases, all connections to and from the API should be monitored with an API-aware platform. Monitoring needs to not only understand how to interpret API traffic such as REST, gRPC and GraphQL, but deeply inspect the bodies or data payloads of those requests.  Only by deep inspection can more subtle issues like Broken Object Level Authorization (OWASP API #1), Excessive Data Exposure (OWASP API #3) or Mass Assignment (OWASP API #6) be detected. Additionally, monitoring solutions should support policies enforcing which clients should access APIs and be able to alert for situations such as internal APIs having Internet connectivity. Monitoring is OWASP #10 “Insufficient Logging and Monitoring”.

If Optus had API-aware monitoring in place, the exposure of the testing API to public Internet traffic, the lack of authentication and the sending sensitive data to the Internet would have been detected, alerted and responded to by Optus far earlier than a post to a data-leak forum.

Authentication

It’s hard to argue that an API does not need authentication. Perhaps an API of truly public data provided by a government agency might not need authentication but, even in that case, authentication is a lever that can be used to stop accidental or malicious over-use of an API. Authentication tells you who is making requests of your API which is vital to ensuring proper access to the API’s data. 

API architects have many options for authentication of APIs such as OAuth2, JWT, and OpenID Connect. Yet, even these standards can be implemented improperly leading to security vulnerabilities. Testing APIs prior to production (“Shift Left”) and runtime monitoring can discover missing, weak or misconfigured authentication.

If Optus had sufficient API testing in place, the exposed API’s lack of authentication would have been caught early in its development lifecycle. As mentioned above, API-aware monitoring would also alert for APIs lacking an authentication mechanism.

Unique identifiers

Unique or non-guessable identifiers are a common problem in software, not just APIs. However, the problem is compounded in APIs since APIs lack state and generally rely on identifiers or IDs to create, read, update and delete data (CRUD operations). By using IDs that simply increment vs generate randomly, an attacker has only to get a single ID from which they can accurately determine all the previous or next IDs by subtracting or adding 1. For example, let’s say one contactid is 1234. The first thing you do as an attacker is see if 1235 or 1233 works. In the case of Optus, just adding or subtracting 1 from the initially discovered contactid led to another valid contactid. With unique identifiers, attackers are forced to guess or brute-force for additional IDs which is both a time intensive process and quite noisy allowing for easier detection.

If Optus had used unique identifiers for the reported ‘contactid’, the attacker would have been significantly limited in their ability to extract such a large amount of sensitive data.

*** This is a Security Bloggers Network syndicated blog from Noname API Security Blog authored by Matt Tesauro. Read the original post at: https://nonamesecurity.com/blog/optus-data-breach-why-vulnreable-apis-are-to-blame