Breaking Down API Breaches: How Simple Mistakes Lead to Major Security Failures

Over a delightful lunch a fellow software raconteur asked, "What are the biggest API breaches in history?" It is a deceptively tricky question. For example, what makes an API hack a "big" one? Is it the number of people affected? Is it the monetary damage done to reputation or stock price? Or is "big" more about the sensitivity of the data stolen? 

I recalled a few notable incidents off the top of my head: Cambridge-Analytica for one. Strava's public heat maps compromising military bases seems pretty bad, too. And I've lost track of the number of "free credit monitoring" services I'm owed - the go-to fig leaf covering a financial service's unmentionables. 

In 2021, Gartner predicted that APIs would be the #1 attack vector. Cast a search in most any direction and you'll find a collaborating statistic like, "95% of respondents have experienced security problems in production APIs". That sounds like some next-level, scary stuff. 

However, when I reviewed many of the notable API-related security failures of the past decade, what stood out wasn't amazing levels of Mission Impossible-esque sophistication or nation-state sized resources. Rather, there was a surprising amount of failure to do the bare minimum… repeatedly. 

In Net API Notes #241, I will highlight a handful of notable past breeches, perhaps not the biggest of all time, but the ones we're most likely to learn something from. 

A Thicket of Unsecured Endpoints

Optus is an Australian telecommunications company. In 2022, hackers discovered an unauthenticated API endpoint, allowing them to gather names, dates of birth, phone numbers, email addresses, home addresses, passport and driving license details for Optus's 11.2 million customers (although the company claims that number is closer to 10 million). 

In January 2023, a hacker gleaned user information on 37 million T-Mobile customers; according to an SEC filing, the bad actor obtained the data through a single API without authorization. 

Then, as I prepared this piece, two additional companies reported unsecured API breaches: Twilio (allowing hackers to verify millions of Authy multi-factor users phone numbers and account details) and Life360 (400,000 user phone numbers leaked). 

These recent examples are shocking, given how long we've known unsecured endpoints can be a problem. In 2016, for example, the API powering the Tinder app was - you guessed it - unsecured. That same year, the Nissan Leaf's API was found to have "absolutely zero access controls". It doesn't matter if the API documentation isn't published or doesn't exist; security by obscurity is not a viable strategy.

In the Optus case, the company's leadership attributed the oversight to "human error". It also  made vague allusions that the endpoint security (or lack thereof) was to "facilitate fast digital collaboration" between external companies. If I squint hard I can kind of see that line of thought. However, no rush to production for a marketing effort or time-sensitive partnership opportunity is worth the $140 million in estimated financial impact that this case had. Endpoints - internal or external - should be authenticated, rate-limited, and monitored for abnormal behavior.

This category of API security failures seems to be an example of OWASP's Broken Authentication API threat, with a dash of Unrestricted Resource Consumption. 

Like Granting Someone Commit Access And Never Doing a Code Review

It is important to ensure API requests are authenticated. The next step is to ensure that those authenticated users are authorized to perform the action intended upon only the resources they have can access. 

In 2018, USPS had a service called "Informed Visibility". It was meant to provide real-time tracking data to businesses and advertisers. However, any logged-in user could query the system for account details with a few tweaks - even if those details belonged to other users. Those details included email address, username, user ID, account number, street address, and phone numbers. Many of the API's endpoints also accepted "wildcard" parameters, returning all records for a wider set of terms. Abusing this API with a wildcard could return, for example, everyone on your street expecting a delivery that day - a porch pirate's dream come true. 

Similarly, John Deere equipment owners also got a rude surprise in 2021. A security researcher discovered that anyone having completed an authentication step and obtaining a particular cookie, could "expose any vehicle or equipment owner's name, physical address, and equipment GUID".

The flaw impacted 60 million USPS user accounts and took over a year to fix. I'd consider it an example of OWASP's Broken Object Property Level Authorization, where improper authorization controls lead to excessive data exposure. The John Deere case was also an example of Unrestricted Resource Consumption, as a remote attacker could easily enumerate an account username with no observable rate limit.

Authorization is more complicated than authentication, in part because it must be performed at the code level. Detection of whether the ID of a given object or structure has been manipulated is not trivial. A simple approach is to heavily prefer using random and unpredictable values for identifiers. But a more robust solution is to apply authorization mechanisms to the structures accessed by the API. 

The Sinister, Slippery Slope of "Working As Designed"

Suppose that you've provided appropriate authentication and authorization for your API endpoints. There's still a chance that an API "working as designed" causes a security incident.

