Vulnerabilities > CVE-2018-8736 - Unspecified vulnerability in Nagios XI
Attack vector
NETWORK Attack complexity
LOW Privileges required
SINGLE Confidentiality impact
COMPLETE Integrity impact
COMPLETE Availability impact
COMPLETE Summary
A privilege escalation vulnerability in Nagios XI 5.2.x through 5.4.x before 5.4.13 allows an attacker to leverage an RCE vulnerability escalating to root.
Vulnerable Configurations
Exploit-Db
description Nagios XI 5.2.6-5.4.12 - Chained Remote Code Execution (Metasploit). CVE-2018-8733,CVE-2018-8734,CVE-2018-8735,CVE-2018-8736. Remote exploit for Linux platfo... file exploits/linux/remote/44969.rb id EDB-ID:44969 last seen 2018-07-03 modified 2018-07-02 platform linux port 80 published 2018-07-02 reporter Exploit-DB source https://www.exploit-db.com/download/44969/ title Nagios XI 5.2.6-5.4.12 - Chained Remote Code Execution (Metasploit) type remote description Nagios XI 5.2.6 < 5.2.9 / 5.3 / 5.4 - Chained Remote Root. CVE-2018-8733,CVE-2018-8734,CVE-2018-8735,CVE-2018-8736. Webapps exploit for PHP platform file exploits/php/webapps/44560.py id EDB-ID:44560 last seen 2018-05-24 modified 2018-04-30 platform php port published 2018-04-30 reporter Exploit-DB source https://www.exploit-db.com/download/44560/ title Nagios XI 5.2.6 < 5.2.9 / 5.3 / 5.4 - Chained Remote Root type webapps
Metasploit
| description | This module exploits a few different vulnerabilities in Nagios XI 5.2.6-5.4.12 to gain remote root access. The steps are: 1\. Issue a POST request to /nagiosql/admin/settings.php which sets the database user to root. 2\. SQLi on /nagiosql/admin/helpedit.php allows us to enumerate API keys. 3\. The API keys are then used to add an administrative user. 4\. An authenticated session is established with the newly added user 5\. Command Injection on /nagiosxi/backend/index.php allows us to execute the payload with nopasswd sudo, giving us a root shell. 6\. Remove the added admin user and reset the database user. |
| id | MSF:EXPLOIT/LINUX/HTTP/NAGIOS_XI_CHAINED_RCE_2_ELECTRIC_BOOGALOO |
| last seen | 2020-06-13 |
| modified | 2018-11-25 |
| published | 2018-05-01 |
| references | |
| reporter | Rapid7 |
| source | https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/linux/http/nagios_xi_chained_rce_2_electric_boogaloo.rb |
| title | Nagios XI Chained Remote Code Execution |
Packetstorm
data source https://packetstormsecurity.com/files/download/148374/nagios_xi_chained_rce_2_electric_boogaloo.rb.txt id PACKETSTORM:148374 last seen 2018-06-30 published 2018-06-29 reporter Benny Husted source https://packetstormsecurity.com/files/148374/Nagios-XI-Chained-Remote-Code-Execution.html title Nagios XI Chained Remote Code Execution data source https://packetstormsecurity.com/files/download/147413/nagiosxi-remoteroot.txt id PACKETSTORM:147413 last seen 2018-05-07 published 2018-04-30 reporter Benny Husted source https://packetstormsecurity.com/files/147413/Nagios-XI-5.x-Chained-Remote-Root.html title Nagios XI 5.x Chained Remote Root
Seebug
| bulletinFamily | exploit |
| description | We found four vulnerabilities in NagiosXI, and chained them together to create a root RCE exploit, available here. Vulnerability chaining can increase the risk posed by individual vulns, it takes a village to raise a root RCE etc. etc. If you’re running NagiosXI <= 5.4.12, update. If you perform application vulnerability assessments, odds are at some point you’ve experienced some push-back on reported vulnerabilities in the form of arm-chair threat modeling along the lines of “Well, you could only do x with y, so it’s probably not a must-fix”. This statement is probably overly dismissive in most cases, in part because it neglects the possible impact of vulnerability chaining. Vulnerability chaining is the process of leveraging multiple vulnerabilities to achieve something beyond the scope of any individual vuln in the chain. A good examples of vulnerability chaining have been written about [here](https://foxglovesecurity.com/2016/01/16/hot-potato/). [Offensive Security’s AWAE](https://www.offensive-security.com/information-security-training/advanced-web-attack-and-exploitation/) is basically a course about vulnerability chaining. Another good example of vulnerability chaining (hopefully) is the NagiosXI root RCE exploit, that you’re about to read about. The Nagios XI exploit we’ve written leverages four vulnerabilities: * CVE-2018-8734 - sql injection * CVE-2018-8733 - authentication bypass * CVE-2018-8735 - command injection * CVE-2018-8736 - privilege escalation First, We’ll touch on each vulnerability is isolation, followed by an outline of how we chained these web application vulns together to achieve root RCE on the NagiosXI application server. If you’d like to follow along at home, you can grab a vulnerable version of NagiosXI here: https://assets.nagios.com/downloads/nagiosxi/5/ovf/nagiosxi-5.4.10-64.ova And the exploit in question here: https://www.exploit-db.com/exploits/44560/ ### CVE-2018-8734 - SQL injection (unauthenticated) An unauthenticated GET to `<nagiosxi_host>/nagiosql/admin/helpedit.php` gives a response with a 302 response code which redirects back to `/nagiosql/index.php`. In a browser, this might appear to be normal behavior for a webapp that’s redirecting unauthenticated sessions back to auth, but an intercepting web proxy allows us to inspect the response and determine that this response also contains a moderately broken form. A quick pass at this form gives us the following form submission POST to `helpedit.php`, which contains a vulnerable `selInfoKey1` parameter. ``` POST /nagiosql/admin/helpedit.php HTTP/1.1 Host: <nagiosxi_host> Content-Type: application/x-www-form-urlencoded selInfoKey1=SQLI_PAYLOAD&hidKey1=common&selInfoKey2=&hidKey2=free_variables_name&selInfoVersion=&hidVersion=&taContent=&modus=0 ``` Since we’re performing a whitebox test of this application, we can inspect the db logs and determine exactly where the injection occurs (For a in depth look at these kinds whitebox SQLi techniques, have a look at our [Unitrends 9 SQLi post](http://blog.redactedsec.net/exploits/2018/01/29/UEB9.html)). After some analysis of the database logs, we were able to confirm that `selInfoKey1` is vulnerable to SQLi. However we also discovered that the database user used to issue this injectable query (nagiosql) did not have sufficient permissions to perform many of the actions that we would be interested in as an attacker such as adding users, dumping password hashes, or enumerating sessions. [+] It’s Unauthenticated SQL injections! [-] The DB user doesn’t have privileges to do anything too interesting. ### CVE-2018-8733 - authentication bypass The CVE description for this vulnerability is perhaps misleading, since it’s not as though we’re able to bypass authentication globally with this vulnerability. Instead, we have a similar situation to the previously discussed CVE, whereby a GET request to `<nagiosxi_host>/nagiosql/admin/settings.php` returns a form with a 302 response code. A little meddling with the returned form gives us the following POST request to settings.php: ``` POST /nagiosql/admin/settings.php HTTP/1.1 Host: <nagiosxi_host> Content-Type: application/x-www-form-urlencoded txtRootPath=nagiosql%2F&txtBasePath=%2Fvar%2Fwww%2Fhtml%2Fnagiosql%2F&selProtocol=http&txtTempdir=%2Ftmp&selLanguage=en_GB&txtEncoding=utf-8&txtDBserver=localhost&txtDBport=3306&txtDBname=nagiosql&txtDBuser=nagiosql&txtDBpass=n%40gweb&txtLogoff=3600&txtLines=15&selSeldisable=1 ``` Nothing here is injectable, some of the settings don’t take, and others simply break nagiosql. What’s significant for us is the ability to set the database user account. If we could use this form to get the nagiosql db user more permissions, then maybe we could access parts of the database with our SQLi that were previously inaccessible. It turns out we can do just that; The ssh credentials to the appliance are set to `root:nagiosxi` by default, and these credentials are reused for the root database user. [+] We can change the DB user account! [+] We can maybe break the application configuration and cause a denial of service (DoS) situation! [-] Taken alone, this might seem to be a DoS, at worst. ### CVE-2018-8735 - command injection (authenticated) This command injection vulnerability was discovered mostly through source code analysis of application .php files. This one is useful for us, since it affects a wide swath of NagiosXI versions, and runs as user ‘nagiosxi’ (as opposed to ‘apache’). After some source code analysis, testing and hand waving, we get the following vulnerable POST request, which is vulnerable to authenticated command injection: ``` POST /nagiosxi/backend/index.php HTTP/1.1 Host: 10.20.1.179 Content-Type: application/x-www-form-urlencoded Cookie: nagiosxi=eb8pa9098grmgummu2pnofq3f5 Content-Length: 66 cmd=submitcommand&command=1111&command_data=$(your_command_here) ``` These POST requests get back responses that don’t immediately suggest command injection: ``` <?xml version="1.0" encoding="utf-8"?> <result> <code>0</code> <message>OK</message> <command_id>12</command_id> </result> ``` but white-box testing allows us to simply touch a file to /tmp, and then verify it’s existence out of band: ``` [root@nagiosxi_host tmp]# ls -l ... -rw-r--r-- 1 nagios nagios 0 Apr 13 02:21 testing ... ``` [+] We have command injection! [-] It’s authenticated, and requires admin level authorization. ### CVE-2018-8736 - local privilege escalation Finally, we went looking for some local privilege escalation, for reasons which may be becoming obvious at this point. Generally, a good first place to look when looking for local privesc on a linux environment is the sudoers file. Here’s an excerpt of the Nagios `/etc/sudoers` file: ``` ... NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/upgrade_to_latest.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/change_timezone.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_services.sh * NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/reset_config_perms.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/backup_xi.sh * ... ``` This is very interesting to us, especially if file permissions on those files allow write access to the nagiosxi user, which, in fact, they do: ``` [root@nagiosxi_host ]# ls -l /usr/local/nagiosxi/scripts/ ... -rwxr-xr-x 1 nagios nagios 1664 Dec 28 2016 change_timezone.sh -rwxr-xr-x 1 nagios nagios 2303 Dec 28 2016 manage_services.sh -rwxr-xr-x 1 nagios nagios 2681 Dec 28 2016 upgrade_to_latest.sh -rwxr-xr-x 1 nagios nagios 1010 Dec 28 2016 reset_config_perms.sh -rwxr-xr-x 1 nagios nagios 5673 Dec 28 2016 backup_xi.sh ... ``` So, we have a fairly straight forward instance of local privilege escalation. All that user nagiosxi needs to do to execute commands as root is place them into one of the scripts listed in the sudoers file, then invoke that script via password-less sudo. [+] It’s local privesc! User nagiosxi can easily escalate to root. [-] It’s local privesc and anyone running commands as nagiosxi is already an administrative user on this system. ### Putting it all together! Individually these vulnerabilities carry a lot of caveats. We can modify some application parameters unauthenticated, but it’s mostly good for breaking the application. We have SQLi but it can’t touch nagiosxi authentication data. We have command injection, but it requires an authenticated administrative session. We have local privesc, but you need command line access to the application server. It may seem counter intuitive then, that taken together, these vulnerabilities provide us with everything we need to put together an unauthenticated root remote command execution exploit! Taking a look at the finished exploit is probably the best way to get a feel for the details, but general process is outlined below: * STEP 0: Validate the proper nagios version - All of the listed vulnerabilities work on NagiosXI versions (5.2.6 <= x <= 5.4) The version string can be parsed out of `<nagiosxi_host>/nagiosxi/login.php`. * STEP 1: Change the database user to root - Using CVE-2018-8733, we can modify the nagiosql database user to be root, granting it sufficient authorization to access nagiosxi authentication data. * STEP 2: Leverage SQLi to access API keys - Now that the database user has sufficient privileges, we use CVE-2018-8734 to perform a SQL injection which returns all unique API keys in the system. The application seems to ship with an administrative API key already in the database, so this is a pretty reliable option. * STEP 3: Use an API key to add an administrative user - This one isn’t a vulnerability, just an API which can be used to add an administrative user, if you’ve got the proper API key. * STEP 4: Log in - Now that we have an administrative user in the system, we can log in. At this point, we’ve effectively bypassed authentication to the nagiosxi portion of the application. * STEP 5: Inject a command + elevate privileges - Here, we use CVE-2018-8735, our command injection vulnerability, to execute a command. We could establish a low priv reverse shell then elevate privileges once we’ve got a session on the application server, but our PoC does it all in one go, by placing the desired command into an ad hoc privesc script: ``` cp /usr/local/nagiosxi/scripts/reset_config_perms.sh /usr/local/nagiosxi/scripts/reset_config_perms.sh.bak && echo "{your_command_here}" > /usr/local/nagiosxi/scripts/reset_config_perms.sh && sudo /usr/local/nagiosxi/scripts/reset_config_perms.sh && mv /usr/local/nagiosxi/scripts/reset_config_perms.sh.bak /usr/local/nagiosxi/scripts/reset_config_perms.sh ``` This script leverages CVE-2018-8736 by placing the desired command into `/usr/local/nagiosxi/scripts/reset_config_perms.sh`, then invoking that script with a password-less sudo. The first and last lines backup and restore the original script, respectively. It’s a fairly long command, but it works consistently here. ### Conclusions We’re done! Following the steps above, we were able to convert 4 vulnerabilities with a lot of caveats and mixed severities into 1 root RCE with no caveats. What conclusions should we draw from this? I can think of a couple. * Vulnerabilities exist in the larger context of an application, not in isolation, and they should be treated as such. Failure to remediate seemingly low risk vulnerabilities can have consequences. * If you’re running NagiosXI version (5.2.6 <= x <= 5.4.12), you should update. |
| id | SSV:97259 |
| last seen | 2018-06-26 |
| modified | 2018-05-02 |
| published | 2018-05-02 |
| reporter | My Seebug |
| source | https://www.seebug.org/vuldb/ssvid-97259 |
| title | Multiple Vulnerabilities in NagiosXI |
References
- https://assets.nagios.com/downloads/nagiosxi/CHANGES-5.TXT
- https://blog.redactedsec.net/exploits/2018/04/26/nagios.html
- https://gist.github.com/caleBot/f0a93b5a98574393e0139104eacc2d0f
- https://www.exploit-db.com/exploits/44560/
- https://www.exploit-db.com/exploits/44969/
- https://www.nagios.com/downloads/nagios-xi/change-log/