Exploiting OWASP Top 10 API Vulnerabilities

Hello Everyone,

I hope you are doing well and good.

You might have read a lot about OWASP Top 10 Web Application Security risks but have you read about OWASP API Security Top 10?

No? Well, you are at the right place. 😉

These days, APIs have become critical element of modern applications and security landscape has changed significantly since the rise of APIs. Hence, OWASP released a list of top 10 API Security vulnerabilities for the first time in 2019.

This blog post is a walkthrough of exploiting top 10 API vulnerabilities on vAPI which is Vulnerable Adversely Programmed Interface, a self-hostable PHP Interface that mimics OWASP API Top 10 scenarios in the means of exercises. It can be downloaded from : https://github.com/roottusk/vapi

It can be easily configured according to the instructions provided in README.md .

Tools Required:

• Postman
• Burpsuite
• XAMPP Server (Apache and MySQL)

Fig A : Documentation can be browsed at http://localhost/vapi/

Without wasting more time, lets get started with OWASP Top 10 API vulnerabilities.

1. Broken object level authorization

APIs tend to access user data by using an identifier in the parameter (such as id=5). This identifier can be predicted and replaced by an attacker (user with malicious intent) to the identifier of other users (e.g. id=6). If API does not perform proper authorization checks, it will let attacker access the data of other users. This attack is also called IDOR (Insecure Direct Object References).

Ideal Behavior of vAPI - API1

1. Create a user with POST request (Fig 1.1)
2. Get user details with GET request (Fig 1.2)

Fig 1.1: POST request to CreateUser.php

Fig 1.2: GET request to getUser.php

Exploiting vAPI - API1

Fig 1.3: API1 Documentation

It says that we can register as a user here. Is there something more ? 😯

Lets try.

1. Created a user by providing details. (Fig 1.4)
2. Got user details by making a get request. (Fig 1.5)
3. Intercepted the request and enumerated the id from 4 to 1.
4. API returned details of admin user while making request with id=1. (Fig 1.6)

Fig 1.4: Create User

Fig 1.5: Get User

Fig 1.6: API1 FLAG

What happened here?

Well, API did not perform permission checks while returning data based on the identifier and hence we got the flag.

2. Broken authentication

APIs do not usually implement user authentication properly. Broken authentication is anything which can lead an attacker to assume other user’s identity based on weak passwords, default passwords, brute-force/dictionary attacks or exposure of credentials/tokens to unauthorized actors.

Ideal Behavior of vAPI — API2

1. Login by providing email-id and password to get Auth-Key. (Fig 2.1)
2. Get user details by sending Auth-Key received in the previous response. (Fig 2.2)

Fig 2.1: POST request to loginUser.php

Fig 2.2: GET request to getUser.php

Exploiting vAPI — API2

Fig 2.3: API2 Documentation

Ehh..We just logged in using credentials!! Are there any other credentials as well ?😕 Lets check Resources folder.

Yes, There is a csv file having too many credentials. Seems like they got leaked somehow. Lets use someone else’s credentials and get his details. 😋

Fig 2.4: CSV file with leaked credentials

Oops, there are too many of them; which one is correct? We can’t try all of them to get something juicy.

Intruder to the rescue.

1. Sent the request using default credentials provided in the postman collection and intercepted the request. (Fig 2.5)
2. Forwarded the request to Burpsuite’s Intruder to try credential stuffing.
3. Added email and password as positions to undergo pitchfork attack. (Fig 2.6)
4. Pasted the data from csv file for both payload positions and configured payload processing to segregate emails and passwords from the list. (Fig 2.7 and Fig 2.8)
5. Launched the attack and got two more working credentials [200 OK], and copied the token of one of the users. (Fig 2.9)
6. Used the token to get details of other user. (Fig 2.10)

Fig 2.5: User Login

Fig 2.6: Intruder Positions

Fig 2.7: Payload for Email IDs

Fig 2.8: Payload for password

Fig 2.9: Auth-Token of other user

Fig 2.9: API2 Flag

Didn’t understand what happened here?

