Last week, T-Mobile revealed that the personally identifiable information (PII) of 37 million of its past and present customers was breached in an API attack. They also shared that the attack had been going on since November but was only intercepted on January 5 by T-Mobile’s security team.
Coverage of the attack was fast, wide-ranging and harsh, as it was T-Mobile’s 8th breach since 2018. (We couldn’t resist posting the creative image (no pun intended), T-Mobile also just agreed to pay $350 million for a 2021 breach. which affected 76 million people.
In its SEC filing, T-Mobile called the attack “malicious” and said data obtained through its API was done “without permission.” However, while T-Mobile provided some information related to this API violation, including specific account data, they did not provide any technical details. Discovering an API attack after the fact – in this case, 41 days and 37 million records later – is simply not enough.
Many questions remain to be answered by T-Mobile about the incident. Was the API known to T-Mobile? Did he need authentication and authorization to use it? Where was the API exposed and what was its business and functional purpose? Without answers to these and other questions, it is difficult to speculate at this time as to 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
- Abuse and misuse of the API
- 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 beyond the sight and control of any API governance and security program. Security teams have no knowledge of these undocumented APIs, including the data they process and their security posture. Commonly referred to as “API proliferation,” this challenge stems from phantom (unknown), zombie (deprecated), and phantom APIs. The recent API breach at Australian telecom provider Optus (which set aside $140 million to cover the costs of the incident) falls into this category.
Abuse and misuse of the API
In this scenario, an attacker gains access to the API with valid credentials and exercises the API as intended, but uses the API transaction results for malicious purposes. In such situations, the API works exactly as it was designed; however, the API designer/developer overlooked the possibility of someone misusing the data they produce. There have been many examples of these types of API misuse, including incidents encountered by LinkedIn, Twitter, Peloton, and most recently the FBI’s Infragard program.
Broken business logic
In this scenario, an attacker gains access to an API, in many cases with their own valid credentials, and seeks to manipulate elements of the API request to expose underlying business logic flaws and produce negative, undocumented, and desired 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 seeks to manipulate an API to gain unauthorized access to data or functions. The documented incidents experienced by Experian, Facebook, Coinbase, and more recently various automakers are good examples of this type of API threat.
Stolen credentials (including social engineering and reverse engineering)
In this scenario, an attacker seeks to access an API using credentials or tokens obtained through malicious means. Once a privileged ID or token is obtained, the attacker will seek 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 the tokens are stored in the plaintext app manifest, to inspecting the traffic of web/mobile applications to detect inadvertent exposures of API credentials, to sophisticated social networks. engineering attacks, where attackers can 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 . Over the past few months, numerous organizations have disclosed incidents related to this type of attack, including Dropbox, Slack, and CircleCI.
Another important lesson from the T-Mobile attack relates 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 looking for weaknesses in the API’s business logic. To spot these threats, organizations also need deep context into API behaviors over a longer period of time. API security attacks are not just one and occur like previous security threats. They occur over long periods of time and involve significant acknowledgment by the attacker.
In today’s ever-expanding and evolving API environments, even mature and highly security-conscious organizations continue to experience API-related breaches. Organizations simply cannot uncover all the potential for abuse and flaws in business logic in development and testing. They need to understand that these threats and gaps in governance will always occur despite their best API management efforts. Now more than ever, organizations need the right API execution protection to immediately detect and block malicious activity when an API is abused, compromised, or under discovery. by an attacker.
If you would like to learn more about Salt Security’s award-winning API Protection Platform, please contact us or request a free API Security Vulnerability Assessment to better understand your API environment.
*** This is a syndicated blog from the Security Bloggers Network of the Salt Security blog written by Nick Rago. Read the original post at: https://salt.security/blog/t-mobile-api-breach-what-went-wrong