API security attacks aren’t just one and done like previous security threats. To spot these threats, organizations also need deep context into API behaviors over a longer period of time. Bad actors spend days, weeks and even – as in the case of T-Mobile – months probing for weaknesses in API business logic. Many organizations in recent months have disclosed incidents related to this attack type including Dropbox, Slack, and CircleCI.Īnother important lesson from the T-Mobile attack pertains to the characteristics of today’s API attacks.
#Tmobile breach code#
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. Once a privileged credential or token is obtained, the attacker will look to leverage the API to exfiltrate data or compromise a service. In this scenario, an attacker looks to gain access to an API using credentials or tokens obtained through nefarious means. Stolen credentials (including social engineering and reverse engineering) Documented incidents experienced by Experian, Facebook, Coinbase, and most recently by various car manufacturers are good examples of this type of API threat.
Here an attacker looks to manipulate an API to gain unauthorized access to data or functions. 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. 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. 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. 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. 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. 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. Commonly referred to as “API sprawl”, this challenge derives from shadow (unknown), zombie (outdated), and ghost APIs. Security teams have no knowledge about these undocumented APIs, including the data they handle and their security posture. 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.
However, in general, most API data breaches are usually the result of one or a combination of four different attack scenarios: 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. Many questions remain to be answered by T-Mobile about the incident. Uncovering an API attack after the fact – in this case, 41 days and 37 million records later – is just not good enough. 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.
0 kommentar(er)
