Top 10 API Breaches in 2024, Part I

Until recently, finding information on the latest API breaches was like plowing a 20-acre field with a pocket knife. But here we are, not even at the end of the year 2024, and there are already tons of publicized accounts of API incidents.

Organizations have become more transparent about this topic. That’s at least one of the reasons why now we have access to much more information about the latest API breaches than before. And that’s good because that way, we can learn better how to stop perpetuating the same API security mistakes and oversights over and over again.

With that in mind, we present to you the first part of our list of top 10 API breaches in 2024. This part covers three incidents, the second will cover three, and the third four. At least, that’s the plan.

One note: Our selection of breaches is based on the availability of technical details. The more interesting technical information available, the higher the chances of including an API breach in our list.

10. The Trello Data Exposure: A Public API is a Mixed Bag

Trello is a work management and collaboration tool under Atlassian’s umbrella.

The cybersecurity community learned about the Trello data exposure in January 2024, when a hacker who went by the alias of “emo” offered scraped data of over 15 million Trello users on a hacking forum.

The data exposure happened through a public REST API, which didn’t require a Trello account or any form of authentication to return a Trello user’s information. The API allowed you to request data for any Trello user based on their ID or username using the GET method.

If you had a Trello account and requested your own profile information, the API returned your email address along with public information like username and member type. If you requested someone else’s profile information, regardless of whether you were a Trello user or not, the API returned only public information, meaning the user’s email address was excluded from the API response.

So far, so good. But there was one problem. The Trello API documentation did not state that an email address could be used as a path parameter, more precisely, an identifier. Yet, if you tried to request a Trello user’s profile information using a random email that didn’t match any Trello user’s profile, the API returned a 404 (not found) response code instead of 400 (bad request).

The implication was that the API accepted email as a good input but didn’t find any user with that email address in the database. So, if you had an enormously large list of email addresses, chances were that at least some of them would belong to Trello users. And if there were such email addresses, you could request their profile data and link information such as full name to specific email addresses.

That’s exactly what emo did. Upon noticing that you could use an email address to query the API for any Trello user’s data, the hacker created a list of 500 million email addresses.

Emo queried the API using the list to check for which email addresses it would return user information, which allowed the hacker to map them to Trello users’ full names and other information.

The API rate limited the number of queries a single IP could make. However, emo used rotating proxies, which enabled the hacker to query the API uninterruptedly by continuously changing IPs.

Since limited Trello user data was already publicly accessible, the problem wasn’t that emo scraped it. The real issue was that the API allowed someone to associate public Trello user data (full names) with private data (email addresses).

And when email addresses are combined with information like full names, they pose a privacy risk. Hackers can use them in social engineering attacks and for doxxing, which is why the Trello API incident was considered a security incident in the first place. The API was vulnerable and exploitable in the sense of allowing anyone, including external (unauthenticated) users, to link public to private information.

In terms of the OWASP Top 10 API Security Risks, the Trello API vulnerability falls under the API1:2023 Broken Object Level Authorization category.

The reason is that the API allowed you to use an email (again, a private piece of information) as an identifier that authorizes you to access Trello user information, even though it should’ve accepted only a Trello ID or username. That led to a privacy risk and opened the gates to more severe attacks, such as phishing, which could threaten the safety of other valuable private information.

9. The Cox Communications API Breach: Millions of Modems at Risk

Cox Communications is one of the top cable, telecommunications, and internet service providers in the United States, with millions of residential and business customers.

In June 2024, the prominent ethical hacker Sam Curry disclosed an API vulnerability that made millions of Cox’s modems remotely exploitable.

Cox included a support service that allowed its agents to remotely manage customer devices, such as modems, through the TR-069 protocol. Curry discovered that this service relied on an API. Upon investigating a main.js file, he found over a hundred API calls that had the endpoint /api/cbma/ in common.

Since it looked like every important remote management functionality was carried out through this API endpoint, Curry tried to find a way to exploit it.

The hacker discovered a landing page with the API documentation containing all the API routes, but he couldn’t load it. The reason was that the /api/cbma/ endpoint served as a reverse proxy, which included a rule that switched routing for static resources. That meant that static resources were routed through the base URI instead of the API endpoint.

Curry had to circumvent this rule to load static resources through the API endpoint. He achieved that by automatically appending the URL-encoded symbol %2f to the .js extension in a great number of POST and GET requests.

