roottusk/vapi Writeup

This blog post provides a tutorial of exploiting the top 10 API vulnerabilities on vAPI, which stands for Vulnerable Adversely Programmed Interface, a self-hosted PHP interface that uses exercises to replicate the OWASP API Top 10 situations. It’s available for download at https://github.com/roottusk/vapi.
It can be readily configured by following the directions in README.md.

Requirements

• PHP
• MySQL
• PostMan
• MITM Proxy

Let’s begun our exploitation

1. Broken object-level authorization

In this vulnerability, the user can see the data of another user by changing one parameter like if my id is 5 and I change the id parameter value to 6 and I'm able to see other user data then it is broken object-level authorization. This vulnerability is called IDOR.

So in API 1 endpoints, we can create a user and see our data using the id parameter

So we created a new user.

You people also ship for Eren Mikasa. I know that. ME TOO!!!

And now we will see our data by making a get request

GET Request API 1

As we can see our data. Let’s try to change the id parameter and check whether we can see the other user data or not.

Yes, we got our first flag by changing the id value to 1.

The last endpoint in API 1 is the PUT Update user which gives the user the facility to update the information. But I tried to change the data of the user whose id=1 and I’m able to lead to broken object-level authorization

What happened here, exactly?
We got the flag because the API did not execute permission checks when returning data based on the identity.

2. Broken authentication

In this, an attacker can bypass the authentication and personate as the user whose account he has taken over. Major reasons are Weak passwords, default passwords, brute-force/dictionary attacks, or unauthorized actors gaining access to credentials/tokens.

In API 2 there are two endpoints first we can log in using an email Id and password which gave us a token. and this token is used in the next request to get the information and specific for every user.

API AUTH TOKen

In the above image, we can see that automatically token value that we get by logging is stored in the api2_auth variable.

So like this API 2 should work but in the resource folder, there is a creds.csv file that has a lot of ids and passwords. Now the time has to come to call our favorite Burp suite.

Now we will capture the request of 1 endpoint and send it to the intruder and do the following steps

1. Selecting attack as a pitchfork
2. select email id and password as payload
3. Go to the payload tab and paste the credentials from creds.csv

Intruder tab

Do this for payload 1

Do this for payload 2

And now start the attack

It will take time to complete the attack if you are using the community version of the Burp Suite. Now we can see the result and in response, we can see the token which we can use in the GET request to obtain the information, and there we will get our flag.

These two photos are from the previous writeup. Some technical problem I’m facing in Burp Suite

Don’t know what’s going on here?
Because the API did not include rate-limiting on authentication functionality, the attacker used a credential stuffing attack to acquire access to the other user’s account by providing leaked credentials.

3. Excessive data exposure

We all have been there. Sharing more than required. ME TOO!!. This API response shares the information which is not needed to share with a normal user and the user can access that data and take advantage of it.

So, in this, we have to go resources folder in there is an apk which we will run in our emulator and follow the steps

Now after seeing what this API is made for try to exploit it and for that, we need a burp suite. We set the proxy and intercept the request and send it to the repeater to test it.

See the response to the request and I know we got our FLAG!!!!. So much oversharing.

What an easy FLAG!!

Because the API is returning a lot of data in response to the login request, but not all of it is reflected on the interface, a proxy tool like Burpsuite can help uncover data that is being exposed needlessly.

4. Lack of resources and rate-limiting

The majority of the time, APIs are not set to protect themselves from excessive client-side requests. An attacker could use this weakness to flood the server with requests, causing a denial-of-service (DoS) or bypassing the authentication system.

In this, we have 3 endpoints. Firstly we send the OTP and then verify it and we got a token then lastly, we are able to see the details of the user.

So, we send the OTP

OTP sent

Now we don’t know the OTP so from the response body of the above request we can think that otp is of 4 digits and there is no rate limiting so we will try brute force.

For that, we will capture the request entering any 4 digits in Burp Suite, and then send it to the intruder tab

Intruder OTP bypass

Select otp value as payload and attack type sniper

Go to payload tab and set payload type numbers and in payload options set things as shown in below screenshot.

Launch the attack!!!

We can see the correct OTP and now send the request to the postman using this OTP.

Yes we got the key I think it’s time for our FLAG

As I said we got our 4th flag

What exactly did we do just now?
We got around rate-limiting on the second-factor authentication mechanism (OTP) by performing a brute-force attack on the OTP value and obtaining the correct OTP and so user data.

5. Broken function-level authorization

In this, the normal user can temper the request method and be able to retrieve the information which she should not have or can perform an action which he should not ba accessible

