Top 5 API Security Incidents of 2023

The vast majority, 92%, of surveyed organizations experienced at least one API security incident in the last 12 months, reports TechTarget in “Securing the API Attack Surface.” A joint Traceable and Ponemon Institute research, “2023 State of API Security: A Global Study on the Reality of API Risk,” states that 60% of 1629 organizations suffered an API-related breach in the last two years.

And yet, public information on API incidents, particularly technical details, is scarce. That’s understandable; no one wants to disclose information that jeopardizes their business secrets or affects how others see them. Hence, we learn about API incidents mostly when they become data exposure debacles, lead to painful financial blows, or cause prolonged business disruptions.

But we must talk openly about API exploitation. The principal reason is not to be judgmental but to learn from mistakes and strive not to repeat them. In this review of the top 5 API security incidents of 2023, you’ll learn about real-life abuse of APIs and the effects it can have on organizations and businesses.

5 Major 2023 API Incidents

API security breaches in 2022 caused losses worth $12–$23 billion in the US and $41–$75 billion globally. Among the attacked businesses were renowned names such as Twitter and FlexBooker. The Twitter API breach leaked the data of 5.4 million users, and the FlexBooker API breach leaked the data of 37 million users, including (incomplete) credit information.

As you’ll see, not much has changed in 2023.

Our list of API breaches focuses on incidents where threat actors, not security researchers, exploited API vulnerabilities and caused actual harm to organizations and users. So, without further ado, we present you the top 5 API security incidents of 2023.

1. T-Mobile

Unfortunately for the company, T-Mobile has become notorious for security breaches. The telecom giant has suffered as many as eight major security incidents since 2018.

The last incident happened in January 2023, exposing the personal data of about 37 million customers (about twice the population of New York).

The company stated that the exposed user data was limited to names, birthdates, billing and email addresses, phone and account numbers, number of lines, and plan features. It stressed that sensitive data such as passwords, social security and ID numbers, and credit card information was not leaked.

However, publicly exposed customer data is always a risk for users, even when no financial and other sensitive details are leaked. For instance, in the T-Mobile case, the attackers or any third parties buying the stolen data can use the stolen information to launch phishing campaigns, attempt account takeover, or even commit identity fraud.

As is often the case with API security breaches, T-Mobile didn’t disclose any details of the cyberattack apart from the following:

• The threat actor gained unauthorized access to the customers’ data through a company’s API
• The attack started on November 25, 2022, but was detected about one and a half months later, on January 5, 2023

The attackers might have used an unlisted API—an API vulnerability called improper inventory management—to access data sources. Considering that T-Mobile mentions unauthorized access, and that authorization issues are among the ten most common and severe API security risks, the threat actors could have exploited an unpatched authorization vulnerability.

2. JumpCloud

JumpCloud is a directory service provider that organizations use for device, identity, and access management. In June, the company discovered it was a victim of a cyberattack.

Thorough research by JumpCloud, CrowdStrike, and SentinelOne led to the conclusion that the attack was carried out by the notorious North Korean state-sponsored hacking group Lazarus. More precisely, CrowdStrike researchers believe a Lazarus subgroup named Labyrinth Chollima stood behind the cyberattack.

Since Lazarus is known for attacks on cryptocurrency entities, security commentators thought the ultimate target wasn’t JumpCloud. Instead, the attackers likely used the company to get to JumpCloud customers operating in the blockchain, that is, the crypto ecosystem.

If you were wondering why cryptocurrency companies, the answer is simple: Lazarus steals crypto to fund its own endeavors.

The attackers used spear phishing to trick a JumpCloud software engineer into downloading malicious code. That gave them a privileged (developer) level of access to the JumpCloud environments.

Thanks to the privileged access, the threat actors performed a database injection that allowed them to target specific customer devices, instructing them to download malware. Based on the JumpCloud official portrayal of the incident, the attack affected fewer than ten devices of five organizations.

Upon detecting the ongoing attack, JumpCloud reacted promptly by activating its incident response plan, informing the impacted clients, and notifying law enforcement. The most interesting thing for us is that the company’s very first move was revoking the admin API keys of all its customers, which highlights the importance of considering API attacks in your incident response plan.

Why all customers?

Because, at the time, JumpCloud didn’t know the exact number of compromised clients, it decided to enforce a mandatory API key rotation across the board.

Why API keys?

They must have played a substantial role in the attack campaign. After the threat actors had infiltrated the system, admin or privileged keys would’ve allowed them to manipulate APIs. Since APIs are the connecting link between different systems and services, their manipulation might have eventually led to fulfilling the goal of stealing cryptocurrency.

A comprehensive API key reset is a serious undertaking. It must have disrupted standard day-to-day operations and affected functionalities such as the JumpCloud PowerShell modules, Directory Insights Serverless apps, third-party zero-touch MDM packages, command triggers, and Azure AD SCIM integration. Nonetheless, it was the right move for JumpCloud to protect customers from further compromise.

