ZOMG REMOTE SHELL EXPLOIT!!!! … Or, Not

A new post to the Full Disclosure mailing list today detailed a remote code exploit vulnerability within all available versions of the Nagios Remote Plugin Executor (NRPE), and provided a PoC that included gaining a reverse shell on the target server. Note that this reported exploit relies on a separate (but similar) vulnerability report in CVE-2013-1362. In today’s post, Dawid Golunski properly identifies a weakness within the NRPE argument sanitation that could allow a client to execute arbitrary commands on the remote host within the context of the NRPE user. At first this seems like a pretty serious vulnerability, but further analysis shows that successful exploitation hinges on a series of bad practices not related to NRPE code itself.

A further look at Golunski’s research shows that the following criteria must be met in order to successfully exploit this vulnerability:

  1. The attacking server must be previously defined within the allowed_hosts directive, which specifies hosts that are allowed to execute NRPE commands on the remote machine. If a disallowed host initiates a NRPE command, the host will immediately shutdown the connection without further parsing the command arguments (note this ‘immediate’ shutdown is down at the application layer, as opposed to ending the TCP session via RST). By default, only 127.0.0.1 is specified in allowed_hosts, so Nagios machines must be manually defined. Thus, successful exploitation of this vulnerability implies exploitation of the Nagios server itself, which adds an added layer of complexity to this attack.
  2. Remote arguments must be enabled within the NRPE daemon configuration, in the form of setting dont_blame_nrpe to 1. By default, this is disabled- for security reasons. The default nrpe.conf file even specifies this:
  3. NRPE command definitions must be specifically defined to process arbitrary command arguments. This is a relatively common use case, but again, the default NRPE configuration file cautions against this:

Once these conditions are met, we were indeed able to successfully bypass the meta character sanitation. Meeting each of these conditions required us to make a deliberate change to our NRPE configuration and reload the daemon.

The combination of requiring dont_blame_nrpe=1 and specifying commands that use arbitrary parameter definitions places the onus of responsibility on the administrator, not the software architecture or implementation. Does a vulnerability exist within the NRPE package? Yes. Golunski’s research does indeed show this, but a rush to judgement over the security of NRPE is unwarranted. The architecture of the software clearly shows forethought and defense-in-depth as a key design feature. However, any vulnerability within a given software package is no excuse for a lack of planning and poor implementation. Additionally, the discovery of this vulnerability reinforces the necessity for observing and implementing key security principles as part of an organization’s monitoring architecture:

  1. Always limit access to ports serving sensitive information. There is no reason to have a service like NRPE publicly available to the Internet, and the presence of the allowed_hosts directive is not a replacement for limiting access to the NRPE daemon via an ACL. Additionally, even though NRPE traffic is SSL-encrypted, transmitting sensitive data like NRPE (or SNMP, etc) over the public Internet should be done using an encrypted tunnel.
  2. Review your execution context. Best practice here would be to create a separate user with extremely limited access under which to run the NRPE daemon. RPM and Deb packages automatically do this (creating a new nagios or nrpe user in no additional groups, and setting the shell to /sbin/nologin); manual builds should be implemented with this in mind. NEVER run daemons such as this as root.
  3. Check third party libraries. NRPE links against openssl libraries to perform in-app encryption. Just gonna leave that there.

Today’s post a good reminder for us to keep track of what we’re running, how we’re running it, who we’re running it as- and always maintain a critical attitude toward any public announcement.

Update – More than 6 weeks after this vulnerability was announced, it still has yet to be patched. Also props to CG for the pingback at Carnal0nage.

Leave a Reply

Your email address will not be published. Required fields are marked *