In this blog post we will be going over Monitored, Linux Machine from Hack the Box, let’s go!

1)As always we start by enumerating open ports on the machine:

nmap -sC -sV -A -T4 <target_ip>

2)From here we can conclude that port 80 is redirecting visitors to the https://nagios.monitored.htb which is port 443, so I added both monitored.htb & nagios.monitored.htb to the /etc/hosts file.

3)Nagios XI is running on the port 443, I tried default credentials for logging in but that didn’t work, so I decided to perform directory busting and I found another login form (basic authentication), however, default credentials didn’t work there either.

dirsearch -u https://nagios.monitored.htb

4)Now at this point I tried brute-forcing my way in under the /nagios login but I wasn’t successful, so I took a step back as something wasn’t clicking. I decided to conduct port scanning again to check if I missed any open port, but this time I did it for UDP ports as well (top 100 to speed things up).

sudo nmap -sU -T4 --top-ports 100 <target_ip>

4.1)Cool 2 ports are open that I missed with my TCP-only scan. Particularly interesting here is SNMP service running on port 161, as we can use snmpwalk to find some juicy information!

4.2)Let’s give it a try:

snmpwalk -v 1 <target_ip> -c public

Bingo, we found credentials for svc account when that user was running the command with sudo!

5)With these creds I was able to authenticate to /nagios

5.1)From here we can see some interesting information about processes and services running on the remote host, as well as Nagios version, but I didn’t find an exact exploit to match this version, and in addition to that, there were so many exploits out there (most of them related to SQL Injection on endpoints that I wasn’t able to reach on the current website). I was stuck here for a while trying to find the right exploit, but once again I decided to take a step back, to the https://nagios.monitored.htb

5.2)I tried to log in there with svc account, but interestingly I didn’t see the classic error message that I would see when the I try invalid combination of username and password, rather I see that account is deactivated, hmm…

5.3)Nagios XI API Documentation is not very well documented, and at this point I found this script: https://www.exploit-db.com/exploits/51925. I tried running it, but it didn’t worked out, so I start by analyzing the code of it and doing everything manually, so stick with me:

5.4)First we leverage the credentials that we have to send a POST request to the REST API to obtain auth_token

5.5)Very well, we have a auth_token, let’s use it and authenticate to the Nagios XI as now we don’t need username + password combination

(Supply the token that you get to https://nagios.monitored.htb/login.php?token=<token_here)

5.6)Cool, from here we are logged in as svc user!

5.7)At this point I tried looking for exploits that can help us as we are authenticated but the majority that I found either requested from us to have a valid API key, or admin access. I didn’t have either, as the svc’s API key didn’t work.

5.8)Another authenticated SQL Injection that I gave a try (as there are so many issues with Nagios XI xD) is at https://nagios.monitored.htb/nagiosxi/admin/banner_message-ajaxhelper.php and the vulnerable parameter is id. So I fired up sqlmap right away instead of exploiting it manually:

5.9)Cool, we got a hit! This is the final Dump where I got both administrator’s bcrypt Hash and API Key

6)So from here I fired up hashcat and tried to crack the admin’s hash but that didn’t work out. But at least I have admin’s API, so let’s leverage that!

6.1)Follow the script further

Let’s leverage Admin’s API to create another account with Admin Privileges by sending a POST Request to the /api/v1/system/user

Cool, we created a new account with admin privileges:

6.2)Okay, so finally we have an access to the platform as Administrator. From here I started enumerating UI but everything looked like a jumbled mess… I found it easier to read the scrip’s code than to navigate through the UI, so let’s continue the scrip’s way:

Okay so the purpose of this POST Request is to create a new command that we will abuse to get a reverse shell, instead of creating a service with full payload right away I decided to just curl my Python server to test if it works…

6.3)I took me a minute to understand how to execute the commands as I was only able to modify & enable / disable them from the UI. Then I realized that in order to do so I have to leverage services

So, navigate to the Services in the app and either create a new one or modify the existing one, I decided to modify an existing one. Then selected command that you’ve created in previous step:

(Notice how my command in this case is curl)

By executing this service I received a request on my Python server that I started locally:

python3 -m http.server

6.4)Okay, so I know that this is the way to obtain a reverse shell, I changed my command with payload for reverse shell and I followed the same steps as above:

But that didn’t work out… Okay, back to reading the script:

From here we can see that script uses nc with combination with bash

6.5)I created a new command, then used it with the service and I got a reverse shell as nagios user, thus user.txt as well. Great!

7)From here in order to conduct Privilege Escalation I started first by checking if I can run any command with sudo -l

sudo -l

And to my surprise there were a lot of commands that I can run as root without a password. But many of the binaries that were allowed weren’t present on the system. The one that was present and that stood out to me right away is:

sudo /usr/local/nagiosxi/scripts/manage_services.sh stop / start npcd

7.1)I decided to do a quick Google Search for Local Priviliege Escalation with Nagios and these command and I stumbled across this very well document Github Page:https://gist.github.com/sec-fortress/6d128a5e290e873be4c2ca27b6579eca. From here you can either transfer a script to remote host and execute with Bash, or you can do it manually as I did for a better understanding of what is happening:

7.2)And we got root.txt and another reverse shell but this time as root user. GG!

Lessons Learned

1)The most important thing that I learned while solving this machine is taking a step back if something is just not working, to check if we missed something that is important for further exploration. For example, here I missed an important UDP port that enabled us to conduct snmpwalk and to obtain important credentials. Then again I had to take another step back when I was trying to get initial foothold where I stopped trying to exploit website under /nagios and switched my focus to Nagios XI

2) The second important thing that I learned is not to stick only with one exploit if there are many vulnerabilities for specific version of the software. In addition to that if we are certain that the script should be working and we are on the right path but it doesn’t, try to do things manually by analyzing the code of the script. This way we will get better understanding and picture of what is actually happening and why that vulnerability exists, rather than just firing up the script. That helped me when I was certain that this script should worked out for me but it just didn’t: https://www.exploit-db.com/exploits/51925