Retired
LFI -> BOF -> RCE (Writeup used)
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.227.96
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-10 23:13 EDT
Nmap scan report for 10.129.227.96
Host is up (0.024s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open httpLFI -> activate_license Binary
When we visit port 80, there's an obvious LFI present:
I was a bit lazy, so I created a quick Python script to read the files:
I still ran a gobuster scan to enumerate any other pages:
beta.html contained a file upload that did nothing, but it revealed some information regarding an activate_license application present:
We can fuzz to find this binary somewhere. Create a quck file with PATH variables:
Then, use wfuzz to find the activate_license binary.
Seems that /usr/bin/activate_license is where it is at. We can download this and try to run it:
This confirms that this is a binary exploitation challenge. We can being with reverse engineering the binary in ghidra.
Anyways, we can continue with our enumeration of the webpages. We can use this LFI to read the source code of the pages. There was an activate_license.php file here too.
It seems that this thing takes the input from the file we uploaded and sends it to the activate_license file on port 1337. We can grab this file and run it on our own PHP server.
Our script would have to send input to this file in order for it to be sent to the binary.
Proc + Binary Enum
We can continue to enumerate the processes present on the server. First, I want to enumerate what PID is the activate_license binary using:
Then, we can find out what is being run:
We can then enumerate /proc/432/maps in order to see the libraries loaded in memory space.
Ghidra + Offset
First we can see that PIE is enabled on this binary:
NX is also enabled, so we probably need to do a Ret2Libc exploit after leaking the libc address. Within the activate_license function, there's a BOF vulnerability due to the hardcoded buffer length and lack of length validation. Furthermore, the first 4 characters read from input are the buffer length used:
So we can probably overwrite this with a huge number of bytes. I ran the binary on my own machine on port 5555, and it seems to take some input.
From reading ghidra, it appears that it does some SQL stuff with our input after getting it:
So from this, it seems that the binary uses both libc and libsqlite3 within this function. We can download both of them from the machine itself.
From reading a writeup, I learned that because we have access to the libc files directly, we can actually call mprotect. This function would basically make the stack executable, allowing us to inject shellcode instead of hopping all over the place with a Ret2Libc.
However, it should be noted that it is possible to run the exploit even without this. This is because we can just call system to execute our shell instead.
Now, we need to figure out how to cause a crash in the binary such that we can control the execution flow.
Afterwards, we can create a quick Python script to send the input:
When run, our gdb window shows that it crashes with a pattern of length 2000.
We have overflowed the stack, and we can check the offset:
So we have an offset of 520.
Exploitation
I didn't really know how to craft this exploit, so I'll be using the official guide's script and trying to understand it.
First, since we can read the read the proc maps area, we can find the base addresses of which libc and the binary are loaded:
Then, we can find the system function, ROP gadgets and a writeable section of memory using these base addresses:
Then once we have these, we can use this to find the offset and write a system command to the binary. The script used in the guide uses a basic bash shell and inserts it in:
Then, the ROP chaining occurs, where the command is written into the memory space 8 bytes at a time:
Afterwards, the whole ROP chain is written into a file and sent to the remote web server. This is done because the web server accepts file uploads and sends the file contents directly to the activate_license binary, which would trigger the shell.
If this script is run, it gives us a reverse shell that we can upgrade.
Privilege Escalation
Backup Symlink Exploit
The first few things we notice is that there's a few backup zip files in the directory we are in:
If we list the timers, we can see that there's a website_backup script being run somewhere:
I ran a grep to view files that had html.zip within them and found one:
Here's teh script contents:
This thing backs up the entire /var/www/html directory and zips it. This is exploitable because we can create a symlink to the entire /home/dev directory within the backup file.
Then we wait for the script to run again, and unzip the latest file:
We can see that it works, and now we can grab the user's private key and ssh in. We can then grab the user flag.
Emuemu
Within the user's directory, there's an emuemu folder:
The contents of reg_helper.c is rather interesting:
This file is executable by us, and it seems to use binfmt_misc or something. The Makefile would create the binary and within it, it runs setcap:
So this bianry has cap_dac_override capability. There are some exploits for binfmt_misc that would spawn a root shell if we can write to the /proc/sys/fs/binfmt_misc/register file, of which this binary can.
We have to edit the exploit a bit. First we can remove all the checks on the writeability of the above file:
Then, since reg_helper is the binary that is allowed to write to that file, we have to change the last few lines of the exploit to use that binary instead:
The /usr/lib/emuemu/reg_helper binary is used because it is owned by root. The one within our home directory is owned by us, so it won't work in bypassing restrictions. After downloading it and running it, we would get a root shell.
This machine was hard for me, and I used a writeup for initial access and emuemu exploitation.
Last updated