BOLA exploitation using unauthorized UUID on an API endpoint

A UUID (Universal Unique Identifier) is a standardized 128-bit format used to identify information in computer systems. It is often used to identify records or objects within a database or devices or components within a computer system. UUIDs are typically generated using a combination of numbers and letters and are designed to be unique across all devices and systems. 

Attackers can exploit BOLA vulnerabilities by using another user's UUID to access their account or data. This can happen if a system does not properly validate the UUIDs that are used to access user accounts or data or if a system does not properly protect against unauthorized access to UUIDs.

In this article, we will discuss a test case for BOLA, where a vulnerable application fails to authorize a UUID on the API endpoint, allowing us to retrieve another user's information using their UUID.

General Severity: Low to Medium

OWASP Category: API1:2019 Broken Object Level Authorization

For practical demonstration, we will use a completely ridiculous API (crAPI) which is vulnerable by design to test for API vulnerabilities. (Install the vulnerable application by referring to the quick start guide of crAPI)

The vulnerable application has a feature where users can request a refresh location endpoint to view their vehicle's location. The application uses vehicle id to retrieve the location. 

On another side, the application exposes other users' vehicle IDs when replying to their comments.

General reproduction steps:

1.  Once you have installed the application, register and log in to the application.

2. Navigate to the MailHog server on port 8025 to get the vehicle details.

3. Register the vehicle and navigate to the dashboard.

4. At the bottom of the page, Refresh Location while capturing the traffic using Burpsuite (or any other proxy tools). (By the way, you can also create an inventory by importing the captured request in the Akto dashboard using the Burp plugin.)

5. Observe the application was making a request to GET /api/v2/UUID/location endpoint and send a request to a repeater for later use.

6. Now, navigate to the Community tab, and open the comments of any user.

7. Reply to the comment of a user, (In this we have replied to the comment of Title 1, user- Adam.)

8. Navigate to the HTTP history tab in Burpsuite and observe the POST/community/api/comment request.

9. As you can see, the application has exposed the user's details with the vehicle id.

10. Copy the exposed vehicle id and paste it to the previously captured GET/api/v2/UUD/location request. 

11. Send the modified request.

Observe that, by replacing another user’s UUID, we successfully exploited the BOLA vulnerability and allowed us to retrieve another user’s vehicle location information.

Impact:

Attackers who have access to internal references have direct access to the application's data and state. Attackers can then modify the exposed objects to change data and access confidential information.

Remediations:

Implementing strict access control checks on every functionality to determine whether the user is permitted to access and manipulate the requested object is the best way to prevent BOLA.

1. Developers implementing the API should implement a robust authorization mechanism. In the above case, the developer should allow access only if the requested uuid is actually owned by the user.

2. Perform active testing of your endpoints for BOLA vulnerabilities using automated testing products such as Akto. Do not deploy vulnerable changes that break the tests.

Besides, IDs and UUID attackers can manipulate weak authorization tokens to perform BOLA attack. We will see that in the next blog.