After loading the documentation, Curry found the API routes that seemed most relevant to interacting with customer devices and accounts. Then, he searched for unauthenticated API endpoints among them.

Unfortunately for Cox, Curry successfully discovered a bunch of endpoints lacking authentication. Moreover, he learned that he could query them successfully even though he lacked authorization.

In other words, Curry could play a tech support agent without any authentication or authorization whatsoever. If the query didn’t work on the first try, Curry would replay the same API request multiple times, and the vulnerable API would eventually return the customer’s device or account information.

Among others, the API allowed the hacker to access sensitive information like the physical addresses of FBI offices that were using Cox’s modems.

In addition, Curry could access any customer account and device information and modify accounts and devices just by using customer names, account IDs, or MAC addresses. That could lead to a remote code and arbitrary command execution as well as a complete account takeover.

The Cox API security flaws fall within two OWASP API Security Top 10 categories: API2:2023 Broken Authentication and API5:2023 Broken Function Level Authorization.

The first one is obvious: The Cox API included unauthenticated endpoints. The second, BFLA, is because an external, unauthorized user could act as tech support, that is, an agent with privileged (administrative) access and permissions.

8. The SOLARMAN API Vulnerabilities: I’ve Got the Power

SOLARMAN is a prominent PV (photovoltaic) monitoring and management platform that offers a whole range of solar power-related products, from data loggers to module PV optimizers to smart meters.

According to some estimations, its products—used in major solar power projects in China, Singapore, Algeria, and Malaysia—are involved in about 20% of the world’s solar power production.

In addition to producing solar power-related equipment, SOLARMAN also allows its partners— companies like Deye, the widely known inverter manufacturer—to use its infrastructure components, such as data centers, and the platform’s services for their own needs, products, and customers. The latter implies that APIs are the necessary element making this interconnectedness possible.

In August 2024, security researchers / ethical hackers from Bitdefender disclosed severe vulnerabilities in two SOLARMAN API endpoints.

One of the endpoints, /oauth2-s/oauth/token, allowed customers to obtain a JWT (JSON Web Token), but the problem was that the server didn’t verify the authorization token’s signature.

A JWT consists of three parts: header, payload, and signature. The purpose of the signature is to ensure data integrity. More precisely, a signature verification guarantees that the data transmitted in the JWT stays intact.

If the JWT signature verification is missing, hackers can tamper with and forge the JWT. For instance, you can change the user identifier (=subject) in the payload to point to another user and send a request with the forged JWT.

If the API responds with success and returns another user’s data, you’ve evaded the existing authentication mechanism. That way, you can potentially gain unauthorized access and complete control of any other user’s account.

That’s precisely what the ethical hackers could do by abusing the vulnerable /oauth2-s/oauth/token API endpoint: a full account takeover of any SOLARMAN’s partner business or end user account.

As an illustration, this vulnerability threatened all of Deye’s customers. After gaining unauthorized access, hackers could change the way the Deye inverters interact with their environment and wreak havoc on the power grid.

The other API endpoint, /group-s/acc/orgs, returned unfiltered organization data. In other words, it suffered from excessive data exposure.

When the researchers queried an organization’s data, the API returned sensitive information—such as phone numbers, admin names and IDs, and email addresses—in its response.

Phone numbers and email addresses fall within private information, and private data exposure, as we’ve seen a thousand times before, can create all kinds of additional security, as well as business integrity and reputation problems.

In the OWASP API Security Top 10 nomenclature, the first of these two API vulnerabilities falls within the API1:2023 Broken Object Level Authorization category and the second within the API3:2023 Broken Object Property Level Authorization.

It’s worth noting that excessive data exposure used to be a separate vulnerability on the OWASP API Security Top 10 2019 list. However, in the latest 2023 version of the most severe and frequent API security risks, it’s combined with mass assignment to make up a single API security vulnerability category.

Remain Alert and Stay with Us

In this part, we analyzed three API security incidents. We saw that the most common security flaws were related to authorization. Right next to them were authentication issues. No wonder almost half of the OWASP Top 10 API Security Risks – 2023 are authorization and authentication vulnerabilities.

Stay tuned for the next part of this three-piece series on the top 10 API breaches in 2024!

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.