T-Mobile API Breach: Playing the Victim
I’m not sure what is less surprising, that a big company got hacked or that they are trying to play the victim. The headline is that T-Mobile acknowledged that data on roughly 37 million customers was stolen. The breach resulted from a “bad actor” abusing an API to gain access to the data.
First, let’s acknowledge that APIs have become fundamental to application architecture. It’s how microservices are stitched together and how broader systems communicate. If it’s been built with modern development practices, it’s built on APIs. Thus, securing APIs should be a priority of application security.
Yet, we still live in a build-now, secure-later (if ever) world. So organizations few and far between consider API security on par with application scanning, and it’s not like all organizations have mastered application security scanning. API security is an emerging discipline, which means we’ll continue to have high-profile breaches due to vulnerable APIs.
We must accept that API security just isn’t important enough—yet. Our friends at OWASP published a cool Top 10 API attacks list back in 2019, but it hasn’t been updated since. It’s just not urgent, apparently, though we have heard there is an update to the Top 10 API attack list coming any day now. That falls into the category of a day late and a dollar short.
I guess I’ve been doing this too long, because none of this is surprising. Nor will it be surprising when security teams struggle to find the budget to provide some measure of security for the thousands of APIs a typical enterprise publishes.
API security should be a priority. Even amongst lots of priorities. You’ve been warned.
##Abuse
I want to circle back around to T-Mobile and the industry spin in general. The SEC filing explaining the attack is instructive. “The API abused by the bad actor does not provide access to any customer payment card information (PCI), social security numbers/tax IDs, driver’s license or other government ID numbers, passwords/PINs or other financial account information, so none of this information was exposed.”
The bad actor abused the API. Not that we left the keys in the car and the ignition running and the bad actor made off with it. They clearly are trying to turn the tables and play the victim. Sorry, I don’t buy it.
Yes, the bad actor did take advantage of a vulnerable system and broke the law. That’s wrong. But trying to position the attacker as an “abuser” tries to get us to empathize with T-Mobile. They’ve been victimized, and it’s not their fault, right? It’s not just T-Mobile; many technology attacks are framed as “abuse.” This framing numbs us to the real abuse that happens between people every day, and it pisses me off.
I look forward to a broader postmortem from T-Mobile about the attack, but from what they’ve revealed so far, it seems that T-Mobile didn’t have basic protections for an API published to the world. It doesn’t seem that the attacker did anything particularly novel. T-Mobile left the door open and the attacker walked in and looted the place.
##Nothing Changes
Full disclosure: I’m a T-Mobile customer and have been for many years. I’m not thrilled that my data was stolen. I expect better from companies I do business with. But does that mean I’ll cancel my account tomorrow and run to AT&T or Verizon? Nope, I’ll stay right where I am.
And maybe once the class action lawsuits run their course, I’ll get a free month or two of service. Because that’s the way things go. Poor protection, data breach, public relations crisis, public mea culpa, security theater—send a trinket to the customer, wash, rinse and repeat.
Cynical? Yes. True? Also yes. Maybe this wakes up a few companies to the hazards of publishing APIs without proper tooling and protection. But probably not.