Well, API did not implement rate-limiting on authentication functionality and attacker gained access to the other user’s account with credential stuffing attack by feeding leaked credentials.

3. Excessive data exposure

APIs may return lot of unnecessary data in response and filter it on client-side to display only required data. An attacker can easily bypass client-side filtering by using proxy tool such as Burpsuite and access the excessive data returned in the response.

Ideal Behavior of vAPI — API3

1. Setup server URL in base URL (Fig 3.1)
2. Provide credentials and login (Fig 3.2)
3. Post a comment (Fig 3.3)

Fig 3.1: Set Base URL

Fig 3.2: Provide Credentials

Fig 3.3: Post a Comment

Exploiting vAPI — API3

Fig 3.3: API3 Documentation

Android app from the Resources folder works fine, it logs in user after providing credentials. Can’t find what’s wrong here? 😕

Lets intercept the traffic and check.

1. Setup mobile app through Burpsuite proxy to intercept traffic.
2. Set base URL as server’s address.
3. Provided credentials for login and intercepted the request. (Fig 3.4)
4. Observed carefully the subsequent request for getComments.php and found that it is disclosing lot of information in the response and got the flag. (Fig 3.5)

Fig 3.4: User Login

Fig 3.5: API3 Flag

Pretty easy huh?

API is returning excessive information in response to the login request, however not reflecting everything on the interface hence a proxy tool such as Burpsuite can help in finding unnecessarily exposed data.

4. Lack of resources and rate limiting

Most of the times APIs are not configured to protect itself from excessive amount of request made from client-side. An attacker can use this flaw to overwhelm the server with too many requests in order to perform denial-of-service (DoS) or to bypass authentication mechanism.

Ideal Behavior of vAPI — API4

1. Provide mobile number in POST request to receive one time password (OTP). (Fig 4.1)
2. Provide received OTP in POST request to get Auth-key. (Fig 4.2)
3. Provide Auth-key in GET request to get user details. (Fig 4.3)

Fig 4.1: POST request for Mobile Login

Fig 4.2: POST request to Verify OTP

Fig 4.3: Get Details for logged in user

Exploiting vAPI — API4

Fig 4.4: API4 Documentation

It says OTPs are great way of authentication if and only if implemented securely. Hmmm… something to do with the OTP. But, do we have the OTP for provided mobile number provided in the postman collection?

No, we don’t.

Should we guess the OTP ? 🤔
But there are too many possibilities, we can’t try all of them manually.

Intruder is the way.

1. Sent the POST request with mobile number, it said OTP sent. (Fig 4.5)
2. Provided random OTP in POST request, intercepted it and sent it to Intruder. (Fig 4.6)
3. Set OTP value as position and set 4-digit 1000 numbers in payload. (Fig 4.7 and Fig 4.8)
4. Launched the attack and found that OTP was 1872. (Fig 4.9)
5. Copied Auth-key from the response received from request with OTP as 1872.
6. Pasted the Auth-key in GET request to login and received user details in response and hence got the flag. (Fig 4.10)

Fig 4.5: Mobile Login

Fig 4.6: Verify OTP

Fig 4.7: Intruder Positions

Fig 4.8: Intruder Payloads

Fig 4.9: Found correct OTP

Fig 4.10: API4 Flag

Wait… what we did just now?

Since rate-limiting was not implemented on second-factor authentication mechanism (OTP), we bypassed it by launching brute-force attack on OTP value and got the right OTP and hence user details.

5. Broken function level authorization

Some administrative functions are accessible without any authorization however are not exposed directly to the normal users, so these functions are secure according to the developers. In actual, these are only secure until and unless not discovered by an attacker, which can be easily done by trying educated guesses or brute-force attack.

Ideal Behavior of vAPI — API5

1. Create user using POST request and providing username, password, name, address and mobile number. (Fig 5.1)
2. Get the same user details through GET request. (Fig 5.2)

Fig 5.1: POST request to createUser.php

Fig 5.2: Get user details from getUser.php

Exploiting vAPI — API5

Fig 5.3: API5 Documentation

Yes, We registered as a user but what else could be done? Is it something to do with admin rights? Lets check.

