You are here

NRPE 2.15 Vulnerability

4 posts / 0 new
Last post
smarsh
smarsh's picture
NRPE 2.15 Vulnerability

Recently, news emerged about a 'vulnerability' in Nagios's NRPE 'agent' - http://1337day.com/exploit/22156

Essentially, you can use it to write files or items to /tmp (or any 'write all' directly ('777')) as below:

nagios@nagios-server:/usr/local/nagios/libexec# /usr/local/nagios/libexec/check_nrpe  -H myServer -c check_users -a "`echo -e "\x0a touch /tmp/vulntest "` #" 4 root@nagios-server:/usr/local/nagios/libexec#

Then if you look on your 'monitored server', you'll see:

root@myServer:/proc# cd /tmp/ root@myServer:/tmp# ls -la total 24 drwxrwxrwt 4 root root 4096 Apr 20 20:24 . drwxr-xr-x 22 root root 4096 Apr 18 10:30 .. -rw-r--r-- 1 nagios nagios 0 Apr 20 20:25 vulntest root@myServer:/tmp#

This isnt best - as, has been seen, some pretty bad people can use this to put all kinds of bitcoin mining rubbish on there, amongst other things. Now, this only works because /tmp is writable to everyone (even on my test server, see below):

root@server:/# ls -la | grep tmp drwxrwxrwt 4 root root 4096 Apr 20 20:24 tmp root@server:/#

So - answer number 1 - secure it! Now, if your savvy and use a config management tool like Puppet, Chef, Ansible etc then you can do this en-masse. For me, ive only got the one test server, so i just edited /etc/fstab:

/dev/sda7 /tmp ext3 nosuid,noexec,nodev,rw 0 0

This stops executables running from /tmp, neither any suid programs (more information here): http://www.techrepublic.com/blog/linux-and-open-source/secure-temporary-files-in-linux/171/#.

Next step - answer number 2 - secure your boxes with a firewall. NRPE agents should ONLY be accessible from the Nagios monitoring server. The simplest way is to use iptables on the box:

iptables -I INPUT 2 -s 192.168.200.201 -p tcp --dport 5666 -j ACCEPT

And reject NRPE from any other server. This means, only your Nagios server can access the box via 5666 - so, unless your monitoring server gets compromised - you should be in good shape.

So - /tmp isnt writable, and no-one can run check_nrpe against the box except your monitoring server.

Finally - look at SELinux if your using RHEL/Centos and the likes, and also look at this guide here: http://nagios.sourceforge.net/docs/3_0/security.html

At the end of the day, your network is only as secure as you make it - therefore i'd recommend a review of who can access your internal networks, HOW they got access (Firewalls, NAT, etc) and a review of your IPS/IDS if you are experiencing this issue.

Also - this may be of interest in the future - check_by_ssh - http://www.techrepublic.com/blog/linux-and-open-source/remotely-monitor-servers-with-the-nagios-check-by-ssh-plugin/.

We are currently looking at a patch for this issue in the coming days, so stay tuned to Twitter/Opsview forums for more on this issue.

Sam Marsh

Product Manager

Opsview

jesus@blinkbox.com
jesus@blinkbox.com's picture
Re: NRPE 2.15 Vulnerability

Has this been sent over a mailing list for security advisories? If so, where is this mailing list?

Thanks.

nferguson
nferguson's picture
Re: NRPE 2.15 Vulnerability
Opsview is pleased to announce the release of Opsview 4.5.1 which includes a patch to resolve this vulnerability. This new release is available immediately from our package repositories for all of our supported platforms.   In addition to this, Opsview Agent packages for these supported platforms have been released, enabling you to update your monitored devices. You must upgrade systems running the agent to ensure they are protected against this vulnerability, as well as the Opsview infrastructure itself.    Agents are available from our package repositories as well as on our website.   Also, to help protect our customers, we have released updated agent packages for the following platforms on our website:
  • Solaris 10 i386 32-bit
  • Solaris 10 i386 64-bit
  • Solaris 10 SPARC 64
Please note that the Windows Agent is not affected.   In addition to upgrading your systems, we would still strongly recommend taking the following steps:
  • Using the 'allowed_hosts' directive in your client nrpe.cfg configuration files to prevent access from any hosts other than your Opsview monitoring infrastructure
  • Firewalling the agent port (tcp/5666) to further restrict access to trusted hosts
  • Using the 'Runaway processes' check with Opsview to identify any processes consuming an unusual amount of CPU time
  • Investigating any suspicious alerts or activity, particularly on devices which are internet facing 
 
onetruth
onetruth's picture
Re: NRPE 2.15 Vulnerability

Hi, 

Any ETA on when this will propogate to Opsview Core?   

Thanks, 

BC