This is the explanation for a script to brute-force MongoDB SCRAM authentication when all the required parameters are known or can be obtained (from a .pcap file for example).

It can be useful for Boot2Root challenges.

The authentication protocol is described here https://www.mongodb.com/blog/post/improved-password-based-authentication-mongodb-30-scram-explained-part-1.

From the script perspective, all the parameters are known except the password which is the target.

The objective is then to simulate the authentication protocol until such point the client proof is generated and then compare to what we already have.

The simulation of the protocol is made using https://github.com/tlocke/scramp which greatly simplifies the code.

The computation of the client proof is,

def get_client_proof(username, password, client_nonce, combined_nonce, salt, iteration_count):
    client = ScramClient(MECHANISMS, username, password, c_nonce = client_nonce)
    client_first = client.get_client_first()
    client.set_server_first(f'r={combined_nonce},s={salt},i={iteration_count}')
    return client.get_client_final().split(',')[2]

The full script can be found at https://github.com/glslang/mongo_scram_brute.

Shakabrah is a warm-up box in Offensive Security’s PG Play platform.

Recon

Nmap found two open ports, SSH (22) and HTTP (80).

HTTP Port 80

We’re allowed to run a ping command (connection tester) remote commands through the web interface. By simply clicking on go we get,

From here we can attempt to gain RCE by exploring what the interface allows us to do. Rather than trying to fuzz what commands we can run, even though this is a good exercise on its own, we can simply explore it manually. In particular does it allow to chain commands.

And in our python http handler,

This being the case we can simply try to get RCE by running a python reverse shell.

We get our shell back and we now have access as www-data.

The reverse shell I used is from https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md#python.

A topic that comes up frequently on PG Play/Practice is why only some ports work for reverse shells. In general, one should try ports that nmap identified as open since they’re likely to also allow for outbound connections.

Also don’t forget to try python3 if python alone doesn’t appear to work.

Privilege Escalation

Enumeration of SUID binaries shows us that vim.basic is SUID as root.

From https://gtfobins.github.io/gtfobins/vim/ we get several possible ways of getting a root shell.

Importantly, we also find from vim.basic -version that it has python3 support. With these two pieces of information we get a shell with a EUID of root.

Conclusion

Shakabrah is a fairly easy Play machine with a PWK lab feel to it suitable for beginners.

The challenge is a small reverse engineering problem.
The program will print ‘Correct’ when run with the right flag passed to it
as the 1st argument.

Loading the binary in Ghidra, and inspecting the decompilation window, the
structure of it can be roughly subdivided in 5 parts.

