Nagios Support Forum

Posted: **Mon Oct 01, 2018 9:33 am**

I've been auditing our XI servers for filesystem-related security issues (using things like rpm -V -a) and I'm disturbed by a few findings.

First, I found the following to be set to group nagios and made group-writable:

Code: Select all

drwxrwxr-x. 4 root   nagios  4096 Aug 17  2017 /etc/openldap
drwxrwxr-x. 2 root   nagios  4096 Feb  8  2017 /etc/openldap/cacerts
drwxrwxr-x. 2 root   nagios  4096 Dec  6  2016 /etc/openldap/certs
-rw-rw-r--. 1 root   nagios   600 Aug 17  2017 /etc/openldap/ldap.conf

Why is XI (or components thereof) able to - or why does it need to - modify important base OS configurations like LDAP??

Next:

Code: Select all

-rw-rw-r--  1 root   nagios   323 Sep 24 16:38 /etc/xinetd.d/nrpe

If the nagios account is compromised, editing that file could allow a remote attack by having xinetd call a binary or script other than /usr/local/nagios/bin/nrpe

Finally, the most troublesome:

Code: Select all

-rwxrwxr-x. 1 root   nagios   394 Aug 17  2017 /etc/sysconfig/nagios

Since that is executed by root, if the nagios account is compromised that file could be edited to allow local privilege escalation to root.

I'm prepared to remove the group-write from all these files and deal with limited functionality in XI unless / until someone can help me understand why these files are set this way.

Thanks in advance!

Posted: **Mon Oct 01, 2018 11:21 am**

Info about the hosts where these ownership / group / mode issues have been seen:

CentOS release 6.10 and Red Hat Enterprise Linux Server release 6.10

From /usr/local/nagiosxi/var/xiversion:

Code: Select all

full=5.4.13
major=5
minor=4.13
releasedate=2018-03-13
release=5413

and

Code: Select all

full=5.5.4
major=5
minor=5.4
releasedate=2018-09-20
release=5504

For a good view of the files & directories in question, run the following:

Code: Select all

find /etc \( -user nagios -o -group nagios -o -user apache \) | sort | xargs ls -ald

Translation:
- Find everything in /etc that is user "nagios" or group "nagios" or user "apache"
- sort the output for readability
- run "ls -ald" on each item

(That gives a cleaner view IMHO than just using the "-ls" option of "find", because the display order of "find" by itself is related to the inode traversal and not necessarily going to be in any sane order.)

Posted: **Mon Oct 01, 2018 12:04 pm**

Unfortunately I found a few more.

All the following files are (or in my case were) writable by the group "nagios", but these files are allowed to run as root with NOPASSWD by being listed in /etc/sudoers

If files that are run as root via sudoers can be edited by the user that's allowed to run them, that's inherently a local privilege escalation exploit. Worse, since the "apache" user is in the group "nagios" that means that if Apache can be exploited to run arbitrary code then you're owned.

Here's the list of the files I found writable by group "nagios" (which includes users "nagios" and "apache"):

Code: Select all

-rwxrwx---. 1 root nagios 12022 Sep 24 16:58 /usr/local/nagiosxi/html/includes/components/profile/getprofile.sh
-rwxrwx---. 1 root nagios 7625 Sep 24 16:58 /usr/local/nagiosxi/scripts/backup_xi.sh
-rwxrwx---. 1 root nagios 1776 Sep 24 16:58 /usr/local/nagiosxi/scripts/change_timezone.sh
-rwxrwx---. 1 root nagios 2634 Sep 24 16:58 /usr/local/nagiosxi/scripts/manage_services.sh
-rwxrwx---. 1 root nagios 1688 Sep 24 16:58 /usr/local/nagiosxi/scripts/repair_databases.sh
-rwxrwx---. 1 root nagios 2920 Sep 24 16:58 /usr/local/nagiosxi/scripts/upgrade_to_latest.sh

This was on both XI 5.4.13 and 5.5.4.

Posted: **Mon Oct 01, 2018 4:27 pm**

Have you found these on new installs or are these upgrades? The permission on you machine are not matching the default permissions on my lab machines:

ldap - nagios needs to access these files for ldap/ad integration. https://assets.nagios.com/downloads/nag ... ios-XI.pdf

/etc/xinetd.d/nrpe & /etc/sysconfig/nagios these are not on a system by default and the group does not need write permissions. You can remove the write ability for the nagios group.

/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh & scripts in /usr/local/nagiosxi/scripts/ - permissions by default look like "-rwxr-xr-x 1 root nagios". You can remove teh write ability for the nagios group.

Posted: **Tue Oct 02, 2018 9:49 am**

cdienger wrote:Have you found these on new installs or are these upgrades? The permission on you machine are not matching the default permissions on my lab machines:

Hmm - that's a good point. All three of our XI machines (we have two prod and one dev) had the same / similar issues, and I believe all three originally had XI 5.2 or 5.3 installed but have been upgraded one or more times since original setup. (I joined this team after those servers had already been built, so I'm not sure when the issues first appeared.) Since all three had similar problems I thought it was from the installer / upgrader scripts but it could have been from the professional services engagement way back because I think the same person built all three.

If I perform a manual upgrade (from tarball download) on top of our now-fixed dev instance and the permissions issues reappear I'll report that to you.

