During the DefCon30, Las Vegas, a CTF was made byCheckmarx guys called C{api}tal in the AppSec Villiage CTF based on the API OWASP TOP10. The challenge is divided into ten levels based on the Pokémon figures, so as a Pokémon master, I had to catch them all!
The CTF tasks categories were as follows:
- Broken Function Level Authorization
- Broken Object Level Authorization
- Broken User Authentication
- Improper API Management
- Excessive Data Exposure
- Improper Assets Management
- Lack of Resources and Rate Limiting
- Security Misconfigurations
- Injection
- Mass Assignment
- Security Misconfiguration
- Insufficient Logging
To play, I had to download the challenge locally using Docker and with little docker-compose…Let’s get started!
# Level 1: Broken Function Level Authorization
The challenge description:
As described, we need to find some hidden path within the app that has broken function level authorization; therefore, we can access it without any authorization mechanism. One of the common ways to do that is to look for hidden administrative interfaces.
As the app is based on an AngularJS application, I decided to take a look at the bundle.js, which contains all the JavaScript hardcoded logic and paths:
With Burp Suite, I tried to access the path directly, and I got our first flag:
# Level 2: Broken Object Level Authorization (BOLA)
The challenge description:
In BOLA, we need to identify an API method that does not implement any access control check. It usually does happen with API methods that accept user input in their query string or path variables (for example: /users/<id>/info).
As part of the CTF, we were given the API documentation (as Swagger and Postman), so I decided to have a look at the Postman first, and I found the following API method:
Based on this method, we need to provide the article slug (aka “name”). Let’s view one of the articles:
Great! Let’s take that slug and send it to our API endpoint to get our flag:
# Level 3: Broken User Authentication
The challenge description:
So I decided to start with basic OSINT, read the post in the application, and see if anything came up. As I’m pokeing around, I found that Pikachu has several positions with his email address and some list of other Pokémon’s colleagues, I guess?
The idea that comes up to my mind is that: Maybe we can use brute force attack as part of the Broken User Authentication issues, as no other Pokémon has his email published… and also we got a decent amount of possible passwords.
So I used the Burp Suite Intruder feature to load all those Pokémons as passwords while using Pikachu’s email address:
And finally, we got our flag:
It seems that Pikachu like Snorlax very much : )
# Level 4: Improper API Management
The challenge description:
The first thing that I thought in terms of this vulnerability is to automate a discovery process for every account in that system and see if any API endpoint leaks any excessive data.
I used Burp Suite agin to automate the process for the GET profiles method as the first try:
Then, it was found that Rocket Team has some credit cards exposed (ironecly right?):
Let’s try to use their card as Pikachu as sweet revenge to buy a membership… and we’ve got our flag:
# Level 5: Improper Assets Management
The challenge description:
Like in real life, developers are using version controls to track their API development when new features are coming out or deployed to production. So I decided to take the only API endpoint that I found with version control — the login API:
By modifying the version from 2 to 1 I would expect that the API endpoint will have some hidden gem… and I was right, the old API endpoint contains our flag:
So far we’re halfway in… but gotta catch em all! See you in Part 2!
M.
