T-Mobile API Breach — What Went Wrong?

Last week, T-Mobile disclosed that the personally identifiable information (PII) of 37 million of its past and present customers had been breached in an API attack. They also shared that the attack had been going on since November but was only caught January 5 by T-Mobile’s security team.

Coverage of the attack has been swift, far-reaching, and harsh, as this represents T-Mobile’s 8th breach since 2018. (We couldn’t resist posting the cheeky creative image from security influencer Brian Kreb’s blog on the incident.) Adding salt to the wound (no pun intended), T-Mobile has also just agreed to pay $350 million over a 2021 breach that affected 76 million people.

In its SEC filing, T-Mobile called the attack "malicious" and stated that data attained through its API was done "without authorization.” However, while T-Mobile has provided some information related to this API breach, including specific account data, they have provided no technical details. Uncovering an API attack after the fact — in this case, 41 days and 37 million records later — is just not good enough.

Many questions remain to be answered by T-Mobile about the incident. Was the API known to T-Mobile? Did it require any authentication and authorization to use? Where was the API exposed, and what was its business and functional purpose? Without these and other questions answered, it is hard to speculate at this time exactly how the T-Mobile API was exploited by the attacker.

However, in general, most API data breaches are usually the result of one or a combination of four different attack scenarios:

• Lack of API visibility and governance
• API abuse and misuse
• Broken business logic
• Stolen credentials

Lack of API visibility and governance  

In this scenario, an attacker takes advantage of an exposed API whose existence is outside the view and control of any API governance and security program. Security teams have no knowledge about these undocumented APIs, including the data they handle and their security posture. Commonly referred to as “API sprawl”, this challenge derives from shadow (unknown), zombie (outdated), and ghost APIs. The recent API breach at Australian telecommunications provider Optus (who has set aside $140 million to cover costs from the incident) falls under this category.

API abuse and misuse  

In this scenario, an attacker obtains access to the API with valid credentials, and exercises the API as designed, but uses results of the API transactions for nefarious purposes. In such situations, the API functions exactly as it was designed to do; however, the API designer/developer overlooked the potential for someone to abuse the data it produces. There have been many examples of these types of API misuse, including incidents experienced by LinkedIn, Twitter, Peloton, and more recently the FBI's Infragard program.

Broken business logic  

In this scenario, an attacker obtains access to an API, in many cases with their own valid credentials, and looks to manipulate elements of the API request to expose underlying business logic flaws and produce a desired, undocumented, negative API behavior. The most common type of threat associated with this type of API vulnerability is BOLA, or Broken Object Level Authorization, which is the number one API threat according to the OWASP API Security Top 10 list. Here an attacker looks to manipulate an API to gain unauthorized access to data or functions. Documented incidents experienced by Experian, Facebook, Coinbase, and most recently by various car manufacturers are good examples of this type of API threat.

Stolen credentials (including social engineering and reverse engineering)

In this scenario, an attacker looks to gain access to an API using credentials or tokens obtained through nefarious means. Once a privileged credential or token is obtained, the attacker will look to leverage the API to exfiltrate data or compromise a service. Credentials or tokens can be obtained in a variety of ways, from reverse engineering a mobile app to see if tokens are being stored in the app's manifest in clear text, to inspecting web/mobile app traffic for inadvertent exposures of API credentials, to sophisticated social engineering attacks, where attackers may use elaborate schemes to gain targeted access to a victim's system and connected file systems and source code repositories where API tokens and credentials may exist.  Many organizations in recent months have disclosed incidents related to this attack type including Dropbox, Slack, and CircleCI.

Another important lesson from the T-Mobile attack pertains to the characteristics of today’s API attacks. API attacks take time. Bad actors spend days, weeks and even — as in the case of T-Mobile — months probing for weaknesses in API business logic. To spot these threats, organizations also need deep context into API behaviors over a longer period of time. API security attacks aren’t just one and done like previous security threats. They occur over lengthy periods of time and involve significant reconnaissance on the part of the attacker.

In today’s expanding and ever-changing API environments, even very security wise and mature organizations continue to experience API-related breaches. Organizations simply cannot uncover all potential for abuse and business logic flaws in development and testing. They must understand that these threats and lapses in governance will still occur despite their best API management efforts. Now more than ever, organizations must have proper API runtime protection in place to immediately detect and block malicious activity when an API is being abused, compromised, or is under reconnaissance by an attacker.

If you’re interested in learning about the award-winning Salt Security API Protection Platform, please contact us or request a complimentary API Security Gap Assessment to better understand your API landscape.