HTB Writeup: Monitored
Hello and welcome to another writeup for Hack The Box machine Monitored. This machine is rated medium and the user shell holds true to the rating. However, the root shell was pretty easy. I learnt a lot about authorisation tokens and API Keys so let’s go!
Enumeration⌗
As always, I start the enumeration process with an Nmap scan.
Nmap shows 4 open ports. Port 80 and 443 are web servers, 80 is used for HTTP and 443 is used for the secure version HTTPS. Port 22 is running SSH and port 389 is running LDAP. For further enumeration, I also ran a Nmap UDP scan. I also added the nagios.monitored.htb to my /etc/hosts file so my browser can redirect to this address.
This is where it gets interesting. UDP port 161 is running SNMP. We can get a lot of information about the host machine if SNMP is not configured properly. Let’s run snmpwalk on the host and also look at the web server. I navigated to https://nagios.monitored.htb and found a link to the nagiosxi sub-directory. nagiosxi redirects me to the login page.
I tried some default credentials but it doesn’t work. Let’s fuzz for directories and see if we can find something interesting.
I found lots of interesting sub-directories. I first looked at the terminal but it again requires authentication. I then looked at admin, db etc but I don’t have any username or password. Another interesting sub-directory is the api, if it is misconfigured I can leverage it to get more information. Let’s fuzz the api sub-directory to find endpoints.
Now, let’s look at api/v1.
I found the authenticate endpoint. When trying to access this endpoint, it gives me an error message that I can only use POST requests with this.
So, I need some kind of authentication to send as data in the POST request. Meanwhile, snmpwalk is running in the background and it’s giving me exactly what I need. As this machine is slow, I had to increase the retry and timeout count so snmpwalk can continue to fetch data.
I can see the password for user svc. Let’s send this as a POST request to api/v1/authenticate. This took me some time because I had to figure out the exact command for POST data. I tried sending it as a json data but it didn’t work. Finally, I tried username=username&password=password which worked!
So, this gives me an auth_token. Now what do I do with this? I also tried to access other api endpoints but I received the error “No API Key provided”. This means I have to get the API Key somehow.
I looked up vulnerabilities for Nagios XI and one of them gave me an answer. According to CVE-2023-40933, the upload_banner_message_settings function in Nagios XI is vulnerable to SQL Injection. So, let’s try that.
Nagios XI vulnerabilities resulting in privilege escalation (& more)
Initial Foothold⌗
This again was a lot tricky because I was trying to inject at the vulnerable id parameter. However, I was not using the auth_token. I wasted a lot of time here getting frustrated until finally I tried to use the token in the url and started getting some results.
Another time consuming fact, this machine was super slow. sqlmap was not getting any responses, so I increased the --level and --risk parameters.
I used the following resource to craft the token request.
And it worked! I dumped all tables from the nagios database and this gave me the xi_users table. Here, I find the API Key for nagiosadmin.
Wonderful! Now, let’s try to leverage the API Key and get into that web server. I found a curl command to add new users to Nagios XI.
add new users to Nagios XI web interface - Nagios Support Forum
I created a user with this but it didn’t give me admin level access. I went through Nagios documentation again and realised that I need to specify the auth_level for the user. I created another user and gave it the auth_level=admin.
Understanding Nagios XI User Rights
Now, I try to login to the webserver with my newly created username, password and I’m in!
Getting User Shell⌗
I looked around the web server and tried to exploit the NRDP vulnerability. But, this didn’t work. After hours of trial and error I realised a simpler way was staring right at me. The Commands page under Core Config Manager. I first created a new bash command which gave me a reverse shell.
Then, I navigated to the Services page > Add new > Choose the newly created bash command. Then click on Run Check Command. Remember to listen on the specified port on your host machine.
[Hacker Voice] I’m in. Get the user flag from /home/nagios/user.txt.
Privilege Escalation⌗
I transfered the linpeas script on Monitored from my host machine and executed it to get information about any misconfigurations. I also ran sudo -l which gave me much more interesting results.
I can run many scripts and manage services as root. Once again, I went down several rabbit holes looking at known CVEs but in vain. A major vulnerability belonged to the autodiscover_new.php but it never worked.
It did give me an idea though. One part of the PoC consisted of stopping and restarting a service with manage_services.sh. What if I can manipulate one of the services and restart it to give me a shell? As the CVE talked about the npcd service, I chose the same. I tried changing the $PATH variable to point towards the /tmp directory and created a malicious npcd file there. However, this did not work.
Then, I thought of an easier way. Let’s delete the legitimate npcd file and create a new one. First I removed the npcd file with rm /usr/local/nagios/bin/npcd. Then I created a malicious npcd file which just contained a bash script for reverse shell. (This machine was pretty unstable so I created the file on my host machine and transferred it to Monitored with netcat)
Now, start the netcat listener on host machine and restart the npcd service.
And, Monitored is pwned! Find the root flag under /root/root.txt. This was a very fun machine and I learnt a lot of things, especially about the Nagios XI service. Thank you for reading and I will see you in the next writeup.