Dear-QS | CTF

Hello exploiters, welcome back to my channel. Today, I am going to solve a CTF challenge which includes: exploitation, reversing, asm and pwntool

I highly recommend that the information security community look at this challenge.

To solve this challenge, we need to consider a few things, which I want to show you while writing this blog.

We should analyze the file before exploiting and reversing the file.

Let's get started to exploit the vulnerability.

Analyzing the file

You should always consider that when a file has been given to you to analyze the file with some commands:

1. file command

The Linux file command helps determine the type of a file and its data. The command doesn’t take the file extension into account, and instead runs a series of tests to discover the type of file data.

As you can see that file has data of 64 bits. We have to behave in a 64-bit format. I had already used the sudo chmod +x command.

2. strings command

Awesome ! /bin/bash is given, and that allows us to get the shell from the system.

The strings command in Linux will return each string type of characters that are printable in the file.

What we are doing statically is to determine what kind of strings, bits, or whatsoever is given to us.

Before analyzing the file, it is well recommended to use static tools or commands to determine your action to exploit it.

We understood from this file that we can use an exploitation technique to be rooted. But we need to consider what kind of vulnerability is being affected.

3. checksec command

I am not going too deep into this security mitigation, but I will want to cover some of them. You can check this blog if you want to know more about it: https://medium.com/@slimm609/checksec-d4131dff0fca

PIE

Executable Linkable Format (ELF) files have a fixed base address space and must be loaded in that address space during execution. Dynamic executables are normally position-dependent and require fixed address space in memory.

No-Execute (NX)

No-Execute is a technology used in CPUs to split areas of memory into 2 sections: storage of code and storage of data. This splits up what should be executed as program code and what should be read as program data.

Stack

Stack-smashing protection uses canaries, predetermined values inserted between the memory buffer, and control data on the stack to monitor buffer overflows. When an application executes, memory gets allocated to the process.

As you can see above that we do not have to worry about these security mitigations.

I am going to try to exploit this file with the help of buffering with ‘A’s

Awesome! We see that a segmentation fault has appeared. We should consider reviewing disassembled code with Cutter.

First of all, scanf() is considered a dangerous function in C language but why?

The main reason is that scanf() and any function that writes to memory without regard to allocations and sizes can potentially write to memory reserved for something else — this behavior is also known as “buffer overflow”.

The most dangerous buffer overflow is when scanf() writes to memory on the stack which, among other things, contains return addresses (the address in code a procedure jumps to when it finishes its work). If the return address changes to something desired by say, a malicious attacker, they can potentially cause the process to do stuff they intended (this is known as exploitation) and ultimately hack the system in all sorts of ways.

We know that scanf() takes 0x20 bytes (32 as decimal) so we will use the GDB debugger to investigate more in-depth.

Let me also note that is not considered an uncontrolled format string vulnerability because:

the format is given as ‘%s’ the parameter is given as a string to stdout. We are concerned about buffer overflow by overflowing the stack and manipulating the return address.

GDB-PEDA

We already knew that 0x20 bytes has been stored to RSP(stack pointer). I decided to create a pattern that includes 100 characters because we should know the offset to manipulate the return address.

You can use ‘info functions’ to view the functions inside the file. Our target is: vuln()

Now I am going to run this file with 100 characters.

We just calculated the offset of ‘RSP.’ we should have already known that RSP was given 0x20 -> 32 bytes.

Awesome! We are going to try something that we can make sure that it works 32 bytes + 8 bytes let's give it a try.

Please note → The %rbp register has a special purpose: it points to the bottom of the current function’s stack frame, and local variables are often accessed relative to its value. However, when optimization is on, the compiler may determine that all local variables can be stored in registers.

We are working with 64-bit it may differ from 32-bit.

Awesome! we just need to find the memory address of vuln()

Awesome! it starts at 0x400686 memory. Now, we are able to manipulate with the help binary-exploitation technique.

PWN-TOOLS

We know everything about this file. We know the offset, and memory address of vuln and add 8 bytes to manipulate the return address.

I first tried to deceive the file locally.

1. We know that 0x20 bytes were being stored in RBP
2. We also calculated the offset which was (40) I subtracted (offset-RBP)
3. In the third step, I created a payload that I mentioned

result:

It did work locally, now I am going to try remotely.

I was trying to scan with NMAP tools to analyze the port, and the result:

port 5700 is for us enabled to deceive the system.

Awesome! I am going to use the shell to make it stable.

It was easy to use /bin/bash to get the shell.

We are now able to read the flag.txt.

Summary

First of all, I highly recommend it to people who want to learn and get into binary exploitation and reverse engineering candidates. It was well worth spending my time to solve and write such a blog for enthusiastic people. If you did not understand this challenge please then ask me questions to figure out your problems together!

I will write more blogs about this topic.

The level will be easy, intermediate, and hard challenges. Thus stay tuned people!

You can follow me on social media:

LinkedIn: https://www.linkedin.com/in/ahmetgoker/

Instagram: https://instagram.com/0xcd4_

Twitter: https://twitter.com/TurkishHoodie_

GitHub: https://github.com/0xCD4

Thank you for spending your valuable time reading this blog!

~ 0xcd4