1. Created a user by providing username, password, name, address and mobile number. (Fig 5.4)
2. Got user details and intercepted the request, it was making request to getUser.php page. (Fig 5.5)
3. What if we want to get details of all users? tried getAllUser.php but didn’t work.
4. Again tried the same request with getAllUsers.php page and got details of admin user and hence got the flag. (Fig 5.6)

Fig 5.4: Create User

Fig 5.5: Get User

Fig 5.6: API5 Flag

It was quite simple, right ?

We fetched details of other users by making an educated guess to a page which was not exposed directly to the normal users but it didn’t have any authorization check to verify the privileges of the user.

6. Mass assignment

Many a times, APIs trust user input received from the client-side and write it in the database without filtering. Attacker can find additional objects from API documentation, educated guesses or http responses, and add it in the request to gain unauthorized access to restricted functionalities. e.g. while registering a user, an attacker can append &admin=true parameter and could gain admin privileges.

Ideal Behavior of vAPI — API6

1. Create user using POST request and providing username and password. (Fig 6.1)
2. Get the same user details through GET request. (Fig 6.2)

Fig 6.1: POST request to createUser.php

Fig 6.2: Get details of registered user

Exploiting vAPI — API6

Fig 6.3: API6 Documentation

They said we will give you credits if you behave nicely but we didn’t get any. 😢

Should we be more nice? 😏

1. Created user by providing username and password. (Fig 6.4)
2. Got user details through GET request but credits field was blank. (Fig 6.5)
3. Intercepted ‘create user’ request and appended another parameter as &credit=100 (tried to steal some credits). (Fig 6.6)
4. 100 credits got assigned to the user and hence got the flag while getting user details. (Fig 6.7)

Fig 6.4: Create User

Fig 6.5: Get User

Fig 6.6: Assigned credits forcefully

Fig 6.7: API6 Flag

How did we receive credits ?

From the response of getUser.php we identified that there is another parameter named credits however as per the design there were no credits assigned while creating user. We tried to forcefully assign credit by creating another parameter in createUser.php request, as a result, we got the credits assigned and hence the flag.

7. Security misconfiguration

Security misconfiguration is anything which is a result of default or incomplete configurations, misconfigured HTTP headers, unnecessary HTTP methods, Cross-Origin resource sharing (CORS) misconfigurations, and verbose error messages containing sensitive data. An attacker may exploit these poor configurations to gain unauthorized access or break security mechanisms.

Ideal Behavior of vAPI — API7

1. Create user using POST request by providing username and password. (Fig 7.1)
2. Login using GET request and the same credentials. (Fig 7.2)
3. Receive Auth-Key of the user and by sending the session ID of logged-in user. (Fig 7.3)
4. Log out of the user account.

Fig 7.1: POST request to createUser.php

Fig 7.2: Login using the same details

Fig 7.3: Get Auth-key for logged in user

Exploiting vAPI — API7

Fig 7.4: API7 Documentation

It says, as an API it is expecting a cross-origin request, and they hope it works fine but we hope it does not. 😄

-> As a victim:

1. Created a user with username and password. (Fig 7.5)
2. Logged into user account using same credentials. (Fig 7.6)
3. Received Auth-Key by providing session ID of logged in user. (Fig 7.7)

Fig 7.5: Create User

Fig 7.6: Login using same details

Fig 7.7: Get Auth-key after login

-> As an attacker:

a. Wrote a CORS exploit for getting Auth-Key from getKey.php page. (Fig 7.8)

Wanted to get Auth-Key of the victim but it needs session ID of the victim’s user accounts.

Can’t steal the session ID from victim? no problem, let the victim get it for us. 😉

b. Hosted the CORS exploit on attacker.exploit.com (fake domain) and sent the link to victim.

Fig 7.8: CORS exploit hosted on attacker.exploit.com

-> As a victim again:

