Optus, the second-largest telecommunications company in Australia, has experienced an API security incident – and it might come with a $1 million price tag. That’s the amount being demanded by the attacker who has breached Optus and claims to hold more than 11 million user records. The hacker has threatened to sell the data in parcels, if Optus doesn’t pay within a week. But wait – it gets worse! The hacker has now contacted Optus customers directly demanding that they pay $2K AUD, or their PII will be sold for “fraudulent activity within 2 days.”
How could this type of breach occur? The widely acknowledged cause – unauthenticated APIs.
Unauthenticated APIs (or open APIs), the purported culprits in this incident, represent one of the most common API security exposures. According to the OWASP API Security Top 10, broken user authentication constitutes the second biggest API vulnerability. Bad actors know they can easily exfiltrate data from unauthenticated APIs, making this vulnerability a key target.
Like organizations in many other industries, Telcos and ISPs have begun to broadly adopt APIs to drive digital transformation initiatives. According to a recent report published by Acumen Research and Consulting, the global telecommunications API market will experience a CAGR of more than 20% from 2022 to 2030. The report attributed the growth to increasing competition across telco organizations to provide improved and enhanced services for their customers.
APIs now exist in every IoT device, from security cameras to video doorbells. They have become ubiquitous. In our work with companies, we frequently see IoT devices suffer this kind of breach. APIs may be unauthenticated, as in this case, or they could be using very simplistic authentication, such as the default basic authentication, which can be easily breached.
Because of the increasing adoption of such IoT devices in the telecommunications sector, telcos and ISPs must be aware of these threats. In addition, they need to ensure that everyone within their organizations understands different security requirements and that teams communicate with each other about security steps that have – or have not – been taken in each stage of the API design, development, and deployment process. Very often, API development straddles multiple people and groups, and reuse is a conscious design principle. However, sometimes when an API is used into a new sequence, an earlier security step in a previous API isn’t included.
ISPs require strong authentication to protect their devices and their data. Moreover, the risk extends far beyond data exfiltration. In addition to exploiting authentication vulnerabilities to take over user accounts, attackers can also gain access to all the data that a device is entitled to access. For example, attackers could control the whole network if a telco’s network equipment can be exploited. That’s a huge risk!
Human error nearly always plays a role in breaches, but it’s not just a case of individuals being more careful. APIs touch all areas within an organization, not just development. Typically multiple teams share ownership across APIs. Often miscommunication (or incomplete communication) can lead to problems. For example, infrastructure teams may assume that the development team has already managed authentication requirements. They may believe that the API has already gone through a security review when, in fact, it hasn’t.
Unfortunately, miscommunication is fairly commonplace. Moreover, in the case of Optus, it appears that the network team unintentionally made a test network available on the Internet, which could then be easily exploited.
Like many other API breaches, the Optus security incident highlights the importance of dedicated API security.
The proliferation of APIs within telco and ISP environments has created new and complex security risks that cannot be fully defended with existing regulations and traditional security solutions. To protect this growing attack surface, telcos must:
To identify potential API threats, organizations must understand how APIs normally operate within their environment. Having this insight will enable telcos to quickly identify and speed threat response before a bad actor accesses their critical user data…or worse.
Dr. Anton Chuvakin, security advisor at Office of the CISO, Google Cloud, joined our recent API Security Summit. Dr. Chuvakin’s session – co-hosted by Salt Security's Michelle McLean – provided an in-depth discussion on why API security has become a “now” problem.
The monetary growth opportunities promised by APIs are immense, but to harness them, CISOs must ensure the protection of their APIs.
With the industry moving to microservices and API-driven applications, new security threats and attack vectors have emerged. The PCI Security Standards Council has worked to address these threats in its newest PCI DSS 4.0 standard.