Hello exploit freaks,
Welcome back to my channel. Today, I will be writing part 2 of the Binary-Heaven blog. I recommend you to read part 1 if you need to become more familiar.
For people who are read part 1, they should have become familiar with “How we found the username and password to get access through ssh”
Today, we are focused on “How we can abuse the binary file” to get access to “binexgod”
Understanding the security mitigation
To write an exploit script, we should consider, and check the security mitigations to write a script successfully.
When we used the ls command, we can see there was a SUID file called “pwn_me” interesting!
I am going to check the file with the help of some static tools.
When we used the file command, we could see that the file has been compiled in 32-bit, and it is not stripped which is great and make it for us easy.
I highly advise people during the reconnaissance phase, to check object dependencies with the help of the dd command.
/lib32/libc.so.6 -> is a symbolic link to the 32-bit x86 C library, used to run 32-bit executables.
To understand more about libc
When we used the strings command, we see that the output did not give a valid result.
I was going to check syscalls with the help of the strace command to see what kind of syscalls were being used.
We can see that access() has used 4 times, but what does access() mean in this phase:
access() checks whether the calling process can access the file pathname. If pathname is a symbolic link, it is dereferenced
Now, I was going to use a powerful command called readelf. When do we use this command?
When we compile source code, an object file is generated from the program, and with the help of a linker, this object file gets converted to a binary file which, only the machine can understand. This kind of file follows some structures one of which is ELF(Executable and Linkable Format). And to get the information of these ELF files readelf command is used.
We have a lot of options to check the binary properly. In this case, I used the -s flag to check the symbolic linkers of this file.
You might be asking “what is libc”? let me explain briefly.
The Glibc package contains the main C library. This library provides the basic routines for allocating memory, searching directories, opening and closing files, reading and writing files, string handling, pattern matching
I highlighted system@libc. I will explain this more in-depth when the exploitation phase is to be seen.
The last checkup was being used by the checksec command. If you are not familiar with these security mitigations, I recommend you learn and practice them.
The value (2) shown in the commands above indicates that ASLR is working in full randomization mode. The value shown will be one of the following:
0 = disabled
1 = Conservative Randomization
2 = Full Randomization
With this statement, we can see that ASLR protection is enabled. Thus, we have to be able to bypass this security mitigation.
Address space randomization hinders some types of security attacks by making it more difficult for an attacker to predict target addresses. For example, attackers trying to execute return-to-libc attacks must know (or compute) the location of the target function. These values have to be guessed to bypass the ASLR successfully. ASLR security is based upon the low chance of an attacker guessing the locations of randomly-placed areas, and so, the more entropy the more secure it is. There are three different entropy dimensions for each area:
1. Non-randomised: It is widely accepted that even a single non-randomized area can be used by attackers to defeat the ASLR. Therefore, all areas must be randomized.
2. Range of entropy: The size or range of possible values where each area can be located. The larger the range the better.
3. The relocation frequency: The frequency at which the areas are newly mapped. Ideally, every process shall have a custom memory space where all the areas are located at different places concerning previous executions of the same executable, and concerning other concurrent processes. The more frequent the better.
To exploit this mitigation, we first ought to know the addresses of libc and ASLR.
There are two possibilities to do so:
- Brute force attack
- Format string vulnerability and this allows us to read the memory addresses into the stack.
The range of entropy is seriously limited by the available virtual memory space. It is almost impossible to have a “decent” implementation on 32-bit systems; with only 256 possible values, it is considered almost useless. A simple brute force attack can defeat the ASLR in a few milliseconds. But on 64-bit systems, the range is large enough to effectively discourage attackers unless another method to extract information from the target process is available. Even in unrealistic attacks where the system does not provide the SSP and the NX bit protections.
Bypassing ASLR security mitigation
In this part, we are going to try to exploit the binary with the help of pwntools. Most people do like this part :)
Awesome! The system address is given to us, which makes it easier to handle it.
The question should be: “How can we get the system address through a python script” As I mentioned earlier, I am not an expert nor a professional at programming, but the internet has good documentation to understand it.
We can however see that the buffer overflow issue has occurred.
As you can see, we get only the address of the system. Now our next goal is to get the address of libc.
Let me show you some demonstrations:
Awesome! Now, I will be trying to get the address of the libc.
We already that ASLR is enabled thus address will consistently be changed.
As you can see above.
Suppose we run the command “ldd ./pwn_me | grep libc” and observe that only 2 bits are changing continuously. So in that case, we can calculate that one bit can change from 0-F, having 15 places, then 2 bits will give a combination of 15*15=225. So we had to run our script 225 times to hit the correct one.
- We first need to find the address of ASLR address
- When we find the address of ASLR, we need to subtract this from the leaked system address.
- When step 2 is done, we can find the real address (base address of libc)
- we can add to this libc.address
In order to calculate the offset we can use a cyclic pattern to create random characters:
Awesome! When we send 32 characters + /bin/sh or /bin/bash to execute a shell from the server.
It will be useful to find the /bin/sh or /bin/bash
In order to search /bin/sh we can use:
Awesome! Everything is well being coded. The next is to create a fake binary that also holds a real address.
To get more information: https://docs.pwntools.com/en/stable/rop/rop.html
the idea of chaining together small snippets of assembly with stack control to cause the program to do more complex things.
I am going to build a fake binary with the parameter that I created.
It works as follows:
I created a fake binary with the parameter “libc”, and then, I stored all those gadgets to libc to manipulate the library of that file. I was able to send some A’s to the ROP which is great!
The goal is :
- We know the offset of this file which is: 32
- After, I will manipulate and store the address of /bin/sh to the libc. In order to do that: a fake system() call will be great
You can get more info at: https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/gadgets
I forget to add the address(). The reason is that:
- We know the system address
- we know the libc address which continuously changed
- after, we would add to the libc base address.
After the progress:
We need to send the ROP chain, and in order to get the shell interactive()
Woohoo! we are now — -> binexgod
Path to root exploit
As last, we have a challenge called “path to root” exploit, let's see
This would be an easy challenge, however. We can just create an echo file with the parameter called system()
/usr/bin/env followed by the name of a program that executes that program. It looks up the program name as an executable file in the directories configured by the
PATH environment variable. It's a special case of the usage of
env is followed by some environment variable assignments and then a program name and arguments here there happen to be zero variable assignments.
Note that the output binary must be named echo because we are trying to replace the “legit echo” binary.
The final step: We are going to export the environment variable to get the root shell:
After, we can run the vuln binary again.
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:
Thank you for spending your valuable time reading this blog!