5. Received a link from someone, got curious to check what’s in it for me.
6. Clicked on the link which is hosting CORS exploit, at the same time user account is logged-in in the browser.
7. When CORS exploit got executed, it made request to getKey.php while sending Session ID along in the request. (Fig 7.9)
8. The server, which is misconfigured to trust arbitrary host in the Origin header (attacker.exploit.com) sent back the Auth-Key and the flag.

Fig 7.9: Server sent back the Auth-Key to attacker.exploit.com

-> As an attacker again:

c. Because attacker.exploit.com is attacker controlled server, we got hold of the Auth-Key of the victim and hence the account is compromised.

So, the victim clicked on the CORS exploit link received from the attacker and the server was misconfigured to trust any domain coming in the Origin header of the request and it sent back the credentials to attacker.exploit.com.

8. Injection

Injection attacks are not only prevalent in web applications but also have secured a place in OWASP top 10 API security list. API calls may include SQL query, NoSQL query, LDAP, OS, or other commands in the request. Injection attack happens when a server blindly executes the input received as a part of query from the user without filtering it.

Ideal Behavior of vAPI — API8

1. Login using POST request by providing username and password. (Fig 8.1)
2. Get Auth-key by providing session ID in the request. (Fig 8.2)

Fig 8.1: POST request to login.php

Fig 8.2: Get Auth-key by sending Session ID

Exploiting vAPI — API8

Fig 8.3: API8 Documentation

It says that we aren’t getting credentials for this, what to do ? How to login? 😐

Lets try injecting something.

1. Tried random username and password, intercepted the request and sent it to Intruder. (Fig 8.4)
2. Added username and password as positions and SQL injection strings in payload. (Fig 8.5 and Fig 8.6)
3. Launched attack and found some of SQLi payloads working and bypassing authentication. (Fig 8.7)
4. Copied session ID of logged in user and used it to get Auth-Key of admin user. (Fig 8.8 and Fig 8.9)

Fig 8.4: User Login failed

Fig 8.5: Intruder positions

Fig 8.6: SQLi payloads

Fig 8.7: SQLi payloads worked

Fig 8.8: Login using SQLi payload and copy Session ID

Fig 8.9: Used Session ID to get Auth-key of admin

Since, the authentication functionality was not filtering user input and server was using SQL language to query from database, we performed SQL injection attack and got access to admin credentials.

9. Improper assets management

APIs tend to expose more endpoints than it seems, especially the one from older versions. Developers may leave older version of APIs running for backward compatibility which might not have enough security mechanism implemented. A normal user may not have direct access to older version however an attacker can enumerate and discover them to misuse.

Ideal Behavior of vAPI — API9

1. Login into admin account using username and password.

Fig 9.1: POST request to login.php

Exploiting vAPI — API9

Fig 9.2: API9 Documentation

Good news is that they just launched v2 of their API, but is there any bad news as well ? Lets find out.

1. Didn’t have any password to login into admin account.
2. Tried some random passwords but no luck. (Fig 9.3) Can’t even try brute-force attack, there is rate-limiting set in v2 API. Wait.. Was there rate-limiting set in v1 API and is it still accessible?
3. Changed v2 to v1 in URI and got the response.
4. Launched brute-force attack using SQL injection payloads and got some payloads working.
5. Use the payload to login at api1 and got the flag. (Fig 9.4)

Fig 9.3: Login request

Fig 9.4: API9 Flag

Was this really a good news?

v2 of API was launched with improved security mechanisms but v1 was still left open to invite attackers for a feast.

10. Insufficient logging and monitoring

Most of the times, APIs are not configured for monitoring, logging and raising alerts which make an attacker (who has compromised the system, or trying to) go un-noticed, further leading an attacker to maintain his persistence in the system, perform lateral movements and compromise critical systems.

This can easily be prevented if system is configured to identify and prevent the attempts of attack with the help of logging and monitoring.

“There is no walkthrough for Insufficient logging and monitoring since it a design flaw and an attacker has no role to play in exploiting this issue”

References:

roottusk/vapi

OWASP API Security - Top 10 | OWASP

OWASP API Security Top 10

Thank you!

This was the first ever public blog written by me, please let me know how do you like it?

Follow for reading upcoming blogs on cyber security. Thank you.