Zipper

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.1.198                
Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-14 23:19 EDT
Nmap scan report for 10.129.1.198
Host is up (0.0099s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
10050/tcp open  zabbix-agent

Detailed scan:

$ nmap -p 22,80,10050 -sC -sV --min-rate 3000 10.129.1.198   
Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-14 23:21 EDT
Nmap scan report for 10.129.1.198
Host is up (0.0075s latency).

PORT      STATE SERVICE    VERSION
22/tcp    open  ssh        OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 5920a3a098f2a7141e08e09b8172990e (RSA)
|   256 aafe25f821247cfcb54b5f0524694c76 (ECDSA)
|_  256 892837e2b6ccd580381fb26a3ac3a184 (ED25519)
80/tcp    open  http       Apache httpd 2.4.29 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.29 (Ubuntu)
10050/tcp open  tcpwrapped
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Added zipper.htb to the /etc/hosts file as per standard HTB practice.

Web Enum -> Zabbix

Port 80 shows the default Apache2 page:

Running a gobuster scan reveals a /zabbix directory:

Zabbix is an open-source software used to monitor IT infrastructure via a dashboard, and it does have its fair share of vulnerabilities.

Visiting the directory returns a login page:

I didn't have any credentials, so I signed in as a guest user. When the dashboard is viewed, there's a version at the bottom:

Zabbix 3.0.21 is running, and it is likely outdated and has public exploits for it. Interestingly, when looking at the dashboard, I can see that there is a zapper user or machine:

This entity has a backup script. zapper sounds like a user of some sorts. If I attempt to login with zapper:zapper, I get a unique error message:

This means the the password is legitimately zapper, since it did not return an invalid password error. I took a look at the documentation for Zabbix , and found that there was an API:

Logo20 APIwww.zabbix.com

This was located at the api_jsonrpc.php file.

Zabbix API

Firstly, since GUI access was disabled, it is likely that I have to use the credentials I found to sign in.

This can be done using curl:

Using this token, I can perform some authenticated actions like listing hosts:

Now that I have privileges over this, I took a look at the users present:

This output can be extended using extend:

So there's an admin user as well. When reading the API documentation, I found out that it can be used to execute scripts:

LogoScriptwww.zabbix.com

Based on the above, I first took a look at the existing scripts:

There were a few parameters, including a type and execute_on variable. All of them were set to 1, which refers to the Zabbix server.

I wanted to see what happens if I created two reverse shell scripts, and have one execute on 0 and one on 1.

Based on the Script object documentation, only the command and name parameters are required. I used this python script to create the script on the machine:

This printed the scriptid parameter:

Now, I have to use the script.execute method to run it. This requires a scriptid and hostid to specify where to run it. I took another look at the hosts available:

It is likely 10106 is the machine itself, and 10105 is a container running Zabbix. Here's the final script I used to run and execute stuff:

Here's the outcome if execute_on is set to 1:

And here's the outcome of setting it to 0.

Seems that one shell spawns in the container, and one on the actual host. I continued using the shell from the actual host.

Privilege Escalation

Zapper Creds

This machine had 1 user zapper, with some interesting files:

Here's the backup.sh script:

There was a password here, which I could use to su to zapper.

SUID Binary RE -> Root

There was a zabbix-service SUID binary within the utils directory I saw earlier. I downloaded a copy via nc, and took a look at it within ghidra.

The binary uses the systemctl binary without the full PATH.

This is pretty easy to exploit:

Rooted! There were actually a LOT of different paths for the initial access. Based on 0xdf's writeup, the other paths include:

  • Zabbix admin's password being in the container

  • Public exploits

  • Creating a new administrator user

PreviousVesselNextInsane

Last updated