Getting Reverse Shell in crAPI - Part I

Introduction

Recently, I’ve started to play with OWASP crAPI (completely ridiculous API) to help me prepare for INE eWPTX certification. There are a lot of vulnerable apps and environments (Juice shop, Multillidae, DVWA, WebGoat and so on) to get hands-on experience in application security testing in a safe way. However crAPI got my attention because it is designed specifically for API security tests and includes modern features (like LLM, email and OTP integrations).

Security Assessment of Video Upload Feature

During my inspection on video upload feature of crAPI, I realized some sensitive data is being returned (conversion_params). This data exposure weakness is also known as CWE-213.

During testing to change video name feature, I suspected that it may also be vulnerable to mass assignment (see CWE-915 and BOPLA in OWASP API Security Top 10). I wanted to check if the request body was being passed directly into database query (without stripping out the properties other than videoName).

Verifying The Vulnerability

To test if other parameters are passed to database query, I injected conversion_params into the request (by intercepting and manipulating the communication between browser and web server via Burp Suite).

I assumed those params are passed to a video processing tool like ffmpeg, so tested if it is being executed directly. I’ve appended && sleep 10 to test command injection weakness (CWE-78) along with mass assignment. I assumed the conversion operation is done by combining command and conversion params (something like: ffmpeg ${conversion_params} -i ${video_name} ${video_output_name}).

As you can see the image below, user input is stored as it is in the database. Hence I confirmed that it is vulnerable to mass assignment.

If it did wait 10 seconds to return the response, I would prepare my script and listening ports to get a reverse shell inside the web server. But the response returned within a second.

At this point, I am thinking that this video conversion is not done in this endpoint, and most probably done by a separate worker process. This is a logical thing to do in a good system design, since video conversion may take a while and users do not need to wait for it.

Then I saw the “Share video with community” button in the application. When I clicked, browser sent a GET request to /identity/api/v2/user/videos/convert_video?video_id=52 endpoint and it returned following error response:

{
    "message": "Thi-S endpoint S-hould be accessed only inte-Rnally. -Fine? , endpoint_url http://crapi-identity:8080/identity/api/v2/user/videos/convert_video",
    "status": 403
}

crAPI creators gave a hint for the next step (see abbreviation for S-S-R-F - Server Side Request Forgery), which supports validity of my assumptions.

Wrap Up

Up to this point, I’ve confirmed that POST /identity/api/v2/user/videos endpoint has Broken Object Property Level Authorization vulnerabilities (excessive data exposure and mass assignment weaknesses are exploitable). These types of vulnerabilities can be prevented by mapping and validating user input, specifying expected structure (via Data Transfer Objects - DTOs).

Also see OWASP Cheatsheet for Mass Assignment for understanding and preventing such vulnerabilities.

The next steps can be:

• finding some other part of the application which is vulnerable to SSRF,
• then get a reverse shell by chaining this vulnerable video upload feature.

I will cover these in next blog posts.