3. Ivanti

Ivanti is an IT and software company that, among others, develops Ivanti EPMM (Endpoint Manager Mobile), formerly MobileIron Core. This solution helps you manage mobile devices and implement security policies.

In July, the Norwegian NSA (National Security Authority) revealed that threat actors took advantage of a zero-day vulnerability in Ivanti EPMM that enabled them to hack a software solution used by 12 different Norwegian ministries. The involvement of the Norwegian Data Protection Authority suggested that the cyberattack most probably resulted in a data breach.

This Ivanti EPMM vulnerability is known as CVE-2023-35078. It allows malicious actors to access API endpoints remotely without authenticating themselves. If attackers exploit it successfully, they can access personally identifiable information and make changes to servers, such as adding an admin account on an EPMM server.

The vulnerability’s severity rating is defined as critical, but it’s worth noting that Ivanti already released a patch. Since all supported versions of its EPMM are affected by the vulnerability, users must install the patch to avoid security incidents.

Besides the security incident in Norway, the Ivanti EPMM API authentication bypass vulnerability also led to the exploitation of about ten (or fewer) Ivanti customers.

4. Duolingo

Duolingo is a company known for its popular language learning application, which many people try at least once to learn a new language the fun way.

In January 2023, scraped data of 2.6 million Duolingo users appeared on the old version of a dark web hacking forum suitably called Breached. It reappeared later in August on the revamped Breached.

The scraped data included email addresses, personal names, usernames, and other user profile information. The first time it was posted, the data was offered for $1,500. The second time, you could access it for only $2.13.

The malicious actor acquired the data through Duolingo’s API. The API provided access to user information based solely on an email or a username without requiring other verification. It lacked security mechanisms that ensured requests came only from legitimate (authenticated and authorized) users, so it didn’t restrict data access.

What we said means that Duolingo’s API vulnerability was a mix of the API2:2023 Broken Authentication and API3:2023 Broken Object Property Level Authorization (BOLA) security risks.

Suppose you have an extensive list of email addresses. In Duolingo’s API case, you could use an email address as a parameter in an endpoint URL to request user information. If the API responded with the required data, you could tie the email address to a user profile.

That’s presumably how the malicious actor took advantage of Duolingo’s API to create a dataset of 2.6 million users.

Some accounts of Duolingo’s API vulnerability state that the API also gave access to a link that allowed viewing profile pictures. Others say it returned fields showing whether a user had higher than regular user privileges. Yet others claim that the API sometimes returned credit card information.

Even if we ignore the possible leak of credit card info, mass data scraping resulting in exposed emails, phone numbers, or other personal information can lead to serious privacy problems and even regulators launching official investigations.

Besides the apparent threat to privacy, information exposed in this way is problematic because it allows threat actors to build detailed user profiles and target the users in social engineering campaigns.

Duolingo was informed about the scraped data as early as January 2023 but didn’t feel that what happened was a security breach. The rationale behind its attitude was that the scraped data was meant to be publicly available. The sole fact that someone created a dataset with millions of entries instead of a list with several names didn’t change much in the company’s eyes.

However, again, the real problem is that Duolingo’s API gives access to data not considered public, such as email addresses, which can eventually cause actual harm to the company’s customers. From that standpoint, the user data and the API should’ve been protected much better (especially if the API leaked credit card information).

5. Kronos Research

The Kronos Research incident differs slightly from the rest on our list because it’s an API incident in the blockchain industry. It reminds us that no technology, regardless of how advanced, is safe if it relies on under-protected APIs.

Kronos Research is a cryptocurrency exchange that was hacked in November. The attacker stole $26M in cryptocurrency, forcing the company to stop trading temporarily. The attack was carried out through stolen API keys.

Hackers use three methods to steal API keys:

• Reverse-engineering
• Intercepting API requests (man-in-the-middle attack)
• Searching for leaked API keys in public repositories

The last method is the easiest and most common. Malicious actors don’t need to go further than Google dorking and API reconnaissance to find heaps of exposed API keys in public repositories on GitHub and similar platforms.

Since Kronos Research didn’t reveal any details of the cyberattack, we’re left with conjectures that the attacker must have used one of the above three methods to steal some of the company’s active API keys.

With API keys in possession and no adequate authentication mechanisms, hackers can manipulate APIs to perform actions of genuine authorized users. In cryptocurrency trading, by abusing API keys, they can employ techniques such as sell-wall buyouts and price boosting to steal millions in crypto.

Conclusion

Relevant technical information on API security incidents is always hard to find. Nonetheless, you can still construct working hypotheses about what went south that can prove helpful in evaluating your own security posture.

As we’re looking forward to the new developments in API security in 2024, we should learn from the past and try to avoid repeating the same mistakes.

Contact us to learn how Equixly can help you secure your APIs and avoid security incidents. If you’re strategic and methodical, Equixly will suit you just perfectly.

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.