The journey on the HTB monitored Linux box involved a unique path to gaining access as a low-level user. Initially, we obtained a user password through the SNMP service and attempted to use it on the Nagios CMS. Despite the account being disabled, we discovered that Nagios uses a REST API for authentication. Leveraging this knowledge, we authenticated using the REST API and obtained a token, granting access to the disabled account. From there, we acquired cookies and exploited an authenticated SQL injection vulnerability to obtain the API key of the Nagios administrator.
With the administrator API key, we created a new admin user and gained access to Nagios. This access allowed us to create a reverse shell. Finally, for privilege escalation, we exploited a binary that our user could execute as root without requiring the root password, effectively exploiting suid or sudo privileges to gain root access.
NMAP SCAN
┌──(liquidrage㉿kali)-[~/HTB]
└─$ nmap -p- -sC -sV -A -T4 monitored.htb
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-04-20 08:26 EDT
Stats: 0:02:19 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 22.93% done; ETC: 08:36 (0:07:47 remaining)
Warning: 10.10.11.248 giving up on port because retransmission cap hit (6).
Stats: 0:08:28 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 62.72% done; ETC: 08:39 (0:05:02 remaining)
Nmap scan report for monitored.htb (10.10.11.248)
Host is up (0.17s latency).
rDNS record for 10.10.11.248: nagios.monitored.htb
Not shown: 65276 closed tcp ports (conn-refused), 254 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0)
| ssh-hostkey:
| 3072 61:e2:e7:b4:1b:5d:46:dc:3b:2f:91:38:e6:6d:c5:ff (RSA)
| 256 29:73:c5:a5:8d:aa:3f:60:a9:4a:a3:e5:9f:67:5c:93 (ECDSA)
|_ 256 6d:7a:f9:eb:8e:45:c2:02:6a:d5:8d:4d:b3:a3:37:6f (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
|_http-server-header: Apache/2.4.56 (Debian)
|_ssl-date: TLS randomness does not represent time
| tls-alpn:
|_ http/1.1
| 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
|_http-title: Nagios XI
5667/tcp open tcpwrapped
Service Info: Host: 127.0.0.1; 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 924.47 secondsautorecon.py
To expedite the process of port scanning and enumeration, we ran autorecon.py, a tool designed to quickly identify open ports and gather information about the target system. This helped streamline our reconnaissance efforts and provided faster results.
Port 80: nagios.monitored.htb
We initiated fuzzing on the domain to uncover hidden folders and files, aiming to identify potential vulnerabilities or hidden resources within the web application. This systematic approach will help in further enumerating the target and potentially discovering critical entry points for exploitation.
Port 161
Utilizing the snmpbulkwalk tool, we monitored and queried the network for any sensitive information. This effort resulted in the retrieval of the password for the user “svc” in clear text, providing us with valuable credentials for further exploration and potential exploitation within the network.
Since attempting to use the obtained username and password for the domain did not succeed, likely due to the user being disabled, we need to explore alternative methods to gain access to the portal. One potential avenue is to investigate the Nagios CMS and its REST API for potential authentication methods or vulnerabilities that could provide access despite the disabled user account.
Upon discovering the forums, we identified a token-like mechanism that could potentially be leveraged later to gain access to the dashboard or other restricted areas. This token may serve as a key for authentication or authorization.
https://support.nagios.com/forum/viewtopic.php?t=58783
Examining another link within the forum, we found discussions that could potentially assist us in utilizing the token to gain access to the forum.
https://support.nagios.com/forum/viewtopic.php?t=60315
Manually navigating to the dashboard, we access the path “/nagiosxi/account” within the NagiosXI application
When searching for some exploit we found a blog that was talking about a bug SQL injection but that requires authentication, blog link below
https://outpost24.com/blog/nagios-xi-vulnerabilities/
To exploit the SQL injection bug discussed in the blog, we’ll need cookies. We can fetch these cookies from the browser’s developer tools (inspect element) and use them to authenticate our requests, facilitating the exploitation process.
We’ll confirm the existence of the SQL injection issue by sending a POST request using cURL and including the fetched cookies for authentication. This will allow us to verify the vulnerability and proceed with exploitation if confirmed.
We’ll replace the cURL command with SQLMap and adjust the options accordingly. By using “–method=POST” instead of “-XPOST,” we’ll instruct SQLMap to send a POST request. Running SQLMap with these parameters may take some time.
In the Nagios database, we’ll find the “xi_users” table, which contains hashed passwords, API keys, and other sensitive information. This table presents an attractive target for further exploitation and data extraction.
Exploring further, we attempted to crack the passwords without success. Instead, we shifted our focus to utilizing the API key of the administrator. A discussion post on the same forum revealed a method for creating users using the API key, providing us with an alternative approach to achieve our objectives.
https://support.nagios.com/forum/viewtopic.php?t=42923
After successfully creating a new user using the API key of the administrator, we received a confirmation message indicating the success of the operation. This action expands our access within the system and provides additional avenues for exploitation and privilege escalation.
Upon attempting an exploit that specifically targets admin users, it failed, indicating that the user we created was not an admin user. This prompted us to search for a solution, leading to the discovery of a Metasploit exploit that creates the necessary admin user for a chained attack. This exploit provides us with additional
After creating the user, we can log in using the newly created credentials. This access allows us to further explore the system, execute commands, and potentially escalate privileges to achieve our objectives.
Shell as Nagios
Here I did take a hint on the exploitation part, so it basically goes like this
The exploitation process involves the following steps:
- Access the Core Config Manager.
- Navigate to the “Commands” section in blue and create a new command, adding your reverse shell payload.
- After creating the command, scroll down and apply all configurations.
- Return to the Core Config Manager page and select “Services” from the “Configure” dropdown.
- Choose your command name and test it using the “Run Command” option.
- This will execute your payload, providing you with a shell on your listener.
core config manager option configure drop-down
select the “commands” from here to create new command
add reverse shell command from here after clicking on “Add New”
added command config looks like this, don’t forget to select command type “check_coimmand” as these check_coimmand are visible in services section only after saving the apply configuration on the same page where we clicked the add command.
once the command is created go to “services” in the blue button
select the command name you just created.
click “run command” below and run it
you will have a shell as a low-level user as expected.
Shell as Root
Certainly, let’s enumerate the privileges we have as the current user. We’ll explore various methods for privilege escalation, noting which ones require root passwords and which ones do not. This will help us identify the most viable avenues for further exploitation.
Upon examining the “sudo -l” privileges, we discovered that most of the commands require entering the password of the current user to execute them as root. This restricts our ability to escalate privileges using these commands unless we have access to the required passwords.
Running LinEnum or LinPEAS revealed that there are services that can be rewritten, indicating potential vulnerabilities that could be exploited for privilege escalation. It suggests the presence of privileges from the previous enumeration where we might be able to restart these services, leading to further exploitation opportunities.
After checking all the privileges, we identified a bash file that can be executed as root without requiring a password prompt
After passing flags one by one, we identified the final command that allows us to restart the service named “npcd.” This command can be executed as root without requiring a password
To create a reverse shell of the same type as the service file, we need to determine its file type first.
Using msfvenom, we created a Linux reverse shell payload of the same type as the service file
After creating the reverse shell payload, we uploaded it to the server. Then, we replaced the actual service binary with our reverse shell payload.
This action allows us to execute commands as root when the service is invoked, effectively granting us full control over the system.
After replacing the service binary with our reverse shell payload, we restarted the service. This action triggers the execution of our reverse shell payload, providing us with a root shell on the system
Successfully restarting the service triggered the execution of our reverse shell payload, granting us a root shell on the system via the Metasploit console
HOPE YOU LIKE THIS WALKTHROUGH
