How to Resolve Security, Vulnerability and Compliance concerns with Rapid Recovery (4040770)

A security vulnerability scan has detected concerns with Rapid Recovery and you want to know what can be done to resolve them.  For example, after running a Nessus security scan, the following results are displayed:

• Medium Cipher Strength Cipher Suite Supported
  • Scanner reports DES­CBC3­SHA is supported on port 8006
• SSL 64­bit Block Size Cipher Suites Supported (SWEET32)
  • Scanner reports DES­CBC3­SHA is supported on port 8006
• SSL Version 3 Protocol Detection and Vulnerability to POODLE Downgrade Attack
  • Scanner reports 1+ CBC ciphers supported on SSLv3 on port 8006RC4
• SSL RC4 Cipher Suites Supported
  • Scanner reports RC4­MD5 and RC4­SHA Cipher Support on port 8006
• SSL/TLS Diffie­Hellman Modulus
• TLS12_DHE_RSA_WITH_AES_256_GCM_SHA384 (1024 bits) on port 8006
• TLS12_DHE_RSA_WITH_AES_128_GCM_SHA256 (1024 bits) on port 8006

WORKAROUND:

Medium Cipher Strength Cipher Suite Supported

• SSL 64­bit Block Size Cipher Suites Supported (SWEET32)
• You can avoid the Sweet32 (disable support of Triple DES) by adding a registry key:
  • Open the registry and browse to "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Triple DES 168" 
  • Created a REG_DWORD called Enabled and set the value to 0

SSL Version 3 Protocol Detection and Vulnerability of POODLE Attack.

There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol.  However, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available.

The POODLE vulnerability is a weakness in version 3 of the SSL protocol that allows an attacker in a 'man ­in­ the ­middle' context to decipher the plain text content of an SSLv3 encrypted message. Servers and clients should take steps to disable SSL 3.0 support completely. Take care to evaluate your servers to protect any additional services that may rely on SSL/TCP encryption.

To manually edit the Windows registry to disable SSL 3.0, do the following:

• Open Registry Editor
• Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocol
• Under Protocols, add the SSL 3.0 key
• Within the SSL 3.0 key, add Client and Server keys
• In both of the Client and Server keys, create the following DWORD values
  • DisabledByDefault with a value of 1
  • Enabled with a value of 0
• Open the SSL 2.0 key, and set the Enabled value to 0 in both the Client and Server keys
• Reboot the server
• After reboot, test all applications on the Client and Server for compatibility before rolling out the change

Although the TLS protocols are enabled by default, they do not appear in the registry. After disabling SSL 2.0 and SSL 3.0, it is a good idea to ensure that at least one of the TLS protocols are enabled. To verify that the TLS protocol is enabled, do the following:

• Create keys for one or all of the TLS 1.0, TLS 1.1 and TLS 1.2 protocols
• Within each of the protocol keys, add Client and Server keys
• Within each of the Client and Server keys, create the following DWORD values:
  • DisabledByDefault with a value of 0
  • Enabled with a value of 1
• Reboot the server if required

SSL RC4 Cipher Suites Supported

In light of recent research into practical attacks on biases in the RC4 stream cipher, Microsoft is recommending that customers enable TLS 1.2 in their services and take steps to retire and deprecate RC4 as used in their TLS implementations. Microsoft recommends TLS 1.2 with AES­GCM as a more secure alternative which will provide similar performance. Microsoft recommends that customers upgrade to TLS 1.2 and utilize AES­GCM. On modern hardware AES­GCM has similar performance characteristics and is a much more secure alternative to RC4.

Clients and servers that do not want to use RC4 regardless of the other party’s supported ciphers can disable RC4 cipher suites completely by setting the following registry keys. In this manner, any server or client that is talking to a client or server that must use RC4 can prevent a connection from occurring. Clients that deploy this setting will be unable to connect to sites that require RC4, and servers that deploy this setting will be unable to service clients that must use RC4.

You can avoid the problem by running the following commands from an elevated command prompt:

• REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" /v "Enabled" /t REG_DWORD /d 0 /f
• REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v "Enabled" /t REG_DWORD /d 0 /f
• REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v "Enabled" /t REG_DWORD /d 0 /f

Each command will add the "Enabled" dword registry value and set it to disabled (value data set to 1 is 'On').  If you currently do not have the registry keys for RC4 128, RC4, or RC4 56, the above commands will automatically add these registry keys and corresponding dwords automatically.

SSL/TLS Diffie­Hellman Modulus <= 1024 Bits (Logjam)

An information disclosure vulnerability exists in Secure Channel (Schannel) when it allows the use of a weak Diffie­Hellman ephemeral (DHE) key length <= 1024 Bits in an encrypted TLS session.  Allowing <= 1024 Bits DHE keys makes DHE key exchanges weak and vulnerable to various attacks. You can avoid the problem by running:

• Open Registry Editor
• Access key exchange algorithm settings by navigating to the following registry location:
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms
• Select the Diffie­Hellman sub key (if it does not exist, then create it)
• Set the Enabled DWORD registry value to 0 (if it does not exist, then create it)
• Exit Registry Editor