Top 10 API Breaches in 2024, Part II

This is the second part of our three-piece series on the top 10 API breaches in 2024. We hope you already checked out the first part.

However, note that each part can be read independently. Just like the different seasons of the series “Fargo,” you can understand what’s happening in this part, even if you don’t know what happened in the previous one.

This piece covers three cases in which organizations suffered from multiple API vulnerabilities and security flaws. So, fasten your seatbelt and prepare for takeoff.

7. AnythingLLM: Anything Is Possible When You Find a Vulnerable API

AnythingLLM is an AI assistant developed by Mintplex Labs. As with any other large language model app, it relies heavily on APIs to perform its normal functions.

Between February and March 2024, different ethical hackers discovered they could exploit multiple vulnerable AnythingLLM API endpoints. All three security flaws we’ll discuss here are highly severe vulnerabilities with a base score of over 9.0.

Path Traversal

The first and most serious—with a score of 9.9—was a path traversal vulnerability, allowing threat actors to read or delete arbitrary files in AnythingLLM’s system.

The /api/system/setting-preferences endpoint allowed users to update their logo filename. However, it didn’t include filtering or validation of the name value inputted by the user.

By altering the logo extension, hackers could reference filenames stored in a directory outside of the intended path, such as .db (database) files. On top of that, they could download and delete the referenced files through the /api/system/logo and /api/system/upload-logo endpoints.

Apart from unauthorized access to and deletion of sensitive files, the lack of input validation and filtering could lead to system compromise. For instance, in a likely scenario, attackers could use information obtained from sensitive files to move laterally or escalate privileges.

In terms of the OWASP Top 10 API Security Risks – 2023, this security flaw would fall under API3:2023 Broken Object Property Level Authorization.

Remote Code Execution

The second is a remote code execution vulnerability, with a base score of 9.6.

An ethical hacker discovered they could inject arbitrary commands into the AnythingLLM environment file by sending an appropriately crafted POST request to the /api/system/update-env API endpoint.

More specifically, as a proof of concept, they injected a command into the .env file that executed a new process, touch /tmp/rce, by:

• Adding the command to the payload in the POST request sent to the /api/system/update-env endpoint
• Sending a GET request to the /api/migrate endpoint to trigger the code execution and successfully create a new file called rce (short for remote code execution)

This vulnerability made it possible for attackers to read and modify data available to customers running the AnythingLLM app, as well as stop the service altogether and launch a DoS attack.

It’s hard to determine precisely within which OWASP API Security Top 10 category this security flaw falls and whether it falls within any of them at all. However, since it includes a code injection, we can classify it as a general OWASP A03:2021 – Injection vulnerability.

Improper Authorization

The third AnythingLLM major API flaw—with a base score of 9.1—is an improper authorization vulnerability.

The endpoint /api/v/ allowed an ethical hacker to list namespaces and reset or delete data from AnythingLLM’s vector databases. They could perform these operations without any authorization and permission checks whatsoever.

The hacker was able to:

• List namespaces by sending a POST request to /api/v/tables if LanceDB was the default vector database.
• Delete data by sending a POST request to /api/v/delete-namespace, regardless of the vector database provider. This action affected only the data in a single workspace.
• Reset data for vector databases powered by LanceDB, QDdrant, Chroma, or Weaviate by sending a POST request to /api/v/reset. The reset operation affected all the workspaces within a vector database.

Clearly, this vulnerability could lead to data loss and exposure.

This AnythingLLM security flaw mostly matches API5:2023 Broken Function Level Authorization.

6. Spoutible API Leakage: When the Levee Breaks

Spoutible is a social media platform that came into prominence at the beginning of 2023 as an alternative to X (Twitter).

In February 2024, the renowned cybersecurity expert Troy Hunt disclosed a major API vulnerability in the Spoutible API.

Note, however, that he wasn’t the one who hacked the platform. The information on the API breach was, instead, provided by another person (presumably the real attacker), who sent 207,000 scraped Spoutible records to Hunt.

In addition to public information like name and username—which are not a security concern anyway—the Spoutible API endpoint /sptbl_system_api/main/user_profile_box was returning the following private and highly sensitive user information:

• Gender
• Phone number
• Email address
• IP
• Bcrypt hash of the password
• 2FA (two-factor authentication) secret
• 2FA backup code
• Password reset token

Yes, you read that right.

The Spoutible API required only a username as a query parameter to return all this information. So, as long as you were a regular Spoutible user who knew other Spoutible usernames, you could query the API and receive anyone’s private information unchecked.

Moreover, finding the vulnerable API was ridiculously easy for those using the Spoutible feature Pods. Pods allowed Spoutible users to host and take part in live audio and video conversations. Opening the developer tools in your browser was all it took to see the vulnerable API in action, exposing all the private information for participants in a Pods session.

Let’s leave the other pieces of exposed private information out and focus on how bad the leakage of the following four is:

