fbpx


T-Mobile’s API Data Breach: The API Security Reckoning is Here


We are roughly three weeks into 2023, and here we are, contending with the second major API data breach of the year. If this is any indication of how this year will progress, we have some hard questions to answer and hard truths to face.

The latest instance of a massive data breach where APIs were the attack vector was the T-Mobile data breach

On Thursday, January 19th, T-Mobile disclosed their latest data breach that has impacted approximately 37 million of their customers. 

It was only months ago that T-Mobile entered into a $350 million class action settlement that resulted from their 2021 data breach of personal data – that one affecting 77 million of their customers. As part of that settlement, the company committed to spending an additional $150 million to address its cybersecurity gaps.

And yet, here we are, again.

As stated on their website:

“We are currently in the process of informing impacted customers that after a thorough investigation we have determined that a bad actor used a single Application Programming Interface (or API) to obtain limited types of information on their accounts.”

 

That’s a Small Part of the Story


Apparently, the bad actor had access to this particular API for approximately 6 weeks. A lot can happen in that amount of time.

According to their 8-K SEC filing, they stated that the bad actor first retrieved data through the API in question, around November 25, 2022. 

This means that this particular API data breach had a dwell time of more than 40 days, because the hacker had started accessing sensitive data via the API in question, from November 25th, 2022.

Consumers Ultimately Pay the Price 


This unauthorized API access exposed data including names, emails, phone numbers and birthdates as the source of the breach. T-Mobile stated that the bad actor did not obtain all data from every one of the 37 million customers affected. It was specifically prepaid and subscription customers who were impacted; hackers apparently also obtained data including the number of lines on the account and service plan features.

T-Mobile said no social security numbers, credit card information, government ID numbers, passwords, PINs or financial information were exposed in the hack.

But, guess what? That doesn’t really matter.

While the data stolen at T-Mobile is certainly different from more sensitive data such as PII, PHI or account information that is often found in financial services or healthcare organizations, stolen data such as phone numbers and email addresses still pose a threat to consumers, especially if the hacker knows that the information is recent and therefore, likely to be valid, and lead them to more sensitive types of data. For example, the increased risk of identity theft, social engineering and phishing, typically increases as a direct result of data breaches, even if the hacker lacks specifics like passwords or other information that could help them gain additional access. 

The exfiltrated data typically ends up on the dark web, and will be used on other web applications and APIs for months – maybe years – to come.

How Does This Happen?

Lack of API Visibility

For starters, incidents typically happen when there is a lack of comprehensive visibility of an organization’s API inventory. In other words, unmanageable API sprawl. This results in a complete lack of control in a distributed ecosystem. You simply can’t protect what you can’t see.

Here at Traceable, we’ve observed that companies just don’t know how many APIs they have, where those APIs reside, and what those APIs are doing – everything from the number, to how those APIs behave and function, are completely unknown.

This creates an unknown attack surface, and therefore, unknown additional risk.

The process of API discovery must be instant and continuous, and include internal, external, third-party and partner APIs. API types are also important to discover and secure – GraphQL, SOAP, HTTP, RESTful, XML-RPC, JSON-RPC, and gRPC, and more.

Also important, is to be able to filter within API discovery, to find unauthenticated endpoints that return relevant sensitive data in the response.

 

Inability to Determine Use from Abuse

API Abuse has recently become an important topic among security professionals, and for good reason. In the past two years, we’ve seen large scale data breaches happen as a result of APIs being abused in some way.

API Abuse occurs when a malicious party uses an API in a way that was not intended by its original design, such as making excessive requests to a server in order to cause a denial of service attack, or using an API to access sensitive information without proper authorization, which, so far, has been a top method of data breaches recently. 

Addressing API Abuse requires creating baselines for data access patterns per sensitive data type, per API, and per user, over prolonged periods of time to be able to detect sudden surges in access patterns, and be able to identify malicious actors exfiltrating sensitive data within acceptable time.

And according to Gartner, API Abuse attacks are set to double by 2024 – just one year from now. As far as we can tell, the industry is right on track with that prediction.

Detecting API Abuse also involves going beyond an API design analysis. In nearly every major API data breach, such as with Venmo, Coinbase and Shopify, the API was functioning exactly how it was designed. Simply performing a design analysis wouldn’t have yielded enough useful information about potential abuse.

