Nagios vulnerability CVE-2020-35269

[hbouma]

I am looking for some instructions on updating the Nagios XI apache configuration to resolve this vulnerability.

Running Nagios XI 5.8.1 on RHEL 7.9 64bit VMs.

[dchurch]

Hi!

That CVE is filed in a way where it's not clear how to reproduce the issue, so it's hard to gauge the impact of the vulnerability.

Some of our devs looked into reproducing it, and here's what they have to say:

The issue isn't with our CSRF protection, it's instead due to the Core CGIs using HTTP by default, so that someone sniffing the requests can see CSRF tokens in plaintext.

-- https://github.com/NagiosEnterprises/na ... issues/809

Mitigating it may be as simple as turning on SSL. We have a guide to setting up your Apache server to use SSL: https://support.nagios.com/kb/article/n ... s-595.html

For a free certificate, I'd personally recommend you check out Let's Encrypt.

[hbouma]

My IT Security team is requiring that we have more of a firm answer as this is rated at a High vulnerability (8.8). https://nvd.nist.gov/vuln/detail/CVE-2020-35269

We do have SSL turned on as directed at https://assets.nagios.com/downloads/nag ... s%20XI.pdf however, nothing in this document appears to be turning off non-SSL traffic.

I know on the github page for Nagios Core, they mentioned making some additional tweaks to the Apache server to force SSL for /nagios and /nagios/cgi-bin. What would the matching Nagios XI configurations be?

https://github.com/NagiosEnterprises/na ... -760331317

[dchurch]

however, nothing in this document appears to be turning off non-SSL traffic.

Yes it does. It's on page 7:

Add the following lines to the end of the file (press SHIFT + G):
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule nagiosxi/api/v1/(.*)$ /usr/local/nagiosxi/html/api/v1/index.php?request=$1 [QSA,NC,L]
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>

That last rewriterule forces traffic to use HTTPS.

For a more permanent solution, you'll want to enable HSTS on your server as well:

Code: Select all

Header always set Strict-Transport-Security "max-age=63072000"

Securing your SSL configuration

The document is not exhaustive, and it's hard to get SSL correct unless you know what you're doing. There are other things to do to secure your server such as enabling HSTS, enabling SSL stapling, turning off SSL session tickets, disabling insecure protocols such as SSLv3, and turning off insecure cipher suites -- none of which the document covers.

Instead, I'd use Mozilla's tool to generate an appropriate Apache configuration for the level of security you need, and use those values instead of those listed in the document. The document can help you plug them into your Apache configuration. Here's an example output from it:

Code: Select all

# generated 2021-02-16, Mozilla Guideline v5.6, Apache 2.4.41, OpenSSL 1.1.1d, intermediate configuration
# https://ssl-config.mozilla.org/#server=apache&version=2.4.41&config=intermediate&openssl=1.1.1d&guideline=5.6

# this configuration requires mod_ssl, mod_socache_shmcb, mod_rewrite, and mod_headers
<VirtualHost *:80>
    RewriteEngine On
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt >> /path/to/signed_cert_and_intermediate_certs_and_dhparams
    SSLCertificateFile      /path/to/signed_cert_and_intermediate_certs_and_dhparams
    SSLCertificateKeyFile   /path/to/private_key

    # enable HTTP/2, if available
    Protocols h2 http/1.1

    # HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

# intermediate configuration
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

A good utility to test how secure your SSL certificate, and show device compatibility, is here: https://www.ssllabs.com/ssltest/

[hbouma]

Is this a new addition to the document? It doesn't seem to have been there when we setup our servers in 2018.

I also found that we had to remove the http (80) firewall service leaving only the https (443) service as the lines provided still allowed communication to Apache, only giving a redirect response.

[dchurch]

Is this a new addition to the document? It doesn't seem to have been there when we setup our servers in 2018.

Indeed, our documents change as new practices come out, and the software changes.

I also found that we had to remove the http (80) firewall service leaving only the https (443) service as the lines provided still allowed communication to Apache, only giving a redirect response.

This isn't recommended. It will cause browser requests to fail if someone loads up the non-HTTPS site. If someone loads up the browser and simply types in the hostname, it'll return an error instead of redirecting them to HTTPS.

google.com's port 80 is open. It just redirects the traffic over HTTPS. Having port 80 open isn't a security risk in and of itself.