1. Checking the size of the argument and if the flag starts with TWCTF{

2. Two nested loops doing some basic operations (addition, xor, shifts) followed by 4 memcmp with fixed memory address arrays

the second nested loop,

3. A single loop assigning constants followed by a memcmp with a fixed memory address array

4. A loop doing a reduction of fixed locations of the input and checking against a constant

5. A series of checks against fixed locations of the input

From the above we can develop our exploit script as follows,

1. Use pwn to read the fixed memory addresses to compare against

2. Develop our Z3 model based on the expected size of the flag

3. Transcribe the loops from Ghidra and add the constraints to our Z3 model

4. For all possible satisfiable answers, run the executable with our current flag candidate

For simplicity, we’re going to create a bit vector using 4 bytes for each of the possible characters of the flag. This is done in line 29.
Lines 32–68 simply use the code decompiled by Ghidra to run the same operations as the binary and set up the constraints
that mimic the memcmp calls, the reduction and the if statements.

With our model built and after checking it’s satisfiable we loop until a solution is found.

The most interesting part in this section is line 87 which ensures our previous candidate attempt is no longer tried.

The solution is printed after a few secs of running the script.

Introduction

The 0x00sec CTF exercises (https://0x00sec.org/t/introducing-bi-monthly-0x00sec-ctf-exercises/19044) are a welcome addition to the CTF scene allowing for a short 10–30 minute solve.

In this post I share my thought process and describe a possible walk-through leading to the flag.

The Challenge

The exercise can be found by following the link from https://ctf.0x00sec.org/.

This one is a crypto challenge and we’re given two hints; decode and use XOR to get the flag.

The decode part is easy. From previous challenges we can now recognize it’s base64 encoded.

We now need to use XOR to obtain the flag. But with what? We need a key and we’re not given any hints about it. But, we know,

The flag must start with flag{.

ciphertext XOR key = flag{…

ciphertext XOR flag{ = key…

With the above we’re now ready to write some python that implements the above,

The code above implements our algorithm and prints the flag. It also makes the assumption that the key size is the same length as flag{. This is reasonable since we’re not given the key size from the challenge.

Conclusion

In this post I shared a possible walk-through of 0x00sec CTF exercise 07.

Introduction

The 0x00sec CTF exercises (https://0x00sec.org/t/introducing-bi-monthly-0x00sec-ctf-exercises/19044) are a welcome addition to the CTF scene allowing for a short 10–30 minute solve.

In this post I share my thought process and describe a possible walk-through leading to the flag.

The Challenge

The exercise can be found by following the link from https://ctf.0x00sec.org/.

In this exercise we are greeted with a page that simply checks our IP against a whitelist and denies access.

Since we cannot interact with the page it’d appear all we can do is change the headers of the request.

What would be an IP that is whitelisted? We can simply try 127.0.0.1. And what would be a good header? It is X-Forwarded-For.

We can try it with the following command,

curl -H “X-Forwarded-For: 127.0.0.1” -X GET “https://exercise-6.0x00sec.dev/"

The response contains the flag.

Conclusion

In this post I shared a possible walk-through of 0x00sec CTF exercise 06.

Introduction

The 0x00sec CTF exercises (https://0x00sec.org/t/introducing-bi-monthly-0x00sec-ctf-exercises/19044) are a welcome addition to the CTF scene allowing for a short 10–30 minute solve.

In this post I share my thought process and describe a possible walk-through leading to the flag.

The Challenge

The exercise can be found by following the link from https://ctf.0x00sec.org/.

In this exercise we are greeted with a page containing a single login button.

Right clicking and selecting view page source we can see two interesting comments, “Stop relying on Base64” and “backup pass in /etc/passwd”.

Further examining the source we see two parameters being passed into the form. The ‘p’ parameter is Base64 encoded and it’s the one we need to change in order to access /etc/passwd.

Following the above reasoning, what would be a good parameter? There’s a few things we could try but ultimately it’s file:///etc/passwd.

We can use a little bit of python to automate the request and get our flag,

The response contains the flag.

Conclusion

In this post I shared a possible walk-through of 0x00sec CTF exercise 05.

Introduction

The 0x00sec CTF exercises (https://0x00sec.org/t/introducing-bi-monthly-0x00sec-ctf-exercises/19044) are a welcome addition to the CTF scene allowing for a short 10–30 minute solve.

In this post I share my thought process and describe a possible walk-through leading to the flag.

The Challenge

The exercise can be found by following the link from https://ctf.0x00sec.org/.

In this exercise we are greeted with a form allowing for username and password and the objective is to get the flag.

Right clicking and selecting view page source we can see an interesting comment, “Restrict debug log access”.

From the hint above it seems we can access the debug log. But how? The obvious url to try is simply https://exercise-4.0x00sec.dev/debug.log.

Does it work? Yes it does! The log contains a lot of header information but in particular we’re interested in the cookie for the PHP session ids. Our next idea is to simply iterate through the session ids and attempt to get the flag from the server reply.

There’s a lot of them so we’re going to automate it with a little bit of python,

Our python script requests the debug.log and then iterates over the session ids. It stops when the flag is found in the reply.

There are many ways on how we could improve the script but is not necessary for this particular exercise.

Conclusion

In this post I shared a possible walk-through of 0x00sec CTF exercise 04.

Introduction

The 0x00sec CTF exercises (https://0x00sec.org/t/introducing-bi-monthly-0x00sec-ctf-exercises/19044) are a welcome addition to the CTF scene allowing for a short 10–30 minute solve.

In this post I share my thought process and describe a possible walk-through leading to the flag.

The Challenge

The exercise can be found by following the link from https://ctf.0x00sec.org/.

In this exercise we are greeted with a form allowing for username and password and the objective is to get the flag. We can simply try the combination of admin/admin but this time we’re greeted with detailed user data for the user.

Right clicking and selecting view page source we can see an interesting comment, “Implement secure object references”.

Looking at the URL we can see https://exercise-3.0x00sec.dev/index.php?user_id=5.

From the above it appears we can simply enumerate the user_id and we’ll be able to find our flag. As it turns out this is the case, so we can simply start at 0 and continue until we have our flag.

Conclusion

In this post I shared a possible walk-through of 0x00sec CTF exercise 03.

Introduction

The 0x00sec CTF exercises (https://0x00sec.org/t/introducing-bi-monthly-0x00sec-ctf-exercises/19044) are a welcome addition to the CTF scene allowing for a short 10–30 minute solve.

In this post I share my thought process and describe a possible walk-through leading to the flag.

The Challenge

The exercise can be found by following the link from https://ctf.0x00sec.org/.

In this exercise we are greeted with a form allowing for username and password and the objective is to get the flag. We can simply try the combination of admin/admin and will get incorrect password.

Right clicking and selecting view page source we can see an interesting comment, “Implement secure sessions”.

Toggle developer tools on your browser and inspect the POST request. The session cookie is of the form PHPSESSID=YXV0aGVudGljYXRlZD10cnVlCg%3D%3D.

The session id is url encoded and in base64. Therefore we need a little bit of python to help us,

From the gist we can see that the session cookie is simply “authenticated=false”. We simply encode “authenticated=true” and do request using our new session id cookie,

curl -X POST -v -H ‘Cookie:PHPSESSID=YXV0aGVudGljYXRlZD10cnVlCg%3D%3D’ https://exercise-2.0x00sec.dev/?user=admin\&password=admin.

The response reveals the flag.

Conclusion

In this post I shared a possible walk-through of 0x00sec CTF exercise 02. This exercise was a simple one but that is the point. They’re small brain teasers.

Introduction

The 0x00sec CTF exercises (https://0x00sec.org/t/introducing-bi-monthly-0x00sec-ctf-exercises/19044) are a welcome addition to the CTF scene allowing for a short 10–30 minute solve.

In this post I share my thought process and describe a possible walk-through leading to the flag.

The Challenge

The exercise can be found by following the link from https://ctf.0x00sec.org/.

In this exercise we are greeted with a form allowing for username and password and the objective is to get the flag. We can simply try the combination of admin/admin and will get incorrect password.

Right clicking and selecting view page source we can see an interesting comment “Remove the git directory after publishing”. If the developer forgot to remove the .git directory then it’s possible to reconstruct the source code for the form.

Recall that a .git directory contains all the information associated with a repository and it is possible to find the SHA commit for current master by following .git/refs/heads/master.

This allows us to find the current HEAD master commit simply by going to https://exercise-1.0x00sec.dev/.git/refs/heads/master. The result we get is 05480569507a37df7731115a5888f91b145c189d.

Since we now know the commit SHA of master’s HEAD we can browse the .git/objects directory for it. The .git/objects directory contains sub-directories corresponding to the first two hex digits of the SHA with the object filename being the remaining digits.

We can now get our HEAD commit by browsing to https://exercise-1.0x00sec.dev/.git/objects/05/480569507a37df7731115a5888f91b145c189d and download the object file.

The object files are compressed using zlib so a little bit of python is required to view its contents,

After decompress we get,

commit 212tree b63be1fb236a6be035cd8573a585a356d47285fa
parent c13f81bf0a2f2c0e64a97a316bf3df3ccccea25a
author pry <pry@Ghostbook-Air.home> 1581195325 +0000
committer pry <pry@Ghostbook-Air.home> 1581195325 +0000

We can now follow the same process and download the object for the tree b63be1fb236a6be035cd8573a585a356d47285fa. Decompressing the tree object and piping to the Linux utility hd, we get,

00000000 74 72 65 65 20 37 33 00 31 30 30 36 34 34 20 69 |tree 73.100644 i|
00000010 6e 64 65 78 2e 70 68 70 00 49 0d f3 ef e4 5d 6c |ndex.php.I….]l|
00000020 c6 73 21 19 32 04 f1 64 9a 57 a3 6c 83 31 30 30 |.s!.2..d.W.l.100|
00000030 37 35 35 20 73 74 61 72 74 2e 73 68 00 bc ad c6 |755 start.sh….|
00000040 66 0a b5 4f a5 51 90 bc aa a5 e9 1d f0 8b 34 92 |f..O.Q……..4.|
00000050 5f |_|
00000051

We’re interested in index.php and we can find its SHA from the above after the last character p and the null terminator. The SHA is 490df3efe45d6cc67321193204f1649a57a36c83. Repeating the same process of downloading and decompressing this object we find the source code for index.php. Inspecting the source code we learn that the user is admin and the SHA256 for the password is e83176eaefcc1ae8c4a23dbc73ebcf122f26cfb9ba5c7cf4763e96c1c38a6c6c.

All that is left to do is to go to https://crackstation.net/ and see if is a known one. As it turns out it is and we get our password.

Going back to the main exercise page we simply type our combination of user and password, and get the flag.

Conclusion

In this post I shared a possible walk-through of 0x00sec CTF exercise 01 and although some of these steps are manual, a lot of the work could be automated, something I’ll share in a later post.