In this post, I would like to share a walkthrough of the Monitored Machine from Hack the Box
This room will be considered a Medium machine on Hack the Box
- What will you gain from the Monitored machine?
- Information Gathering on Monitored Machine
- CVE-2023-40931 vulnerability
- Changing the password on the Nagios System
- Another way to obtain a reverse shell connection on a monitored machine
- Escalate to Root Privileges Access on the monitored machine
- Another method to get Root Access
What will you gain from the Monitored machine?
For the user flag, you will need to abuse the Nagios XI software, a renowned monitoring solution, which plays a pivotal role in the intricate process of employing a vulnerability chain to gain unauthorized access. This exploit methodology, which encompasses various tactics including SQL Injection techniques, is meticulously orchestrated to establish a firm foothold on the target system.
As for the root flag, you need to abuse the process of privilege escalation necessitates the manipulation of sudo permissions allocated to critical system scripts. This intricate manoeuvre involves exploiting vulnerabilities inherent in the sudo configuration, allowing unauthorized users to elevate their privileges and gain elevated access levels within the system architecture.
Information Gathering on Monitored Machine
Once we have started the VPN connection which requires a download from Hackthebox, we can start
┌─[darknite@parrot]─[~/Documents/htb/Monitored]
╰─ nmap -sC -sV -oA initial 10.10.11.248
# Nmap 7.93 scan initiated Sun Jan 14 21:40:02 2024 as: nmap -sC -sV -oA initial 10.10.11.248
Nmap scan report for 10.10.11.248
Host is up (0.27s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0)
| ssh-hostkey:
| 3072 61e2e7b41b5d46dc3b2f9138e66dc5ff (RSA)
| 256 2973c5a58daa3f60a94aa3e59f675c93 (ECDSA)
|_ 256 6d7af9eb8e45c2026ad58d4db3a3376f (ED25519)
80/tcp open http Apache httpd 2.4.56
|_http-server-header: Apache/2.4.56 (Debian)
|_http-title: Did not follow redirect to https://nagios.monitored.htb/
389/tcp open ldap OpenLDAP 2.2.X - 2.3.X
443/tcp open ssl/http Apache httpd 2.4.56 ((Debian))
|_ssl-date: TLS randomness does not represent time
|_http-server-header: Apache/2.4.56 (Debian)
| tls-alpn:
|_ http/1.1
|_http-title: Nagios XI
| ssl-cert: Subject: commonName=nagios.monitored.htb/organizationName=Monitored/stateOrProvinceName=Dorset/countryName=UK
| Not valid before: 2023-11-11T21:46:55
|_Not valid after: 2297-08-25T21:46:55
1059/tcp filtered nimreg
2522/tcp filtered windb
2909/tcp filtered funk-dialout
4126/tcp filtered ddrepl
7938/tcp filtered lgtomapper
16000/tcp filtered fmsas
16012/tcp filtered unknown
27715/tcp filtered unknown
49176/tcp filtered unknown
Service Info: Host: nagios.monitored.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Jan 14 21:41:15 2024 -- 1 IP address (1 host up) scanned in 73.66 secondsLet’s access the website interface
The website interface shows the Nagios XI where you can find more information here
However, there is nothing that we investigate via Burp Suite
When we try to click the button, it redirects us to a login page.
┌─[darknite@parrot]─[~/Documents/htb/monitored]
└──╼ $sudo nmap -sU -sV -sC 10.10.11.248
Starting Nmap 7.93 ( https://nmap.org ) at 2024-05-11 09:31 EDT
Host is up (0.33s latency).
Not shown: 993 closed udp ports (port-unreach)
Bug in snmp-win32-software: no string output.
PORT STATE SERVICE VERSION
68/udp open|filtered dhcpc
123/udp open ntp NTP v4 (unsynchronized)
| ntp-info:
|_
161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public)
| snmp-netstat:
| TCP 0.0.0.0:22 0.0.0.0:0
| TCP 0.0.0.0:389 0.0.0.0:0
| TCP 10.10.11.248:35464 10.10.14.73:1234
| TCP 10.10.11.248:56364 10.10.14.73:1339
| TCP 10.10.11.248:58216 10.10.14.73:1339
| TCP 127.0.0.1:25 0.0.0.0:0
| TCP 127.0.0.1:3306 0.0.0.0:0
| TCP 127.0.0.1:5432 0.0.0.0:0
| TCP 127.0.0.1:7878 0.0.0.0:0
| TCP 127.0.0.1:46498 127.0.1.1:80
| TCP 127.0.0.1:46502 127.0.1.1:80
| UDP 0.0.0.0:68 *:*
| UDP 0.0.0.0:123 *:*
| UDP 0.0.0.0:161 *:*
|_ UDP 0.0.0.0:162 *:*
| snmp-processes:
| 1:
| 2:
| 3:
| 4:
| 6:
| 8:
| 9:
| 10:
| 11:
| 12:
| 13:
| 15:
|_ 16:
| snmp-info:
| enterprise: net-snmp
| engineIDFormat: unknown
| engineIDData: 6f3fa7421af94c6500000000
| snmpEngineBoots: 36
|_ snmpEngineTime: 1d09h50m48s
| snmp-sysdescr: Linux monitored 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64
|_ System uptime: 1d09h50m48.68s (12184868 timeticks)
162/udp open snmp net-snmp; net-snmp SNMPv3 server
| snmp-info:
| enterprise: net-snmp
| engineIDFormat: unknown
| engineIDData: 5a44ab2146ff4c6500000000
| snmpEngineBoots: 27
|_ snmpEngineTime: 1d09h50m48s
18156/udp open|filtered unknown
31335/udp open|filtered Trinoo_Register
61685/udp open|filtered unknown
Service Info: Host: monitored
Host script results:
|_clock-skew: 11s
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1268.85 seconds
Let’s enumerate more further with ldapsearch
As a result, let’s look at the authenticate page as shown above
We should be able to use snmpwalk command to retrieve the command that we found earlier.
However, we need to enter the credentials for this pop-up box which we found earlier.
As a result, we managed to find some information about the nagios system
CVE-2023-40931 vulnerability
The vulnerability marks a significant milestone in our journey toward authenticated access to Nagios, prompting a meticulous investigation into vulnerabilities. Our efforts culminate in the discovery of an enlightening article on Outpost24, unveiling critical insights into the CVE-2023-40931 exploit – a “SQL Injection in Banner Acknowledgment Endpoint.” This vulnerability arises when users acknowledge a banner, triggering a POST request to /nagiosxi/admin/banner_message-ajaxhelper.php. The POST data contains the intended action and message ID: action=acknowledge banner message&id=3.
Of particular concern is the ID parameter, presumed to be trustworthy but susceptible to manipulation by the client without proper sanitization. This oversight exposes the system to SQL Injection attacks, enabling authenticated users with limited privileges to illicitly access sensitive data housed within tables like xi_session and xi_users. Such data includes emails, usernames, hashed passwords, API tokens, and backend tickets. Notably, the exploitation of this vulnerability does not hinge on the existence of a valid announcement banner ID, rendering it exploitable by threat actors at any given moment.
To abuse the vulnerability, we will be using SQLMap in our exploitation of a documented vulnerability (CVE) characterized by Post-Authentication SQL Injection. Our objective is to acquire the admin API key, stored within the ‘xi_users’ table, through the submission of a POST request to the ‘/nagiosxi/admin/banner_message-ajaxhelper.php’ endpoint via HTTP/1.1. For this purpose, we will utilize the username and password gleaned from the preceding step. This endeavour is integral to our overarching strategy of creating a new user endowed with administrative privileges.
Let’s do some research don’t he vulnerability which can be found here
We should retrieve some information on the server via Burpsuite
From the output, we managed to see a few potential injection points that we can abuse in the latter stage.
We should be using the SQLmap tool to enumerate the database within the monitored machine
After a while, I noticed there was a password hash that used bcrypt
Changing the password on the Nagios System
We should be able to add a new account using the above command.
Let’s access the NagiosXI dashboard by using the password change
Boom! We have successfully accessed the dashboard as shown above.
We can add a new command on the machine
However, we can also catch the reverse shell connection by creating the reverse shell connection on our attacker’s machine
Let’s start our python server
Therefore, let’s begin our listening on the attacker’s machine
The screenshot above shows the command that we can execute by clicking the “Run Check Command
Finally, we have managed to upload the file onto the victim’s machine
We can also insert the command that permits the reverse shell file
Let’s start the command as shown above
At last, we retrieved the reverse shell connection back to us.
Another way to obtain a reverse shell connection on a monitored machine
As usual, we can use a very common method in which we can put the command straightly on the command line
It looks like everything is already in place
As shown in the previous method, we have only to click the button of “Run Check Command”
We can read the user flag by typing the “cat user.txt” command
Escalate to Root Privileges Access on the monitored machine
As usual, we can find the binary that we can abuse in the latter stage. We managed to see a few sh files that we can use to obtain the Root Privileges Access
We should be able to modify the nagios.cfg which we can use to retrieve the SSH id_rsaa file using this method
Let’s execute the sh file as shown above which it will take a few second depending on machine
After a while, we managed to see a lot of files that we could analyze further.
At last, we managed to obtain the SSH id_rsa file and we should be able to copy-paste the key into our machine
Finally, we managed to access the machine via SSH service
Another method to get Root Access
If you look back on the result of the binary file, we should analyze one file such as manage_services.sh
We can use any of the services as shown in the screenshot above to abuse the permission
As a result, we managed to find some locations for npcd service on Nagios
There are a few files stored in the directory of Nagios configuration
Let’s create a reverse shell command on the victim’s machine
After a while, we should stop the npcd service on the victim’s machine
We should be starting back up on the service with the sh file
Sadly, we cannot retrieve the reverse shell connection on our attacker’s machine. As a result, we should rename the sh file into npcd file
Let’s give permission to the malicious file
Let’s start the npcd service and there is no error appears like before
Finally, we managed to successfully retrieve the reverse shell connection.
We can read the root flag by typing the “cat root.txt” command
No responses yet