Vulnerabilities > CVE-2018-8735 - OS Command Injection vulnerability in Nagios XI

047910
CVSS 8.8 - HIGH
Attack vector
NETWORK
Attack complexity
LOW
Privileges required
LOW
Confidentiality impact
HIGH
Integrity impact
HIGH
Availability impact
HIGH
network
low complexity
nagios
CWE-78
exploit available
metasploit

Summary

Remote command execution (RCE) vulnerability in Nagios XI 5.2.x through 5.4.x before 5.4.13 allows an attacker to execute arbitrary commands on the target system, aka OS command injection.

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Command Line Execution through SQL Injection
    An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host.
  • Command Delimiters
    An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or a blacklist input validation, as opposed to whitelist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or blacklist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
  • Exploiting Multiple Input Interpretation Layers
    An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
  • Argument Injection
    An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.
  • OS Command Injection
    In this type of an attack, an adversary injects operating system commands into existing application functions. An application that uses untrusted input to build command strings is vulnerable. An adversary can leverage OS command injection in an application to elevate privileges, execute arbitrary commands and compromise the underlying operating system.

Exploit-Db

  • descriptionNagios 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...
    fileexploits/linux/remote/44969.rb
    idEDB-ID:44969
    last seen2018-07-03
    modified2018-07-02
    platformlinux
    port80
    published2018-07-02
    reporterExploit-DB
    sourcehttps://www.exploit-db.com/download/44969/
    titleNagios XI 5.2.6-5.4.12 - Chained Remote Code Execution (Metasploit)
    typeremote
  • descriptionNagios 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
    fileexploits/php/webapps/44560.py
    idEDB-ID:44560
    last seen2018-05-24
    modified2018-04-30
    platformphp
    port
    published2018-04-30
    reporterExploit-DB
    sourcehttps://www.exploit-db.com/download/44560/
    titleNagios XI 5.2.6 < 5.2.9 / 5.3 / 5.4 - Chained Remote Root
    typewebapps

Metasploit

descriptionThis 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.
idMSF:EXPLOIT/LINUX/HTTP/NAGIOS_XI_CHAINED_RCE_2_ELECTRIC_BOOGALOO
last seen2020-06-13
modified2018-11-25
published2018-05-01
references
reporterRapid7
sourcehttps://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/linux/http/nagios_xi_chained_rce_2_electric_boogaloo.rb
titleNagios XI Chained Remote Code Execution

Packetstorm

Seebug

bulletinFamilyexploit
descriptionWe 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.
idSSV:97259
last seen2018-06-26
modified2018-05-02
published2018-05-02
reporterMy Seebug
sourcehttps://www.seebug.org/vuldb/ssvid-97259
titleMultiple Vulnerabilities in NagiosXI