As part of a recent Penetration test performed by the OP Innovate research team, testing was done on the customer’s publicly available API.
The API can perform the same actions as a customer using the product UI. Customers have the ability to create resources, which can be either text files or folders that contain multiple files to be used as resources later on. Each text file or folder is considered a resource and has a unique resource ID.
Discovery of Broken Access Control Vulnerability
The research team discovered a significant Broken Access Control vulnerability in the application’s API which allows authenticated users to access or import other users’ resources by using their resource ID.
The research team initially identified an endpoint in the API that allows users to check if a specific Resource ID exists or not. Unfortunately, this endpoint was found to be susceptible to attack due to a lack of rate limiting and an inadequate access control mechanism. This means that unauthenticated attackers can easily enumerate resource IDs in the system.
The above screenshot demonstrates one successful match out of 1000 enumeration attempts. It stands out due to a response length that is twice as large as those of the failed attempts below it. Further, the server returned a 200 status code, indicating that data was successfully fetched. The request’s enumeration ID is associated to request #979, and proves that the server does not have a single source traffic limitation policy in place.
Enumeration of Resource IDs
This resource ID is a randomly generated, complex number. It is important to note that an attacker would be less likely to successfully exploit it unless they have prior knowledge of valid resource IDs associated with other users. However, with enough time and effort, an attacker can potentially discover valid resource IDs.
This screenshot demonstrates how an attacker can fetch data given a valid resource ID. The resource ID is reflected in the URL and sent through a GET request.
Exploiting the Vulnerability
To exploit this vulnerability, our research team created text files using another account and utilized the resource IDs we obtained for the newly created resources. Subsequently, we attempted to import and utilize a resource owned by another user with our “malicious” user account..
In the API we tested, resource IDs are used in projects created by another endpoint. Once we obtained a valid resource ID from another user, we imported it into a project owned by our “malicious” account. By importing the resource’s ID and creating a project under the “malicious” account, we were then able to download the resource (a text file or a folder containing multiple files) and view the contents of the file.
If attackers obtain a valid resource ID of another user, they can send requests to use those resources, retrieve their data, and incorporate it into their own projects.
If a resource contains any sensitive information uploaded by the user, a malicious actor could access it by creating a project with the resource’s ID.
Root Cause: Lack of Access Control
This vulnerability exists due to a lack of an Access Control mechanism that allows users to access and import/use resources owned by other users.
This is just one example of many oversights that organizations may have in their security controls that could open them up to a severe security breach, and emphasizes the importance of conducting periodic and continuous penetration testing.