89 lines
7.8 KiB
Markdown
89 lines
7.8 KiB
Markdown
|
|
|||
|
|
#### Broken Object Level Authorization (BOLA) (View Object)
|
|||
|
|
|
|||
|
|
When hunting for BOLA there are three ingredients needed for successful exploitation.
|
|||
|
|
|
|||
|
|
1. Resource ID: a resource identifier will be the value used to specify a unique resource. This could be as simple as a number, but will often be more complicated.
|
|||
|
|
2. Requests that access resources. In order to test if you can access another user's resource, you will need to know the requests that are necessary to obtain resources that your account should not be authorized to access.
|
|||
|
|
3. Missing or flawed access controls. In order to exploit this weakness, the API provider must not have access controls in place. This may seem obvious, but just because resource IDs are predictable, does not mean there is an authorization vulnerability present.
|
|||
|
|
|
|||
|
|
The third item on the list is something that must be tested, while the first two are things that we can seek out in API documentation and within a collection of requests. Once you have the combination of these three ingredients then you should be able to exploit BOLA and gain unauthorized access to resources.
|
|||
|
|
|
|||
|
|
- **Finding Resource IDs and Requests**
|
|||
|
|
|
|||
|
|
Authorization weaknesses by understanding how an API’s resources are structured and then attempting to access resources you shouldn’t be able to access. By detecting patterns within API paths and parameters, you might be able to predict other potential resources. The bold resource IDs in the following API requests should catch your attention:
|
|||
|
|
|
|||
|
|
- GET /api/resource/**1**
|
|||
|
|
- GET /user/account/find?**user_id=15**
|
|||
|
|
- POST /company/account/**Apple**/balance
|
|||
|
|
- POST /admin/pwreset/account/**90**
|
|||
|
|
|
|||
|
|
In these instances, you can probably guess other potential resources, like the following, by altering the bold values:
|
|||
|
|
|
|||
|
|
- GET /api/resource/**3**
|
|||
|
|
- GET /user/account/find?user_id=**23**
|
|||
|
|
- POST /company/account/**Google**/balance
|
|||
|
|
- POST /admin/pwreset/account/**111**
|
|||
|
|
|
|||
|
|
In these simple examples, you’ve performed an attack by merely replacing the bold items with other numbers or words. If you can successfully access the information you shouldn’t be authorized to access, you have discovered an authorization vulnerability.
|
|||
|
|
|
|||
|
|
Here are a few ideas for requests that could be good targets for an authorization test.
|
|||
|
|
|
|||
|
|
|
|||
|
|
- **Searching for BOLA**
|
|||
|
|
- Now that we have a better idea of the purpose of the app, we should seek out requests that can provide us with relevant resources. If you remember back to the module covering Excessive Data Exposure, then there should be one request that stands out.
|
|||
|
|
|
|||
|
|
- **GET /identity/api/v2/videos/:id?video_id=589320.0688146055**
|
|||
|
|
- **GET /community/api/v2/community/posts/w4ErxCddX4TcKXbJoBbRMf**
|
|||
|
|
- **GET /identity/api/v2/vehicle/{resourceID}/location**
|
|||
|
|
|
|||
|
|
- **Authorization Testing Strategy**
|
|||
|
|
- Before testing what your looking to exploit, create a new collection where you can copy all your targeted request (the one your looking to exploit) ---> Make things more clear
|
|||
|
|
|
|||
|
|
- When searching for authorization vulnerabilities the most effective way to find authorization weaknesses is to create two accounts and perform A-B testing. The A-B testing process consists of:
|
|||
|
|
|
|||
|
|
1. Create a UserA account.
|
|||
|
|
2. Use the API and discover requests that involve resource IDs as UserA.
|
|||
|
|
3. Document requests that include resource IDs and should require authorization.
|
|||
|
|
4. Create a UserB account.
|
|||
|
|
5. Obtaining a valid UserB token and attempt to access UserA's resources.
|
|||
|
|
|
|||
|
|
You could also do this by using UserB's resources with a UserA token. In the case of the previously mentioned requests, we should make successful requests as UserA then create a UserB account, update to the UserB token, and attempt to make the requests using UserA's resource IDs. We've already been through the account creation process several times, so I will skip ahead to a request that looks interesting.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
This request looks interesting from a BOLA perspective because it is a request for a location that is based on the complex-looking vehicle ID. As UserB, I've gone through the crAPI interface and registered a vehicle. I then used the "Refresh Location" button on the web app to trigger the above request.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
To make things easier for this attack capture the UserB request with Burp Suite.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Next, perform the BOLA attack by replacing UserB's token with UserA's token and see if you can make a successful request.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Success! UserA's token is able to make a successful request and capture the GPS location of UserB's car along with their vehicleLocation ID and fullName.
|
|||
|
|
|
|||
|
|
In the GET request to the /community/api/v2/community/posts/recent, we discovered that the forum has excessive data exposure. One sensitive piece of data that was exposed was the vehicleID. At first glance, a developer could think that an ID of this complexity (a 32 alphanumeric token) does not require authorization security controls, something along the lines of security through obscurity. However, the complexity of this token would only help prevent or delay a brute-force attack. Leveraging the earlier discovered excessive data exposure vulnerability and combining it with this BOLA vulnerability is a real pro move. It provides a strong PoC and drives home the point of how severe these vulnerabilities really are.
|
|||
|
|
|
|||
|
|
**Remember that even if you try to capture all request from the API you might founf/create new request that was not intented to be use by the website and by the same way finding a vulnerability**
|
|||
|
|
|
|||
|
|
#### Broken Function Level Authorization (BFLA)
|
|||
|
|
(Change Object)
|
|||
|
|
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
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. 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.
|
|||
|
|
|
|||
|
|
Steps
|
|||
|
|
- Basicly the same has BOLA, simply tweak method (GET, PUT, POST, DELETE...) and use A & B testing to find vulnerability
|
|||
|
|
- You can also tweak some file path ex (https://something.com/api/v2/user/...) change the /user/ to admin. This might give you some admin permission
|
|||
|
|
- Example
|
|||
|
|
- Get request give us product list, change it to post and check if you might be able to add some parametters to inject some products
|