Zipping

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.114.241         
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-27 17:27 +08
Nmap scan report for 10.129.114.241
Host is up (0.17s latency).
Not shown: 64643 closed tcp ports (conn-refused), 890 filtered tcp ports (no-response)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Did a detailed scan as well:

$ nmap -p 80 -sC -sV --min-rate 4000 10.129.114.241
Starting Nmap 7.93 ( https://nmap.org ) at 2023-08-27 17:28 +08
Nmap scan report for 10.129.114.241
Host is up (0.17s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.54 ((Ubuntu))
|_http-title: Zipping | Watch store
|_http-server-header: Apache/2.4.54 (Ubuntu)

We don't need to add a domain to visit this site. I still added zipping.htb as standard HTB practice.

Web Enumeration -> Zip File LFI

The website was a watch store:

There is a shop feature located on the site, which was rather uninteresting except for the URL itself:

The page parameter was a really obvious LFI. The page is based in PHP, so I assumed that this was loading products.php. If we can figure out how to upload a shell on the machine like rev.php, it would potentially have to be triggered using this. All theory here, I have no source code yet.

The 'Work with Us' part was rather interesting:

This is quite specific in terms of requirements, and while there is technically a CVE out there for this (CVE-2023-38831), I think it's a bit too new for this box which just came out.

Since we are allowed to specify whatever file we want, we could potentially create symlinks to exploit an LFI:

I created a symlink called test.pdf that pointed to /etc/passwd, since we need to have a PDF file within the zip. Then I created a zip file with the symlink:

This would generate a file for us:

It should be noted that the hash in the URL is just the MD5 hash of the test.zip file.

However, visiting it shows an empty page. When the requests are viewed through Burp however, it shows that it worked!

SQL Injection Fail

Using this, we can read whatever file we want. The first thing I want to read is the upload.php file located at /var/www/html/upload.php:

The next thing to read is the code for the shop.

There's an LFI above with an auto .php extension includer. The include function is also used, which would execute PHP code if it exists. This opens up the door to RCE exploits via a PHP file.

The above mentions a functions.php, which contains some more interesting stuff:

This password does not work for ssh however. Reading home.php also had a bit of interesting stuff:

The above does not have any input validation for the id parameter, which is user-controlled.

When we attempt SQL Injection via ' character within the shop and render it in Burp, we see this:

This confirms that SQL Injection works. This, combined with the LFI trigger through includes, gives us a clear exploit path. However, I wanted to enumerate where the id parameter was being processed. Running a quick gobuster scan shows that product.php exists:

We can then use our PDF LFI to read this:

The regex there looks quite hard to bypass, and combined with the fact that the box name is Zipper, it's obvious that this isn't the intended method.

Null Byte Bypass -> RCE

SQL Injection failed, so it's back to the Zip file method. This is the code that checks whether or not there's a valid file in the zip:

The only check present is the pathinfo function, of which it can be bypassed.

From PayloadAllTheThings

To exploit this, we need to somehow append a null byte to the contents of the zip file, since we cannot just include it in the name of the file. I took a PHP reverse shell and zipped it to find that the file name is included in the strings of a the zip file.

Perhaps we could directly put the null byte within the zip file. Using hexeditor, I was able to edit it to this:

This would include the null byte needed to bypass the pathinfo function. When uploaded, this is what we see:

We can then visit that site and get a shell (without the .pdf at the end):

Privilege Escalation

Sudo Privileges -> Stock Binary

When checking sudo privileges, this is what I see:

There's a custom binary that we can run as root. Running it requires a password:

I transferred the binary to my machine and ran ltrace on it:

After using the correct password, we have some options:

When we view these options in ltrace, we can see that it attempts to open a .csv file:

When running on the machine itself, this is what we get:

Shared Library Exploit -> Root

The ltrace output from earlier shows this:

There's a libcounter file being loaded, which is likely a Shared Object file (.so). Since we have control over one file, we can easily create some basic C code that will trigger upon loading the library to give us a root shell.

Here's the C code I used based on the resource above:

Since we are already running this using sudo, no need to use setuid or setgid. Afterwards, compile it using this and download it to the /home/rektsu/.config file:

Then, we can run stock to get a root shell:

Rooted!

Last updated