Broken Function Level Authorization

Broken Function Level Authorization

Where BOLA is all about accessing resources that do not belong to you, BFLA is all about performing unauthorized actions. BFLA vulnerabilities are common for requests that perform actions of other users. These requests could be lateral actions or escalated actions. Lateral actions are requests that perform actions of users that are the same role or privilege level. Escalated actions are requests that perform actions that are of an escalated role like an administrator. The main difference between hunting for BFLA is that you are looking for functional requests. This means that you will be testing for various HTTP methods, seeking out actions of other users that you should not be able to perform.

If you think of this in terms of a social media platform, an API consumer should be able to delete their own profile picture, but they should not be able to delete other users' profile pictures. The average user should be able to create or delete their own account, but they likely shouldn't be able to perform administrative actions for other user accounts. For BFLA we will be hunting for very similar requests to BOLA.

1. Resource ID: a resource identifier will be the value used to specify a unique resource.

2. Requests that perform authorized actions. In order to test if you can access another update, delete, or otherwise alter other the resources of other users.

3. Missing or flawed access controls. In order to exploit this weakness, the API provider must not have access controls in place.

Notice that the hunt for BFLA looks familiar, the main difference is that we will be seeking out functional requests. When we are thinking of CRUD (create, read, update, and delete), BFLA will mainly concern requests that are used to update, delete, and create resources that we should not be authorized to. For APIs that means that we should scrutinize requests that utilize POST, PUT, DELETE, and potentially GET with parameters. We will need to search through the API documentation and/or collection for requests that involve altering the resources of other users. So, if we can find requests that create, update, and delete resources specified by a resource ID then we will be on the right track. If the API you are attacking includes administrative requests or even separate admin documentation, then those will be key to see if you are able to successfully request those admin actions as a non-admin user.

Let's return to our crAPI collection to see which requests are worth testing for BFLA. The first three requests I found in our collection were these:

• POST /workshop/api/shop/orders/return_order?order_id=5893280.0688146055

• POST /community/api/v2/community/posts/w4ErxCddX4TcKXbJoBbRMf/comment

• PUT /identity/api/v2/user/videos/:id

When attacking sometimes you will need to put on your black hat thinking cap and determine what can be accomplished by successful exploitation. In the POST request to return an order, a successful exploit of this would result in having the ability to return anyone's orders. This could wreak havoc on a business that depends on sales with a low return rate. An attacker could cause a fairly severe disruption to the business. In the PUT request, there could be the potential to create, update, delete any user's videos. This would be disruptive to user accounts and cause a loss of trust in the security of the organization. Not to mention the potential social engineering implications, imagine an attacker being able to upload videos as any other user on whichever social media platform.

The purpose of the POST /community/api/v2/community/posts/w4ErxCddX4TcKXbJoBbRMf/comment request is to add a comment to an existing post. This will not alter the content of anyone else's post. So, while at first glance this appeared to be a potential target, this request fulfills a business purpose and does not expose the target organization to any significant risk. So, we will not dedicate any more time to testing this request.

With BFLA we will perform a very similar test to BOLA. However, we will go one step further from A-B testing. For BFLA we will perform A-B-A testing. The reason is with BFLA there is a potential to alter another user's resources. So when performing testing there is a chance that we receive a successful response indicating that we have altered another user's resources, but to have a stronger PoC we will want to verify with the victim's account. So, we make valid requests as UserA, switch out to our UserB token, attempt to make requests altering UserA's resources, and return to UserA's account to see if we were successful.

Please take note: When successful, BFLA attacks can alter the data of other users. This means that accounts and documents that are important to the organization you are testing could be on the line. DO NOT brute force BFLA attacks, instead, use your secondary account to safely attack your own resources. Deleting other users' resources in a production environment will likely be a violation of most rules of engagement for bug bounty programs and penetration tests.

The two requests that look interesting for a BFLA attack include the return order request and the PUT request to update the video names. Both of these requests should require authorization to access resources that belong to the given user. Let's focus on the request to update video names.

In the captured request we can see that UserA's video is specified by the resource ID "757".

Now if we change the request so that we are using UserB's token and attempt to update the video name, we should be able to see if this request is vulnerable to a BFLA attack.

As we can see in the attack, the API provider response is strange. Although we requested to update UserA's video, the server issued a successful response. However, the successful response indicated that UserB updated the name to the video identified as 758, UserB's video. So, this request does not seem to be vulnerable even though the response behavior was strange. Strange behavior from an app response is always worth further investigation. We should investigate other request methods that can be used for this request.

Replacing PUT with DELETE illicit's a very interesting response, "This is an admin function. Try to access the admin API". In all of our testing, up to this point, we have not come across an admin API, so this is really intriguing. If we analyze the current request DELETE /identity/api/v2/user/videos/758 there does seem like one obvious part of the path that we could alter. What if we try updating the request to DELETE /identity/api/v2/admin/videos/758, so that we replace "user" with "admin"?

Success! We have now discovered an admin path and we have exploited a BFLA weakness by deleting another user's video.

Congratulations on performing successful authorization testing and exploitation. This attack is so great because the impact is often severe, while the technique is pretty straightforward. Authorization vulnerabilities continue to be the most common API vulnerabilities, so be vigilant in testing for these.