We get it – APIs are difficult to protect. It’s often because malicious API traffic looks normal to other security tools like web application firewalls (WAF). In the Venmo case, one of their public endpoint unsecured APIs allowed a student to scrape 200 million users’ financial transactions. This looked like normal traffic to their security solution. At Coinbase, an improper API validation allowed an attacker to make unlimited cryptocurrency trades between different currency accounts. Again, these APIs functioned how they were designed, and the traffic looked perfectly normal to the organizations’ security solutions.

It’s time to get beyond the status quo methods of detecting and preventing attacks. APIs simply can’t be protected with first generation, one-dimensional, signature-based solutions. API security needs context.

 

Risk Scoring and Detecting Sensitive Data Flows

Given how much sensitive data is transmitted via API, it’s imperative that organizations get a handle on this as soon as possible. 

Organizations must identify the API endpoints that handle sensitive data without appropriate authentication or zero-trust policies implemented. This allows security teams and development teams to prioritize which of your APIs need greater security controls to protect your organization and data from threats or abuse.

Security teams need a sensitive data view, based on specific data sets, such as PCI, PII, HIPAA, SSN, as well as common data types like emails, phone numbers, addresses, and health record per API version. Having this capability is important to track risk, new software versions of existing APIs, or new APIs, which could result in such data breaches.

In addition, assigning a risk score to every API is also non-negotiable. This can be done by identifying which APIs are most vulnerable to abuse by collecting data on runtime details such as sensitive data flows, API call maps, API usage behavior, user details, event details, threat activity levels, and more.

Traceable’s API security solution includes a data lake that brings deep analytics and context to APIs. This helps organizations determine normal use for the APIs containing sensitive data, with the intent of using this information to set proper rate limiting thresholds without blocking legitimate traffic – applying the rate limits based on the analysis of the data in the data lake.


API Security and Zero Trust

The enduring success of Zero Trust is due to its flexibility, focus, and ability to deliver results. Zero Trust architectures use multiple security layers and technologies, such as network and identity access management and user, application, and workload security to protect enterprise assets. These models “trust no one,” assuming adversaries are already present or able to access different parts of the application and infrastructure stack. As a result, systems continuously verify users, devices, and access attempts. 

However, to date, APIs have been largely neglected by Zero Trust models. In addition, digital transformation demands and DevSecOps processes at organizations have created new gaps and vulnerabilities attackers can exploit. 

Expanding Zero Trust security concepts to the API interface and implementation layers ensures that communication services get the same protection afforded to other resources.

Traceable is offering a free webinar on Zero Trust API Access next month. We encourage you to join the conversation, and learn more about how we’re bringing API security to Zero Trust.

 


The Time is Now


T-Mobile attempted to greatly minimize the seriousness of their most recent data breach. They stated that the bad guys didn’t actually get anything sensitive or important, but then in the same 8-K filing say
“We may incur significant expenses in connection with this incident”. 

This has become the common practice – to declare that violating the trust of tens of millions of customers is no big deal, while still acknowledging that these breaches and exploits are bad enough to result in massive costs and damages. Obviously, it can’t be both. It can’t be “not a big problem”and a big problem at the same time.

In T-Mobile’s own words, they state that they discovered the hacker had stolen 37 million user accounts worth of data on January 5th but they stopped the attack within a day. Except, they also acknowledge that they believe the exploit began on November 25th through API abuse. 

This ultimately means that they, in fact, did NOT stop the attack in one day. It took more than 40 days to stop the attack.

This is the disconnect; without API security in place, they don’t even know when they are being exploited.

API security is in a woeful state, around the world and across every industry, agency and organization. For 10 years APIs have been exploding in use, with virtually no guard rails to keep them safe. 

The T-Mobile API breach may seem shocking, but we’re seeing tens of millions of customer accounts get snatched by the bad guys nearly weekly. And yet, most companies are still willfully ignoring this crisis.

The time to act is now.

 


 

About Traceable

Traceable is the industry’s leading API security platform that identifies APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. With visual depictions of API paths at the core of its technology, its platform applies the power of distributed tracing and machine learning models for API security across the entire development lifecycle. Visual depictions provide insight into user and API behaviors to understand anomalies and block API attacks, enabling organizations to be more secure and resilient. Learn more at traceable.ai.