cdienger wrote:ldap - nagios needs to access these files for ldap/ad integration. https://assets.nagios.com/downloads/nag ... ios-XI.pdf

Maybe I'm missing it, but that doc doesn't say anything about needing to access / change anything to do with the OS authentication config files in /etc/openldap
The only place that "/etc" appears in that doc is /etc/resolv.conf
If I understand it correct, when XI is using LDAP / AD for authentication that is completely independent of the OS. More to the point: an application running on a host should NOT be able to modify the underlying OS authentication mechanism(s)!

Can you please confirm that XI does NOT need to modify anything in /etc/openldap or if it does, why?

cdienger wrote:/etc/xinetd.d/nrpe & /etc/sysconfig/nagios these are not on a system by default and the group does not need write permissions. You can remove the write ability for the nagios group.

Done. As noted above, if I see them again after I run a manual upgrade again I'll report the details.

cdienger wrote:/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh & scripts in /usr/local/nagiosxi/scripts/ - permissions by default look like "-rwxr-xr-x 1 root nagios". You can remove teh write ability for the nagios group.

Done.

A suggestion: for enhanced security, add to the /usr/local/nagiosxi/scripts/reset_config_perms.sh script the fixing of the sensitive items in /etc/sudoers with something like this:

Code: Select all

for item in $( grep /usr/local/nagios /etc/sudoers | cut -d: -f2 | tr ' ' '\n' | sort | uniq | grep /usr/local/nagios ) ; do
	chown root:nagios $item
	chmod 0550 $item
done

I admit it's a bit clunky but that's necessary because of the wildcards for args in some of the sudoers entries (which isn't thrilling either) plus the use of /usr/bin/php with the autodiscover_new.php script passed as an arg.

Anyway, the result of that code snippet is proper, safe user/group/mode on all the sudoers-referenced scripts:

Code: Select all

-r-xr-x--- 1 root nagios 169713 Sep 24 17:06 /usr/local/nagiosxi/html/includes/components/autodiscovery/scripts/autodiscover_new.php
-r-xr-x--- 1 root nagios 12022 Sep 24 17:06 /usr/local/nagiosxi/html/includes/components/profile/getprofile.sh
-r-xr-x--- 1 root nagios 7625 Sep 24 17:06 /usr/local/nagiosxi/scripts/backup_xi.sh
-r-xr-x--- 1 root nagios 1776 Sep 24 17:06 /usr/local/nagiosxi/scripts/change_timezone.sh
-r-xr-x--- 1 root nagios 2634 Sep 24 17:06 /usr/local/nagiosxi/scripts/manage_services.sh
-r-xr-x--- 1 root nagios 3815 Sep 24 17:06 /usr/local/nagiosxi/scripts/manage_ssl_config.sh
-r-xr-x--- 1 root nagios 1688 Sep 24 17:06 /usr/local/nagiosxi/scripts/repair_databases.sh
-r-xr-x--- 1 root nagios 3604 Sep 24 17:06 /usr/local/nagiosxi/scripts/reset_config_perms.sh
-r-xr-x--- 1 root nagios 2920 Sep 24 17:06 /usr/local/nagiosxi/scripts/upgrade_to_latest.sh

Thanks cdienger!

Posted: **Tue Oct 02, 2018 11:23 am**

OK I've run the manual (tarball ./upgrade) upgrade again and none of the problem permissions came back. However I'm not sure if the entire upgrade process is running since it was already at 5.5.4 (release 5504).

In a perfect world I'd have time to try running the "upgrade" from a previous release tarball (in effect doing a downgrade) to see if the permissions issues show up from an older version - but needless to say I don't have time for that.

If you can answer my previous question about the LDAP config files, and let me know what you think of my suggestion to add to the reset_config_perms.sh script, then you can lock this thread.

At very least all the detail I previously added for this thread will hopefully be of use to others on the forum.

Thanks!

Posted: **Tue Oct 02, 2018 2:57 pm**

When you add/remove CA certificates through Admin > LDAP / AD Integration it needs read/write permissions for creation of the certs in /etc/openldap/certs and /etc/openldap/cacerts.

I've also requested that a feature be added to the reset_config_perms.sh:

Code: Select all

FR: XI - reset_config_perms.sh - Add option to fix sudoers items permissions

Posted: **Wed Oct 17, 2018 12:43 pm**

Sorry for the delay in getting back about this topic. Thanks for keeping it open / unlocked this long.

We have our last XI server that we're finally hoping to upgrade from 5.4.13 --> 5.5.5 this week. After that I'll check on the owner/group/mode of things and report back, then after that I expect you can lock the topic.

Thanks for bearing with me / us.

Posted: **Wed Oct 17, 2018 1:56 pm**

Sounds good, we'll keep an eye out for your update.

Nagios Support Forum

Security concerns with XI user/group/mode on files & dirs

Security concerns with XI user/group/mode on files & dirs

Re: Security concerns with XI user/group/mode on files & dir

Re: Security concerns with XI user/group/mode on files & dir

Re: Security concerns with XI user/group/mode on files & dir

Re: Security concerns with XI user/group/mode on files & dir

Re: Security concerns with XI user/group/mode on files & dir

Re: Security concerns with XI user/group/mode on files & dir

Re: Security concerns with XI user/group/mode on files & dir

Re: Security concerns with XI user/group/mode on files & dir