Codeby.Games. CTF TASK «ТЕТРИС»/«TETRIS»

Greetings to all CTF and ethical hacking enthusiasts on the Red Team side! In this article, we will review the walkthrough of a medium difficulty task "TETRIS," developed by pentesters from the Codeby.Games team.

Reference:codeby.games - a domestic conditionally free web project where anyone can practice refining offensive cybersecurity skills. Tasks are presented in a wide range: from using OSINT methods to compromising a training Active Directory domain. CTFs are divided into three groups - "Easy," "Medium," "Hard" in various categories. But more details can be found on the official project website.

The "Tetris" task is in the "Web" category. This category is dedicated to honing practical skills within the OWASP Top 10 framework. The goal of this task is to gain access to the web application's admin panel and capture the flag.

The general plan to solve the CTF looks like this:

1. Visit the web resource with a vulnerable API and study the API functionality.

2. Study the API source code and find vulnerabilities in the code.

3. Exploit the vulnerability.

4. Obtain the flag.

Commentary: at first glance, it may seem that the task is not that difficult. However, this is far from the case. The task belongs to the OWASP Top 10 category, which means attention must be focused on analyzing the application's logic and looking for errors/flaws related to its design.

1. Visit the web resource with a vulnerable API and study the API functionality

   We see in front of us a form for registering new users. We register with the default credentials "user:123"

   

   After authorization, a simple web interface appears before us, featuring the "game of millions" - Tetris. The logout option is at the top.

   

   The functionality is very modest to determine the attack vector. What to do next? Continue studying the application logic.

Let's try logging in under the admin account. As expected, we get an error - "invalid credentials". What to do next? Continue studying the application's logic.

One way to gain access to the admin panel is by resetting the password. Let's try using the "Forget Password?" form.

The server sent a password reset link to the email, which we, of course, do not know. What to do next?

2. Study the API source code and find vulnerabilities

We are very lucky, as the task includes a zip archive with the source code (in real life, this only happens when testing an API in White Box mode).

Comment: I apologize in advance to beginners: I will not describe the API code in detail, "chewing" every line. First, this will significantly increase the reading time of the article. Second, "Tetris" is still a task of medium complexity. It assumes that you are already proficient in programming languages (in our case, python), as well as having a good understanding of SQL queries and local databases. I ask for your understanding)

2.1 Run the application and start analyzing the file "main.py". The application is implemented in Flask, and after starting, it opens access inside the VLAN, generates a simple sqlite3 DB, as well as an admin password for the web interface, consisting of 12 characters of different case.

With each new visit to the web resource, the local DB and admin password are reset and then regenerated. From here comes the first conclusion: brute-forcing the admin password won't work.

2.2 Let's move on. We study the API functions and their purpose. Attention is drawn to reset_password and reset_uuid

The first handles the password recovery request, the second generates the link for password reset. We study the local DB file, which is automatically created when the Web API is launched.

Conclusions from API analysis:

1. The generation of reset_uuid occurs after sending a POST request to the endpoint /reset_password&&username=.

2. User password reset is performed as a result of a GET request to the endpoint /reset/.

3. According to the developer's idea, the link is sent to the email and cannot be intercepted. BUT!

4. The number of unique reset_uuid combinations is only 729 units. From the web application's security perspective, this is critically low. This means that...

The /reset/ endpoint is vulnerable to brute force!!

3. Exploiting the vulnerability

At first, the task seemed very simple to me. I generated a dictionary "tokens.txt" and ran Burp Intruder. But immediately faced a problem - I was able to reset the admin password, but could not start a new session as him.

Why did this happen? Because knowing about the vulnerability is not enough, you also need to understand how to exploit it. For this, we again return to logic analysis, but this time - on the server side.

What the "HttpOnly" flag is and how to bypass it, I suggest you study yourself :)

4. Capturing the flag

After overcoming the server-side protection, request the /admin endpoint and enjoy.

That's all. Happy bug hunting!)

P.s.

The task is truly interesting and - most importantly - useful from a practical point of view. User password reset is a basic functionality of any API. A developer can implement server-side protection, restrict access to the source code, ensure secure storage and transmission of links, but can forget about secure generation of the reset-link.

Could an attacker find this vulnerability without having access to the web application's source code? Yes. It is enough to register several user accounts and carefully study the password recovery links to identify certain patterns.