In 2019, Venmo's API was designed to simplify retrieving payment descriptions - when a payment took place, the amount, any memo details, and to whom. However, few users understood those pieces of data were available to anyone. Curious, a computer science student pulled nearly 200 million transactions and, in the process, discovered descriptions describing a host of private activities - including illegal drug activity.

Venmo is alleged to have known about the problem for a year and was a deliberate choice on the company's part. Venmo users entered the description. The API "functioned as intended". This usage of the Venmo API wasn't a breach, per se. However, Venmo's problem affecting tens of millions was a lack of imagination - an exploration of how this information could be manipulated by others and used for subsequent social engineering attacks.

Eva Galperin is the Director of Cybersecurity for the Electronic Frontier Foundation (EFF) and the Co-Founder of the Coalition Against Stalkerware. She has long been vocal about companies needing more imagination to anticipating how their technology might be misused, particularly against vulnerable populations. She emphasizes that companies often lack foresight in considering the potential for their tools to be exploited for harmful purposes, such as stalking, harassment, or other forms of abuse. This oversight can lead to severe consequences for individuals already at risk.

Unfortunately, "use more imagination" is an aspiration, not an executable plan. What is more tactical is participating in threat modeling and developing abuse scenarios. To be clear, that is not a tool you buy or automation you apply. That is a dedicated body of work that involves compiling a comprehensive list of threats and the careful creation of strategies to mitigate them. That means engaging with diverse stakeholders, particularly vulnerable groups who best understand those threats. To get started, check out OWASP's cheat sheet introduction to threat modeling. 

AT&T recently revealed that hackers stole records of nearly all the numbers used in customer's calls and texts. This was not an API breach, but many people's lackadaisical reaction to the announcement still troubled me. "So what," the apathetic, unimaginative response goes, "if some hacker sees I don't call my Mom as much as I should?" Someone who has performed basic threat modeling knows a relationship between a person and a medical provider, help hotline, or their workplace reveals significant, intimate details - details that can subsequently be abused.

Where to Go From Here

Security can be an intimidating prospect. It can feel overwhelming even knowing what to approach first. Developing an API security point of contact, cataloging and maintaining an inventory of internal and external APIs, and refining collaboration touchpoints may all field orthogonal to "normal" API development work. 

I've mentioned it several times already, but definitely spend some time with the OWASP API Security Project. They have descriptions and recommendations to help developers avoid authorization and authentication issues, among other things. If you are using OpenAPI, an OWASP API Security Ruleset can be run with Spectral to identify critical vulnerabilities. APICheck is another open-source tool by OWASP that scans an API for critical vulnerabilities (although the lack of recent commits is a yellow flag). Cloudflare also claims to have its own API security tool, but I have no firsthand experience with it. 

Thankfully, as demonstrated with some of the examples I've mentioned, there are some highly straightforward places to start. Creating an API description for each API using a standard, such as OpenAPI, and developing a process to get a second pair of eyes goes a long way toward uncovering potential authentication and authorization shortfalls. Description development with security professionals, those versed in threat modeling, will also answer the question,  “What’s the worst that can happen?”

Milestones

• Postman has ended its support for its JSON Schema team, dismissing five folks working on JSON Schema specification and tooling full time for over two years. <sad trombone noises>
• Gartner published its 2024 Hype Cycle for APIs. Unfortunately, that content is paywalled, and if you have to ask how that costs, you probably can't afford it. However, some general insights are available from the publication's announcement. 
• Redocly announced support for Arazzo, the new API workflow specification, in their roadmap.
• This is probably a bug-a-boo that impacts only me, but SerpAPI changed its API behavior without warning within the last week, breaking one of my API job analysis scripts. Seriously, clearly communicating a change with significant lead time is like "API Ops 101" stuff. If I wasn't swamped with other things atm, I'd be taking my business elsewhere. Now, I need to figure out when to schedule rewriting what was broken. 

Wrapping Up

It is hard to believe it is almost August already. I'm off to ponder future newsletter efforts at the softball tournaments. If you'd like to ensure you receive what will come, consider signing up. 

Already signed up to get email updates? Sharing something you've found useful with your peers is also another way to support the effort. Finally, if you're in a position to financially support the newsletter, you can upgrade your signup to a paid subscription for as little as $8 a month - the same price as a couple of ballpark glizzies and soda. 

That's all for now. Till next time,

Matthew [@matthew (Fediverse), matthewreinbold.com (Website)]