• Bcrypt hashed passwords

  There’s not a single good reason for any API to return passwords, as Hunt emphasizes, regardless of whether they’re hashed or not and returned to their owners or other users.

  True, bcrypt hashed passwords are safe, but they’re not uncrackable.

  Besides, considering that Spoutible wasn’t even checking the password strength and was allowing six-character passwords, the hashing function didn’t matter that much. No matter how you slice it, there was a decent probability that hackers would crack a good number of weak passwords—the result of a subpar password policy.

• 2FA secret

  The 2FA secret plays the role of a seed (secret key) in generating the OTP. Hence, a threat actor getting the 2FA secret makes the two-factor authentication meaningless.

• 2FA backup code

  The Spoutible backup code was a bcrypted six-digit number. And decrypting it could take only a few minutes.

• Password Reset Token

  A password reset token in the hands of hackers entailed only one thing: account takeover.

  To make things worse, Spoutible didn’t send email notifications when someone required a password reset. That meant that an attacker, or for that matter anyone else, could reset an account password without the account owner having the chance to know that something fishy was going on.

  Yet another problem was that the password reset function didn’t invalidate an active user session—and log the user out—and didn’t show active sessions. That further decreased the probability of a Spoutible account owner noticing that someone was attempting to compromise their account.

This API vulnerability is a clear example of excessive data exposure, which falls under API3:2023 Broken Object Property Level Authorization. Besides jeopardizing private user data, it could lead to a full account takeover.

5. F5’s BIG-IP Next Platform: Multiple API Vulnerabilities

BIG-IP Next is an F5 product that allows customers to manage network and application infrastructure from a central place.

In May 2024, security researchers from Eclypsium revealed their discovery of multiple security issues in the BIG-IP Next platform. Of those, we’ll discuss three API vulnerabilities, two of which already have CVE identifiers.

Among others, F5 is known for its web application and API protection solutions, which makes the whole situation all the more ironic.

OData Injection

The first, CVE-2024-21793, was an unauthenticated OData injection vulnerability with a high severity—score of 7.5—that involved the BIG-IP Next Central Manager API. OData (Open Data) is a protocol, originally initiated by Microsoft, that defines how REST APIs are built and consumed.

This vulnerability occurred in the way the /api/login API endpoint processed OData queries. The vulnerable API endpoint allowed hackers to inject code into the username field that enabled them to:

• Manipulate authentication, more precisely, bypass login
• Obtain sensitive data such as hashed admin passwords
• Escalate privileges (eventually)

The exploit created by the security researchers worked only in an LDAP-enabled environment.

SQL Injection

The second vulnerability, CVE-2024-26026, was very similar to the first one: unauthenticated blind SQL injection. It had the same high severity score of 7.5 and involved the same /api/login endpoint.

The vulnerable API endpoint didn’t sanitize user input, which allowed attackers to craft an SQL payload in the API query that leaked an admin password hash from the database.

With a leaked admin password hash in their hands, attackers could escalate privileges and wreak havoc on an F5’s customer information environment.

Due to the injection part, both vulnerabilities fall within the OWASP A03:2021 – Injection category.

Server-Side Request Forgery

The third BIG-IP Next API Central Manager security flaw is an SSRF (Server-Side Request Forgery) vulnerability.

The security researchers’ exploit contained the following elements:

• Logging in to the BIG-IP Next API Central Manager through the /api/login endpoint
• Obtaining a summary of managed devices through the /api/device/v1/summary endpoint and extracting details about the devices, such as IDs and hostnames
• Obtaining additional details on the managed devices through the /api/device/v1/proxy/{device_id}?path=/systems endpoint, such as management IPs
• Creating a new user with administrative privileges on each device managed via the BIG-IP control system through the /api/device/v1/proxy/{device_id}?path=/users endpoint
• Confirming the successful creation of a new admin user by authenticating through the /api/v1/login endpoint

The key API endpoint that allowed the success of this exploit was the shadow API /api/device/v1/proxy/{device_id}?path=/users. What gave away its shadowy nature was the API path term “proxy.” This term suggested the API endpoint’s indirect access and interim nature.

Typically, shadow APIs include loose security controls. In this case, the shadow API endpoint lacked proper authorization and access controls, which enabled researchers to create an admin user for the centrally managed devices.

The exploit led to unauthorized access to a whole group of devices managed via the BIG-IP Next Central Manager and could lead to a complete device takeover.

This BIG-IP Next vulnerability falls within the OWASP API7:2023 Server-Side Request Forgery category.

Stay Alert and Stay in the Know

In this part, again, the most common were authorization issues, followed by injection flaws. Due to how widespread they are, people in the know believe that injection flaws should still be a separate OWASP API security risk category on its own, just like they were in the OWASP API Security Top 10 – 2019.

Stay alert for API security vulnerabilities in your environment, and stay tuned for the next, last part of our three-piece series on the top 10 API breaches in 2024 (so far).

In the meantime, find out how a purpose-built API security platform can help you keep your APIs secure from vulnerabilities.

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.