May Mayhem - Walkthrough

i. Admin Login#

Opening the link will show us a simple admin login portal,

Let's try a simple directory bruteforcing to check if there are any hidden endpoints

So, the application is built using python & debug mode in enabled.
Checking the source code will reveal that, once we submit the username & password, it'll be sent to /api/v3/login as JSON (like this {"uname":"tuhin1729","pwd":"r4nd0m_p4$$w0rd"}). If the username & password matches with the database, it'll respond back with auth token & further send the auth token to /api/v3/validate as JSON (possibly for validating the auth token).

Let's try to perform a directory bruteforcing at http://<IP>/api/v3/

We got a new endpoint /api/v3/signup. Looks like the developer forgot to disable signup. Let's try to create a new account,

Now, let's attempt to log in and verify whether the account has indeed been created or not.

So, it's a JWT (JSON Web Token). We'll try to send the auth token to the endpoint /api/v3/validate.

Cool! Now we've a proper understanding of the flow. From the description of the challenge, we can assume that we need to login as admin.
So let's try to create an account with the username admin.

Let's try SQL Injection:

We've already discovered that debug mode is enabled, so let's try to generate some kind of errors, maybe the application will leak some sensitive information.
We can try to remove the pwd parameter and see how the application reacts:

Cool! We got the error, now let's view the error in browser:

There is a stackoverflow link in the comment. Let's see what it is:

So, the developer of the application posted the source code (or part of the source code) in stackoverflow for fixing SQLi vulnerability. Here is the entire code:

From here, we can see that the value of secret parameter $up3r_$3cur4_t0k3n is used to sign the JWT. In case, they've not changed the secret in production, we can forge the JWT to login as admin. For this, we'll copy the JWT of our previous account & put it in jwt.io:

We'll change the username to admin, isAdmin to 1 and sign the token with the secret. Finally, we'll send it to the validate endpoint to get the flag:

ii. Vaults Revenge#

Difficulty: Hard
Points: 300
Category: pwn

The name of this challenge is related to the last month's pwn challenge Vaults(which got 0 solves), the challenge handouts included, an ELF binary, a libc.so.6,(later the Dockerfile was added too).

ELF File Analysis#

• Using the file command:

From running the command, we can deduce that this is a x64 binary, is dynamically linked meaning that the libc functions will be loaded at runtime.

• Using checksec

This gives us further idea of the challenge - The binary is not PIE enabled, meaning the binary will always be loaded at a fixed virtual address in the memory( 0x400000 )

Playing with the binary#

So firstly the binary prompts the user to enter some data to store in an extra space as a token of gratitude. Next we are presented with a menu with 4 options:

The vaults structure basically looks like as shown below:

• Create(Vault)

• Read/View(Vault)

• Update(Key)

• Delete(Vault)

So we have our basic CRUD operations in place. Let's check out what these look like in Ghidra.

Ghidra is an open source decompiler and disassembler, which provides us with a pseudo code in C/C++ or whichever language was detecting while analysing the binary, which is a close approximation of what the original code must have looked like.

Main Function#

The main function decompiled by Ghidra:

As we can see, some space is allocated on the stack of main (184 characters), and 0xb0 (176) characters are read from the user and stored in the buffer. Then we enter our menu loop.

Let's look at each of the menu functions one by one:

create_vault() function#

view_vault() function#

update_key() function#

There are also two very crucial functions: One is the win function named remote_debug which basically calls the /bin/sh system command. Another one is the b4ckd00r function, which provides us with very interesting write-what-where primitive, just before causing the program to exit.

b4ckd00r#

remote_debug#

Now let us try to analyse the different vulnerabilities present in this binary.

Uninitialized variable#

The binary provides us with an option to store a secret in our vault. But if we chose 'n' as the option, then it still copies whatever the previous value it had on the stack in the area assigned to the variable, to the secret buffer in our vault.

Let's examine what this value is:

As we can see it is a stack address!! Thus we have got a stack address stored in our vault, but we can't simply view it by opening the vault, as it is encrypted with a key that has random bytes in it.

XOR Oracle#

As you may have noticed, we have an option to update the key of a vault. This update logic is flawed, since it updates the key by copying the new key in the vault using the strcpy function, which also copies the trailing null byte. And we can also provide length of the key buffer to update. This will allow us to leak the secret byte by byte, as a byte XOR'ed with a null byte will give the original value of the byte itself.

For example when updating the first 2 bytes of the key:

The two bytes at the address stored in rsi will be copied along with the trailing null byte to the address stored in rdi after executing the strcpy function:

So now the encryption key contains a null byte. This will be XORed with the corresponding bit(3rd bit) of the secret(0xff) and we can see it in clear text! We can continue this process for other bits and retrieve the complete stack address.

Leaking Libc (Use After Free)#

Notice there is no check in the view function for checking if the vault is deleted or not? We can use this use-after-free read to leak the libc address! We just need to assign a large enough chunk to end up in unsorted bin after freeing, and it will obediently print out the libc leak in the comment to the accountant variable of the vault.

As we can see in the following screenshots.

After freeing the vault:

Brewing the exploit#

Ok... so we have a stack leak, libc leak, a way to overwrite 8 bits at any location we chose and a fixed offset to the libc, Naturally, the next question to ask is what should we overwrite?

The b4ckd00r function exits soon upon overwriting the bits at a specified address. How can we use it, if it is immediately calling exit() which will kill the program? Turns out, there are few functions related to file operations that get called during the exit of a program. To read about them, refer. This writeup will not be going in the depth of File Structure Programming, but the basic idea is to overwrite the vtable address in one of the _IO_2_1_stdout_, _IO_2_1_stdin_ or _IO_2_1_stderr_ structures to a location we can control and know the address to. The vtable is a jump table that contains addresses of functions used in file related operation, thus if we can forge a vtable and populate it with the address of remote_debug then we can pwn the challenge, as the exit routine calls functions from the vtable, like setbuf, to perform cleanup.But it will jump toremote_debug instead, once we overwrite the addess of vtable in one of those three structures. Since we have a stack leak, we should store this vtable in a variable on stack. Remember this at the beginning?

This is where we will store our forged vtable. and since we have a stack leak, we can easily calculate the address of this buffer on the stack. Then we just need to overwrite the _IO_2_1_stdout_->vtable (or any other standard file streams), to this address using the b4ckd00r function.

Fortunately, pwntools has a handy functions to create a fake vtable:

We can populate the functions of vtable using pwntools with the b4ckd00r function as follows:

The stack address of the temporary storage can be calculated by determining its offset from the stack address we leak by exploiting the weakness of encryption.

Therefore the calculated offset to the stack address is:

Now we just need to piece together all the different parts of the exploit to successfully get a shell!

The Exploit#

The exploit runs successfully, and we get a shell!

Hope you liked both challenges. Happy hacking!