MetaCTF ⚑ Write-Ups

MetaCTF ⚑ Write-Ups

Challenge 3: Challenge categories: Web Exploitation

Challenge Name: Login Query 

Tools: Burp Suite.

Challenge Description:

In this challenge, we need to find the password for "jim404" without using a forgot password functionality. The challenge provides a source code link to help identify the loophole and bypass the login process.

This challenge teaches us how to extract database information using SQL queries. As mentioned in the challenge description, it appears to be an SQL injection attack.

Source Code Analysis:

Download the source code using the link provided in the challenge description. Upon opening the source code files, you'll observe that they contain the login page (index.php) and (app.py), which houses the backend code for the login process. This CTF challenge is written in Python.

The index.html file contained both the login page code and the JavaScript code. The JavaScript includes an asynchronous function called login() that manages the user login process on the webpage. This function communicates with a server to authenticate the user's credentials and updates the webpage based on the login's success or failure.

Another file is app.py. This file contains the backend code used to manage the login process and validate the username and password with the database.

Upon reviewing the code, it was observed that the application lacked proper validation for the username and password parameters. The SQL query is constructed by directly concatenating user input (username and password_hash) into the query string. This practice makes the application vulnerable to SQL injection attacks, allowing an attacker to manipulate the input and potentially execute arbitrary SQL commands.

In the above image, the Python code is part of a Flask web application. It defines two routes ("/" and "/login") and handles requests to these routes. In the def Login() function, line 21 retrieves JSON data sent in the POST request body and stores it in the data variable. The next two lines extract the username and MD5 hash password.

The SQL query is a particularly interesting part of this code. It selects the username, public_btc_address, private_btc_key, and balance from the users table. The query filters results based on matching username and password_hash values against the provided credentials.

It’s observed that the application has not implemented any validation on username and password_hash parameters. Now, let's exploit this vulnerability using the information we've gathered.

Challenge exploit:

Open the given login page using the given URL in the challenge description.

We use the Burp Suite tool to capture the requests.

After intercepting the login request with the username "jim404" and a random password, we examine the response. The response reveals the entire SQL query along with a login failure error message.

Breakdown the query:

Query :

SELECT username, public_btc_address, private_btc_key, balance FROM users WHERE username='admin' AND password_hash='0a1f508dd056bb8d1052ec6a6cb5b8b3';

The query is designed to retrieve the username, public_btc_address, private_btc_key, and balance from the users table for the user whose username is 'admin' and whose password_hash matches the provided hash ('0a1f508dd056bb8d1052ec6a6cb5b8b3').

To verify the username parameter's vulnerability to SQL injection, we employed the query ' or '1' = '1';--. This is a common technique used to exploit SQL injection vulnerabilities. Its most potent effect is when it successfully bypasses authentication controls.

In this scenario, the input ' OR '1'='1' can bypass the authentication check because '1'='1' always evaluates to true. This could potentially lead to the retrieval of all records in the users table. Additionally, the double dash (-- ) signifies an SQL comment which causes the SQL query to ignore the remaining part of the query, including the password check.

SELECT username, public_btc_address, private_btc_key, balance FROM users WHERE username='' OR '1'='1'; --' AND password_hash='d41d8cd98f00b204e9800998ecf8427e';

The "username" parameter is closed and then a "or" statement is used. This means that if the "username" parameter is not true, then the condition "1=1" is always true. After that, a semicolon is used to end the query, followed by double hyphens to comment out the remaining part of the query.

Once we successfully bypass the authentication process, only the admin data is shown, but we need the "jim404" user account to get the flag.

To exploit the SQL injection for the jim404 user, we are using a UNION-based SQL injection attack.

The UNION operator allows you to combine the results of two or more SELECT statements into a single result set.

• Each SELECT statement within the UNION must have the same number of columns in the result set with the same data types in corresponding columns.
• The columns in each SELECT statement must be in the same order.

Craft the payload using the query:

Payload:

jim404' UNION ALL select null, null, null, password_hash from users ;--

Final Query:

SELECT username, public_btc_address, private_btc_key, balance FROM users WHERE username=''jim404' UNION ALL select null, null, null, password_hash from users ;--' AND password_hash='d41d8cd98f00b204e9800998ecf8427e';

To find the password_hash for the user jim404, use the UNION ALL function to concatenate all the strings and get all the data

• jim404': This is the part of the username parameter that closes the existing username string in the original SQL query. If the original query uses a single quote (') to wrap the username, the attacker's input will terminate the string.
• UNION ALL: Combines the results of two SELECT statements. UNION ALL includes duplicate rows, whereas UNION would remove them.
• SELECT null, null, null, password_hash FROM users: This is the injected SELECT statement. It selects three null values followed by the password_hash from the users table.
• ;--: The semicolon (;) ends the original query, and -- is a comment that ignores the rest of the original query. Everything after - is treated as a comment by the SQL engine, effectively removing the password check in the original query.

WOOT, successfully get the FLAG for the “jim404” account.

Reference :

• https://portswigger.net/web-security/sql-injection/examining-the-database
  
• https://www.w3schools.com/sql/sql_union.asp

Mitigation:

• Use parameterized queries or prepared statements.
• Properly sanitize all the user-submitted values used in the query before using them.
• Disallow common characters used in SQL Injection payloads, such as the characters “<>/?*()&” and common SQL operations like SELECT and UPDATE.

LinkedIn: https://www.linkedin.com/in/sudeeplamsoge/
Twitter : https://x.com/SudeepLamsoge