Vulnerability Scans on FMOS Showing Weak Ciphers

Issue Details: 

When running a vulnerability scan against FMOS customers may have a returned warning about weak ciphers. An example of this may appear as "SSH Weak Key Exchange Algorithms Enabled", or "The following weak key exchange algorithms are enabled :diffie-hellman-group-exchange-sha1", or some variation of a similar message.

Weak Diffie-Hellman Keys and Man-in-The-Middle Attacks

A server accepting weak Diffie-Hellman public key values is a flaw that can aid a potential attacker in conducting a Man-in-The-Middle (MiTM) attack against a remote server as weak keys could allow for a fully predictable Diffie-Hellman secret. By itself, this flaw is not sufficient to set up a MiTM attack as it would require some SSL implementation flaws to affect one of the clients connecting to the remote host, such as is required for a "Logjam" attack.

"Logjam" (CVE-2015-4000) is a vulnerability in which TLS connections using the Diffie-Hellman key exchange protocol were found to be vulnerable to a Man-in-The-Middle attack in which the attacker would downgrade the TLS connection to a vulnerable 512-bit export-grade cryptography. This attack affects any server that supports DHE_EXPORT ciphers. This attack can be conducted by pre-computation of the 512-bit primes given in two popular sets of weak Diffie-Hellman parameters, namely Apache's "httpd" versions 2.1.5 to 2.4.7, and all versions of OpenSSL. There are 3 requirements for this attack to be successful, however.

1. The use of DHE_EXPORT cipher suites in the TLS protocol, or DHE keys with export-grade cipher strength: these keys are 512 bits in size and given enough computing power and time, they can be broken.

2. The use of pre-computed primes that are provided with certain widely used packages, such as certain versions of Apache httpd and sshd: this weakness allows an attacker to pre-compute such primes once and use them to decrypt any traffic that uses those primes to establish a TLS connection.

3. A flaw in the TLS protocol, which can lead to a downgrade from DHE to DHE_EXPORT.

The attacker tries to connect to the server using DHE_EXPORT cipher suites on behalf of the client and using this protocol flaw an active MITM attack can be conducted provided the server supports DHE_EXPORT cipher suites. This issue does not affect current versions of FireMon as the current version of OpenSSL does not include DHE_EXPORT cipher suites or any other export-grade cipher suite in its DEFAULT cipher list.

Since clients do not control the cipher suites controlled by the SSL/TLS server, the only defense is to reject small primes in the DHE handshake. Requiring larger primes can prevent the above-mentioned downgrade attacks. OpenSSL upstream addresses the remaining two issues, by increasing the minimum size of DH parameters which a client can accept to 768 bits. This way even if a MiTM attacker downgrades the connection, the client will reject if less than 768 bits are used, which is deemed to be easily breakable.

Issue Resolution: 

What can you do to further protect your FireMon server?

System-Wide Cryptographic Policies is a system component found in CentOS that provides a small set of policies which, when set by an administrator, configures a wide range of the core cryptographic subsystems, covering TLS, IPSec, SSH, DNSSec, and Kerberos protocols.

Depending on which system-wide policy is configured, applications in CentOS follow the selected policy and refuse to use protocols and algorithms that do not meet the policy. The policy applies to the default behavior of applications when running the system-provided configuration.

The 'FUTURE' System Wide Crypto Policy is a conservative security level that is believed to withstand any near-term future attacks. This level does not allow the use of SHA-1 in signature algorithms and only allows the TLS 1.2 and 1.3 protocols, as well as allowing the use of IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 3072 bits long.

Setting the 'System Crypto Policy' to 'FUTURE' from FireMon's Control Panel also sets the 'Use Custom Diffie–Hellman Parameters' field in the Control Panel to 'True'. The tooltip for the 'Use Custom Diffie-Hellman Parameters' option present in the Control Panel further explains this configuration option. "By default, applications using the Diffie-Hellman key exchange use built-in parameters. These parameters are known publicly, which may raise security concerns in certain situations. If this setting is set to 'True', custom parameters will be generated and used instead of the built-in parameters, wherever possible. Note that generating suitable strong parameters can take a very long time (sometimes more than 15 minutes, depending on hardware capabilities). When using the 'FUTURE' system crypto policy, this setting is forced to 'True'."  The 'FUTURE' policy generates larger, custom prime numbers, meaning an attacker would have to factor specific, large prime(s), increasing their workload.

With the 'FUTURE' system-wide cryptographic policy selected the following ciphers are the only ciphers the server will accept and they use a public key length of 4096:

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

ECDHE-ECDSA-AES256-GCM-SHA384

ECDHE-RSA-AES256-GCM-SHA384

ECDHE-ECDSA-CHACHA20-POLY1305

ECDHE-RSA-CHACHA20-POLY1305

ECDHE-ECDSA-AES256-CCM

DHE-RSA-AES256-GCM-SHA384

DHE-RSA-CHACHA20-POLY1305

DHE-RSA-AES256-CCM

PSK-AES256-GCM-SHA384

PSK-CHACHA20-POLY1305

PSK-AES256-CCM:

DHE-PSK-AES256-GCM-SHA384

DHE-PSK-CHACHA20-POLY1305

DHE-PSK-AES256-CCM

ECDHE-PSK-CHACHA20-POLY1305

Testing

Running openssl s_client -connect FIREMON_SERVER_IP:443 returns the following output:

Attempting to run the same command with a downgraded version of TLS, TLSv1.0, with openssl s_client -connect FIREMON_SERVER_IP:443 -tls1 returns the following ‘no protocols available’ output:

Additionally, ciphers can be tested one by one by appending the -cipher parameter and specifying a cipher. For example, testing a known weak Diffie-Hellman Export cipher with openssl s_client -connect 192.168.112.134:443 -cipher EXP-EDH-RSA-DES-CBC-SHA returns a "no cipher match" error.

It would seem that downgrade attacks are not possible, nor are attacks leveraging weak Diffie-Hellman Export ciphers as they are not made available for the TLS handshake.