Reverse Engineering CTF. These are a series of challenges which need to be solved. We will be using Binary Ninja to reverse engineer the program. The program looks as follows with 3 different sections: 1. x64_ASMLets begin with section 1) x64_ASM. After pressing 1, we are presented with the following screen which asks for 2 args: Lets begin reverse engineering. The source code shows this function which handles the logic. As we can see the instruction_test(arg1, arg2) function plays a crucial role. Lets take a look at its assembly Very simple. If the result of the function does not equal 0x7a69 (31337), evaluation failed. Going back to the assembly provided in the first screenshot, some quick maths gives us the answer 30569. Therefore arg1 = 0 and arg2 = 30569 2. serialThe second challenge asks for a serial. Source code below: As you can see, the check_serial(serial) function does the heavy lifting. Lets analyse its assembly. The check_serial function looks to see if each value of arg1 is a particular number converting these hex to ascii gives us the following serial number: 189715 3. encryptThe third and final challenge asks for a password If you provide a password of the wrong length you receive this error: Lets look at the code and begin reverse engineering. As we can see from the code below, the password needs to 14 characters long (0xe = 14). Providing a password of length 14 gives us this screen. It appears to check each character. Analysing the earlier source code and assembly shows the check is done under encryption_check(password). Lets disassemble this function. Following the logic of the disassembled function, we can see that it takes our arguments and encrypts them via XOR against 0x17. If the output does not equal gW""`xesHav{~s, then it goes to the invalid_encryped_char() function. Therefore gW""`xesHav{~s is our encrypted string and with this, we can write a very simple decryption routine to obtain the password. Quick C++ program I wrote to decrypt and encrypt the strings for demo purposes. The decrypt function essentially reverses the XOR encryption routine. Encrypt function shows how the CTF challenge encrypts the password in the first place. Running the program outputs the following. 1) The decrypted string = p@55w0rd_valid 2) The encrypted string = gW""`xesHav{~s Entering the decrypted string into the CTF challenge shows us: Finished. Hope you enjoyed it.
0 Comments
5) Shared Object Library Hijacking/Injection 6) Exploits Shared Object library hijacking/injection From the title you can probably deduce what this is about. This method involves: 1) finding a binary/file/service which has SUID bit set and owned by root. 2) Checking to find if the file has is vulnerable to hijacking 3) Replacing the library with a malicious one 4) profit Finding a SUID file to exploit is simple. See below: Now we have our list of vulnerable SUID binaries, time to pick one to exploit. For demo purposes i'm choosing the last one. Now we need to check whether the file is actually vulnerable. Luckily we can do this with strace. Strace is a linux util which helps with tracing system calls. For us, we can find open calls to files which are missing or replaceable. See below: We can see the SUID binary is vulnerable as it to open a library(./libcalc.so). However it is possible for us to overwrite this library as its located in a writable folder. Next we create our malware (which just executes /bin/sh). Next, compile your malicious code and replace the innocent library with your malicious one. Make sure to name your malicious library exactly the same as the innocent one we replace. Run the SUID binary and hopefully it will load your code and you'll get a root shell Linux ExploitsCheck which the of binaries with SUID is vulnerable to exploits. Try to compare against a exploit database such as exploit-db. Once you've found one, give it a go. Below i'm exploiting a vulnerable exim service with a well known exploit. Code below. Root Shell :) A simple and easy kernel exploit is the famous dirtyc0w exploit[CVE-2016-5195]. I wont go into the intricacies with the code. Running the exploit shows this: Root Shell :)
4) CronJobs 4.1) CronJobs - File Permissions 4.2) CronJobs - Path Environment Variables 4.3) CronJobs - Wildcards CronJob - File permissions The involves looking for instances in which a cronjob touches a writable root file we can overwrite. Taking a look at /etc/cronjob/ we can see which files have a cron schedule. Notice how overwrite.sh has root permissions. We can then inject malicious code into overwrite.sh which will get executed with root permissions. Check you can overwrite it: Overwrite the file with malicious code (reverse shell) of yours. Mine is shown below: Set up a listener and wait for the cronjob to run the file which we've just placed malicious code into. Root access achieved below Cronjob - path environment variables Here we are going to hijack the PATH variable of the overwrite.sh. Look at the image below and notice how the overwrite.sh file does not have an exact path. This means we could hijack it: Create a file called overwrite.sh in the home directory. Place malicious code into our overwrite.sh. Mine is a simple reverse shell from earlier Create the listener with Netcat and wait for root shell. CRONJOBS - WIldcards We can also abuse wildcards to try and get root. Lets look at the file /usr/local/bin/compress.sh which also has root privileges Notice how it uses a tar command with a wildcard? this is something we can exploit. If we can create a file with the same names as arguments which are passed to the tar command we can get it to execute malicious code. Create two files using the following command: Have a listener set up to receive the connection. Once the cronjob runs, it will run compress.sh which will run the tar command, which executes our malicious shell.sh with root privileges.
2) Shell Escape Sequences 3) Sudo Environment Variable Hijacking Shell Escape Sequences / Gtfobins / living off the land whatever you want to call it, this involves using native binaries and their functions to achieve root privileges. First step is finding out which binaries run as root: Another example using apache2 to read /etc/shadow |