what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Nagios NRPE Weak Cryptography Implementation

Nagios NRPE Weak Cryptography Implementation
Posted Feb 14, 2014
Authored by Aaron Zauner

This advisory discusses a weak cryptography implementation in NRPE, the remote monitoring agent distributed with Nagios.

tags | advisory, remote
SHA-256 | 9513ca804b2266816b1f59df17644a5e411eb0d568e52e7f93c445b9e778b63c

Nagios NRPE Weak Cryptography Implementation

Change Mirror Download
in CC to: grok full disclosure, bugtraq


Dear Nagios developers,

It's been a couple of years since I've had a look at NRPE, the remote
monitoring agent distributed with Nagios. Back then we've exclusively
used NRPE on unrouted dedicated monitoring vLANS.

I've recently been implementing monitoring with Icinga2 and been looking
up NRPE again. So I read through your source code and "documentation".
Here's my impression of your work.

- Cryptography -
The Encryption is done using a set encryption routine of
AES-256 Bit Encryption using SHA and Anon-DH. This encrypts
all traffic using the NRPE sockets from the client to the server.

This is simply not true.

src/nrpe.c L259 and src/client_check.c L168:

Setting the cipherstring to "ADH" allows for a multitude of possible
cipherstrings, depending on the OpenSSL configuration on the system and
the configuration shipped by the operating system distribution.
Furthermore, a quick peek into the OpenSSL wiki [0] or any textbook [1]
on the subject would have shown you that anonymous diffie hellman does
not provide any kind of authentication, and is thus, vulnerable to
(easily mounted) man-in-the-middle attacks.

src/nrpe.c L256 and src/client_check.c L145:
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

You're excluding SSLv2 and SSLv3, still leaving two broken protocols in
there: TLSv1.0 and TLSv1.1.

Since we are using Anon-DH this allows for an encrypted
SSL/TLS Connection without using pre-generated keys or
certificates. The key generation information used by the
program to dynaically create keys on daemon startup can be found
in the dh.h file in the nrpe src directory. This file was created
using the command:

openssl dhparam -C 512

512bit DH has been broken _in_the_real_world_ for a couple of years.
Current best practices recommend 3k+ [2]. Further more regenerating
diffie-hellman parameters with autotools may not really improve security.

As to the note on the developer not being sure if there would be
restrictions on the export: Yes. If you live in oppressive regimes there
are restrictions. i.e. for the US of A put a cryptography export notice

The aforementioned implementation of "cryptography" does not provide any
security other than security by obscurity. It's completely absurd and
system administrators without proper knowledge might actually deploy
this, without any warning on the security implications caused by a
fisher-price-my-first-crypto implementation. The first lesson in any
course on cryptography is always “do not implement yourself!”.

- Code quality -
As with the Nagios core, the overall code quality is just horrendous.
I've not had time to check thoroughly but from just scrolling though I
see a wide variety of format string vulnerabilities and bad coding

- Bashing doesn't help, after all it's FOSS, right? -
I've patched some parts of the code to explicitly exclude anything else
than TLSv1.2 and use a sane default cipher string loaded from a
configuration file. But there's still much work to do to enable
something with low overhead like ECDHE-ECDSA - because, yes, in this
case, for good security you'll need certificate handling and proper
implemented PKI. I'm not sure on how to proceed, I see the following
three options:

.) Do nothing and ignore security completely
.) Completely remove the mentioned SSL code parts and only point to stunnel
.) Implement proper PKI with current cryptography and update the project
accordingly (I’d help with that - but I’m not sure if thats even reasonable)

Aaron Zauner

[0] - http://wiki.openssl.org/index.php/Diffie_Hellman
[1] - https://www.schneier.com/book-ce.html
[1] - https://www.cl.cam.ac.uk/~rja14/book.html
[2] - http://www.keylength.com

Login or Register to add favorites

File Archive:

December 2023

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

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By