In this first endpoint is create a user by a POST request and we send the request and make a user and we got an auth token

The auth token we got in the previous request is used in the next request to show the details of the user we created.

Now we will intercept this request and try to see the details of all users as I think there should be our flag. So I tried various ways and finally came to it and got FLAG

Isn’t it a piece of cake?
We retrieved information about other users by making an educated guess about a page that was not directly accessible to normal users but didn’t have any authorization checks in place to validate the user’s privileges.

6. Mass assignment

This is my favorite type of vulnerability. In this sometimes APIs accept user input from the client and save it in the database without filtering it. To get unauthorized access to restricted features, an attacker can identify extra objects via API documentation, educated guesses, or HTTP replies and include them in the request. For example, an attacker may attach the &admin=true argument to a user’s registration and acquire admin capabilities.

So, In this there are two endpoints firstly we will create a user.

Do you guys also root for Eren and Mikasa?🥺🥺🥺

Now after creating the user we got an auth token by entering which we can see the details in the next endpoint

Here we can see an interesting parameter credit.

Let’s try to add this parameter in our first endpoint and see if we can get more credit. *evil_smile*

So, I thought of a number by which I can measure Eren and Mikasa's love but I can't but in search of that, I got the FLAG!!!

What method did we use to get our credits?
We discovered another parameter called credits in the GET response, but no credits were assigned when the user was created, as per the design. We attempted to assign credit by adding another parameter to the POST request, which resulted in the credits being awarded and the flag being set.

7. Security misconfiguration

Default or incomplete configurations, misconfigured HTTP headers, superfluous Cross-Origin resource sharing (CORS) misconfigurations, and verbose error messages containing sensitive data are all examples of security misconfiguration. An attacker could take advantage of these flaws to obtain unauthorized access or disable security systems.

In this, there are 4 endpoints. At first, we have to create a user which got an auth token to log in

In next we enter the auth_token and log in. In this weak encryption is used auth_token is normal base64 encoded

After Logging in we move to the next endpoint where we get the key as we can think from the lab description we have to exploit Cross-origin Request.

Origin is a header added in request. t is used to provide the “security context” for the origin request, except in cases where the original information would be sensitive or unnecessary.

So we add a header in this request and give value https://bing.com to it

AND WE GOT THE FLAG!!!

8. Injection

The injection must tell other vulnerabilities that I’m everywhere or we can say bhaut faila Hua business hai humra. They always secure positions in OWASP TOP 10. SQL queries, NoSQL queries, LDAP, OS, and other commands may be included in API requests. When a server receives input as part of a query from a user, it executes it without filtering it, which is known as an injection attack.

In this we have 2 endpoints first we have to log in. So we tried random username and password

But we are unable to log in using these credentials

So, as the lab name suggests I tried SQL injection and got an MYSQL error and exploited it, and got the auth token.

The payload I used was 1'or’1'=’1. You can try other also

And using this auth token we send requests from the second endpoint and got the FLAG!!!

We used a SQL injection attack to gain access to admin credentials because the authentication functionality did not filter user input and the server was querying the database using SQL language.

9. Improper assets management

In this, the assets which handle all the requests and responses are not handled properly. For instance, a developer updated the API to v3 as a new update came into the market but forget to disable API v2. Now, if some attacker changes the value of v3 to v2 in the URL. He can exploit the vulnerabilities that were present in v2 version.

Now in this when we send the request. In response we can see there is rate-limiting enabled. So what we can do to log in and get the flag.

Rate-limiting — security

v2 to v1 — aukat

Let’s try and change v2 to v1 and send our request as we can see we are able to send as well as there is no rate limiting.

So we launch an attack by setting value as payload position and setting payload option as a number from 1000 to 1700 increasing one at a time.

WE got success on 1655 and got the FLAG!!!

Was this really a good piece of information?
Although API v2 was released with improved security features, v1 was nevertheless left exposed, inviting attackers to feast.

10. Insufficient logging and monitoring

Mostly APIs are not configured for monitoring, logging, or raising warnings, allowing an attacker (who has already penetrated the system or is attempting to do so) to remain undetected, allowing him to sustain his persistence in the system, perform lateral moves, and compromise vital systems.

This can be readily avoided if the system is set up to detect and block attack attempts through logging and monitoring.

“Because this is a design flaw and an attacker has no role to play in exploiting this issue, there is no walkthrough for Insufficient logging and monitoring.”

We send the request and got the flag!!!

References:

Exploiting OWASP Top 10 API Vulnerabilities