pay-to-win
Category: Web
Description
This service is wayyyyy to expensive. I can't afford that! I did hear that premium users get a flag though...
Attachments: server.zip
Write-up
When we access the provided URL, we are presented with the following web page:
After entering a random name and logging in, we are redirected to the following page:
At first glance, there doesn't seem to be anything particularly interesting on this page. Therefore, we proceed to analyze the underlying codebase for potential vulnerabilities.
Upon examining the web application's code, we identify two noteworthy endpoints.
The first one is the index (/
) route, which handles the main page:
From the code snippet above, we can infer the following behavior of the index page:
1. It checks if the user is authenticated by verifying the presence of the data
and hash
cookies. If they are not set, the user is redirected to the login page (/login
).
2. It creates and validates the login data with expected hash value.
3. If the validation fails, the user is redirected to the login page.
4. If the validation succeeds, the user is redirected to a page specific to their user_type
as specified in the login data.
The second interesting endpoint is related to the login process:
In this code snippet, we can observe the creation of the data
and hash
fields in the cookie when a user logs in. Notably, each user is assigned a random hexadecimal value, presumably representing their user ID. This ID is then used, along with the login data, during the hashing process.
Text Only | |
---|---|
Additionally, we learn that by default, when a user logs in, their user_type
is set to basic
. Our objective is to manipulate the login data to have a user_type
of premium
instead of basic
, which will grant us access to the premium page.
To achieve this, we need to modify the login data and specify a user_type
of premium
without compromising the integrity of the data which will result in a hash mismatch and failed validation. This can be accomplished by logging in with a custom hash value corresponding to the manipulated login data and user's ID which were needed during the hashing process.
Given the final hash value obtained after logging in, we can perform a brute-force attack on the 24-bit (2^24 iterations) user ID and check against the final hash. The iteration that matches the hash corresponds is the user's ID.
Since we know the final hash value sent after logining, we can do a bruteforce of 24 bits (2 ** 24 iterations), and check against our final hash. The iteration that matches will be our user's id.
The Python script get-user-id.py automates the brute-forcing process to determine the user's ID based on the provided hash.
Output of get-user-id.py
:
With the user's ID retrieved, we can generate the premium cookie content using get-payload.py, which allows us to escalate the user's privilege.
Output of get-payload.py
Text Only | |
---|---|
We can modify our cookie with the obtained information to gain premium access.
Upon accessing the premium page, we notice that it appears to have limited functionality, mainly the ability to change themes.
By examining the URLs of the above two images, we observe that they reference local files using the theme
query parameter. This suggests a potential vulnerability related to local file inclusion.
To verify this vulnerability, we analyze the premium page template:
Based on the code snippet, the endpoint renders the template using return render_template('premium.jinja', theme_to_use=open(theme_name).read())
, where theme_to_use
is populated with the contents of the specified file.
By specifying the path to our flag file, we can retrieve the following image:
Upon inspecting the page source, we find our flag injected between the <style>
tags:
Flag: tjctf{not_random_enough_64831eff}