API Security Bypassed Using Multiple OWASP API Threats

Research by the CQ Prime Threat Research Team documents how attackers leveraged multiple OWASP API Top 10 threats including Broken User Authentication (API2), Excessive Data Exposure (API3) and Improper Assets Management (API9) to achieve their end goal. The practice of mixing and matching the OWASP API Top 10 categorized threats to bypass API security is commonly observed in customer environments, and they are eerily similar to the techniques used in the recent Optus Telecom incident where, we believe that four of the OWASP API Security Top 10s were exploited.

These techniques are commonly observed in customer environments, and they are eerily similar to the techniques used in the recent Optus Telecom incident where, we believe that four of the OWASP API Security Top 10s were exploited.

Shadow API Introduces API Security Risk

The incident unfolded as attackers discovered an API used for testing that was unknowingly exposed to the Internet. The exposed API, also known as a shadow or zombie API, did not require authorization or authentication, allowing both Personal Identifiable Information (PII) and Customer Proprietary Network Information (CPNI) to be exfiltrated. Added analysis shows how this series of events maps to four of the OWASP API Security Top 10 vulnerabilities.

Broken Object Level Authorization (API1)

In a public online forum, the Optus attacker mentioned that they enumerated the ‘contactid’ parameter object in the API to get unauthorized access to PII and CPNI data of other customers. This is a classic BOLA attack that has been observed at Fortune 500 customers protected by Cequence in varying volumes and complexity.

Broken User Authentication (API2)

Attackers discovered an unauthenticated REST API endpoint during their reconnaissance. The API was not meant to be exposed to the internet, and therefore was unauthenticated, leading to easy an automated exploit. Cequence has detected and mitigated similar automated attacks in real time for our customers. The majority of these events take advantage of credential stuffing, access token replay and Java Web Token (JWT) farming to initiate the attack.

Excessive Data Exposure (API3)

Attackers on the online forum mentioned that the exfiltrated data contains both PII and CPNI. Ideally, there should be logical separation and data custody controls when accessing customer sensitive data. This is only possible if the organization has access to real time analysis of their API posture which looks out for such exposure patterns. Cequence has successfully utilized API Sentinel to identify and mitigate exposure of our customer’s sensitive data.

Improper Assets Management (API9)

The public information shows that the targeted API was https://api.www.optus.com.au. To discover this API, the attacker may have used a common reconnaissance technique of enumerating the infrastructure by appending API to find unpatched and non-deprecated zombie APIs. As these APIs did not have security controls around them, they were an easy target for data exfiltration. The more common API path structure that development teams use would eliminate the www (api.optus.com.au). Customers are using the combination of Cequence API Spyder and API Sentinel to achieve both an outside-in (attacker’s view) and an inside-out (development view) of their API footprint and associated resources.

Leveraging API Security Gaps to Execute SIM Swapping Attacks?

The CQ Prime Threat Research Team has enough evidence to ascertain that a major factor behind the security event was to execute SIM swapping attack on mass scale. News reports indicate that compensating controls have been added to prevent SIM swapping.

Optus has temporarily paused its online or over-the-phone SIM swaps and replacements, as well as any change of ownership requests, to stop criminals from taking control of accounts. These processes can be completed in-store instead with the appropriate ID.

Using OWASP API Security Top 10 vulnerabilities to execute SIM swapping is not new to the CQ Prime Threat Research Team, having documented similar patterns earlier this year and most recently, in the API Protection Report.

A Fortune 500 telecom was hit with 9 million malicious requests from rotating residential proxies attempting to exploit API1. The attackers were looking to obtain information about a customer account by enumerating whether cell phone numbers could be transferred to an alternative provider’s network. Once the attacker discovered transferable phone numbers, they attempted to impersonate the true account owner and manipulate an employee into transferring the cell number onto a SIM card in the attacker’s possession. From there, the attacker can then take control of the victim’s sensitive accounts by completing SMS based two factor authentication.

OWASP API Top 10 is API Security Table-stakes

These API attacks highlight the need for organizations to take a holistic approach to API protection that expands beyond shifting left and the mentality that OWASP coverage is sufficient. It’s well documented that perfectly coded APIs are susceptible to business logic abuse and automated attacks. Security and development teams alike need to fully understand their entire API footprint and how those APIs – managed, shadow, or zombie, correctly coded or those with errors – can be attacked. Equally important it is the ability to detect and mitigate threats in real time, as opposed to relying on a WAF or other third-party solution.