NSClient OpenSSL vulnerability

[Phaethar]

Hey all,

Haven't seen anything really posted about this yet, so I figured I'd ask about it here.

We run Nagios in our environment, and have our Windows and Linux servers reporting to it. It's been working great for us.

A few weeks ago, our weekly internal Nessus scans started flagging our Windows servers as having an open security hole. The exact report detail is:

Code: Select all

Vulnerability found on port netsaint (5666/tcp) : 


    
    Synopsis :
    
    The remote host is affected by a vulnerability that could allow
    sensitive data to be decrypted.
    
    Description :
    
    The OpenSSL service on the remote host is vulnerable to a
    man-in-the-middle (MiTM) attack, based on its response to two
    consecutive 'ChangeCipherSpec' messages during the incorrect phase of
    an SSL/TLS handshake.
    
    This flaw could allow a MiTM attacker to decrypt or forge SSL messages
    by telling the service to begin encrypted communications before key
    material has been exchanged, which causes predictable keys to be used
    to secure future traffic.
    
    Note that Nessus has only tested for an SSL/TLS MiTM vulnerability
    (CVE-2014-0224). However, Nessus has inferred that the OpenSSL service
    on the remote host is also affected by six additional vulnerabilities
    that were disclosed in OpenSSL's June 5th, 2014 security advisory :
    
      - An error exists in the function 'ssl3_read_bytes'
        that could allow data to be injected into other
        sessions or allow denial of service attacks. Note
        this issue is only exploitable if
        'SSL_MODE_RELEASE_BUFFERS' is enabled. (CVE-2010-5298)
    
      - An error exists related to the implementation of the
        Elliptic Curve Digital Signature Algorithm (ECDSA) that
        could allow nonce disclosure via the 'FLUSH+RELOAD'
        cache side-channel attack. (CVE-2014-0076)
    
      - A buffer overflow error exists related to invalid DTLS
        fragment handling that could lead to execution of
        arbitrary code. Note this issue only affects OpenSSL
        when used as a DTLS client or server. (CVE-2014-0195)
    
      - An error exists in the function 'do_ssl3_write' that
        could allow a null pointer to be dereferenced leading
        to denial of service attacks. Note this issue is
        exploitable only if 'SSL_MODE_RELEASE_BUFFERS' is
        enabled. (CVE-2014-0198)
    
      - An error exists related to DTLS handshake handling that
        could lead to denial of service attacks. Note this
        issue only affects OpenSSL when used as a DTLS client.
        (CVE-2014-0221)
    
      - An unspecified error exists related to anonymous ECDH
        ciphersuites that could allow denial of service
        attacks. Note this issue only affects OpenSSL TLS
        clients. (CVE-2014-3470)
    
    OpenSSL did not release individual patches for these vulnerabilities,
    instead they were all patched under a single version release. Note
    that the service will remain vulnerable after patching until the
    service or host is restarted.
    
    See also :
    
    http://www.nessus.org/u?d5709faa
    https://www.imperialviolet.org/2014/06/05/earlyccs.html
    https://www.openssl.org/news/secadv_20140605.txt
    
    Solution :
    
    OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to
    0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should
    upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server)
    should upgrade to 1.0.1h.
    
    Risk factor :
    
    High / CVSS Base Score : 9.3
    (CVSS2#AV:N/AC:M/Au:N/C:C/I:C/A:C)
    CVSS Temporal Score : 8.1
    (CVSS2#E:ND/RL:OF/RC:C)
    Public Exploit Available : true
    
    Plugin output :
    
    The remote service accepted an SSL ChangeCipherSpec message at an incorrect
     point in the handshake 
    leading to weak keys being used, and then attempted to decrypt an SSL record
     using those weak keys.
    
    CVE : CVE-2010-5298, CVE-2014-0076, CVE-2014-0195, CVE-2014-0198,
     CVE-2014-0221, CVE-2014-0224, CVE-2014-3470
    BID : 66363, 66801, 67193, 67898, 67899, 67900, 67901
    Other references : OSVDB:104810, OSVDB:105763, OSVDB:106531, OSVDB:107729,
     OSVDB:107730, OSVDB:107731, OSVDB:107732, CERT:978508, IAVA:2014-A-0083

We are required to have clean internal Nessus scans every quarter, so I need to get this taken care of fairly quickly.

When these systems were installed, they all used the agent that the Nagios system linked to during the monitoring wizard setup process. That link still points to http://assets.nagios.com/downloads/nagi ... SClient++/. The agents on that page are all from 2012, and appear to run version 0.3.9. It also looks like version 0.4.1 is the current version on the nsclient.org site, but I've heard that it's not nearly as stable. I also don't see anything that mentions that it actually addresses the vulnerability listed from the Nessus scans (they were announced on June 5th).

I'm wondering what everyone else is doing to mitigate this. Does the 0.4.1 address this issue? Any advice would really be appreciated.

[sreinhardt]

0.3.9 is not compiled with a vulnerable version of openssl, in fact it may not even use openssl if I recall correctly. 4.0.1 or so, and before was effected by heartbleed but the most recent versions are not. You can read more from the developer here: https://www.nsclient.org/2014/05/20/heartbleed-status/ If nessus or anything else like core security, metasploit, etc, are reporting this as vulnerable it is absolutely a false positive and simply applying a possible vulnerability to all windows hosts with nsclient or nrpe ports open. (I personally checked recent versions of nsclient when heartbleed came out and can confirm newer versions are patched fine)

[Phaethar]

So, I checked with Nessus about their take on this. Their response was as follows:

This specific OpenSSL vulnerability is exploited by sending two ChangeCipherSpec messages during the SSL handshake process. Our plugin sends those two messages, and if the target responds accordingly, the target is marked as vulnerable.

If you have contacted the vendor and they confirmed their software is not vulnerable, then their software is still responding in the above way which is why this vulnerability is being flagged. That being said, as long as the vendor can verify they either don't use OpenSSL or their software is not vulnerable, you can mark this as a false positive and modify the severity for this specific vulnerability.

I'm a bit stuck now. On the one hand, it sounds like this is a false positive. On the other hand, the scanner says "Well, it's responding like it's vulnerable, so we have to treat it that way". I can't really lower the score for this vulnerability, as this scanner tests systems that do have public facing web sites, and I need to know if anything ever trips this rule. So, I need to get it fixed so the scan sees it as clean.

Is there a version of NSClient++ that scans clean right now? I know it's not vulnerable to Heartbleed, but what about the MitM (CVE-2014-0224) and other flaws announced in early June?

[jomann]

Since NSClient++ 0.3.9 has no been build since the change happened the version of OpenSSL it is running does not have the fixes for MitM that you are talking about. The newest version 0.4.2 may have the updated OpenSSL version with the fixes you are talking about in them.