In the first part of the C{api}tal CTF writeup, we’ve completed levels 1–5 while covering the following OWASP API risks concepts:
- Broken Function Level Authorization
- Broken Object Level Authorization
- Broken User Authentication
- Excessive Data Exposure
- Improper Assets Management
Now let’s continue with our missing to be master of Pokémon (or, in this case, an API Security master) :)
# Level 6: Lack of Resources and Rate Limiting
The challenge description:
In API security, there are two ways to make the API webserver consume more resources and lead to a lack of resources or denial of service (DoS); the first is to create a large number of requests or send multiple requests exceed the API server rate limit.
I decided to try to abuse the API web server rate limit; the problem was finding an entry point. After poking around, I discovered that the Articles API endpoint was limited to fetching every ten records from the database. So… what would happen if I attempt to ask for more documents from the database but in a large volume? Let’s try!
So I modified the limit value from “10”:
To “10000,” which probably causes to database error and to fetch our flag:
# Level 7: Insufficient Logging
The challenge description:
Based on the challenge description, we must find a way to abuse the application’s logging mechanism. The problem is that we don’t know what the endpoint is. The application doesn’t seem to send any logging API request, as well as no documentation in Swagger or Postman.
So back to the basics, we already know that the application has some hardcoded paths within its JavaScript bundle.js file, so let’s find it:
Great! Now let’s use Burp Suite to send a request to this API endpoint. I decided to try the GET HTTP method, and it seto work:
# Level 8: Mass Assignment
The challenge description:
Mass Assignment vulnerability is caused whenever the webserver assigns fields or server parameters based on the client request. Let’s try to simplify the concept with a basic example:
Assume we have a login page with the following HTML code:
<form> <input name=”username” type=”text”> <input name=”password” type=”text”> <input type=”submit”> </form>
But the backend has these parameters: username, password, and isAdmin. As we can see, the client code does not mention theisAdmin parameter in the HTML form. But! If we somehow know that this field exists, we can add it to our request as the isAdmin field, which causes the web server to process the field value as well though it wasn’t in the original form.
In our application, we can see in the login response that the user object has the isAdmin attribute:
Now let’s add this field to our client request; the web server will process that field and get us the flag:
# Level 9: Injection
The challenge description:
We need to find an entry point for some injection (might be SQL, XSS, NoSQL, etc.). After looking at the API documentation for research, I found that the documentation of Swagger and Postman was slightly different.
Looking at the Postman, nothing came up:
However, in the Swagger, there’s an additional method called “debug,” which accepts commands:
Interesting! Heading to Burp Suite to play around with that API method, we could see that only one command is supported:
Let’s run the uptime command:
Okay, let’s try to use that command as an entry point for command injection, and we got our shiny flag!
# Level 10: Security Misconfiguration
The challenge description:
Cool! Now we need to find a misconfiguration in the API infrastructure. It may be an open port, exposed header, outdated web server, etc. As I’ve been playing around with the app already, I couldn’t find any application-type of misconfiguration, so I decided to try with classic open ports stuff.
When I just installed the docker, I remembered it showed me that the Redis database had been installed, so let’s give it a shot!
I downloaded the Redis GUI (free) and tried to connect to the local Redis server BUT without a username and password at first:
So I got access as anonymous to the database! That’s a classic misconfiguration. Now all left is to clear our flag:
And we’ve done! I hope you enjoy it! If you are, please use the claps and share my post with your friends :)
M.
