Improper Asset Management In vAPI
- Understanding scenario
In this article, we are going to explore how to exploit Improper Asset Management Vulnerability in vAPI.
before proceeding, we will assume that the project (vAPI, Burpsuite, Postman) is installed and configured properly and everything is in good shape to start with.
first thing first we started analyzing the request structure in Postman, and we saw that there is a simple login process with a username and 4 digit pin number, sweet! so we tried to brute force it using the Brupsuite.
However, after brute forcing, we discovered that there is a rate limit mechanism for answer submission; how should we brute force it if it will stop our requests after every 4 unsuccessful attempts?
We know from the vAPI webpage that they have introduced V2 for API9, which suggests that there may still be an active V1 assets for the same that may not have such a rate limit mechanism.
So, inside Postman, we tried submitting the identical login request with the API version updated from V2 to V1, and voila it worked, so we know that V1 API assets are still active and usable.
so this time we again tried to brute force the pin number in Brupsuite but we are using V1 asset requests for API9, as we thought these requests do not have any rate limit mechanism for request submission, which we wanted from start.
- Brute forcing pin number
configure postman proxy and pivot postman API request to Brupsuite through burp proxy and send the request to the burp intruder.
- select attack type sniper.
- add payload marks to pin only in the request body.
- set the following options in the Payloads section.
Payload set = 1
Payload type = number
From = 0001
To = 9999
Step = 1- and the start attack.
- wait for the attack to complete and analyze the response codes.