Enforcing SSL 3.0 and removing weak encryption vulnerability over SSL ( IIS 6.0 and ISA )
Running a Custom Penetration test on IIS 6.0 server having SSL enabled may show vulnerability reports as a weak encryption on IIS . ISA server 2000 acts as proxy in front of the IIS server and also has certificate installed on it. The following is the error report generated by the Custom penetration test when we have already forced SSL 3.0 , however still have the weak encryption keys supported on the server , which may be used by attackers to exploit man in the middle like attacks on the server.
SSL Server Supports Weak Encryption Vulnerability port 443/tcp over SSL
QID: 38140
Category: General remote services
CVE ID: -
Vendor Reference: -
Bugtraq ID: -
Modified: 10/16/2008
Edited: No
THREAT:
The Secure Socket Layer (SSL) protocol allows for secure communication between a client and a server.
SSL encryption ciphers are classified based on encryption key length as follows:
HIGH - key length larger than 128 bits
MEDIUM - key length equal to 128 bits
LOW - key length smaller than 128 bits
Messages encrypted with LOW encryption ciphers are easy to decrypt. Commercial SSL servers should only support MEDIUM or HIGH strength ciphers to
guarantee transaction security.
IMPACT:
An attacker can exploit this vulnerability to decrypt secure communications without authorization.
Further the "require 128 bit Encryption " on IIS 6.0 dose not enforce strong SSL/TLS ciphers. It only ensures that 128 bit keys are used for encryption.The setting “Require 128-bit encryption” enables all 128-bit encryption algorithms, including RC2 and RC4. It also enables suites that use MD5 for integrity. Since all of them wont provide utmost security, we need to disable them separately.
Resolution
SSL/TLS supports a range of algorithms. For symmetric encryption, it can use AES, 3DES, RC2, or RC4. For message integrity, it can use MD5 or SHA. For asymmetric encryption, the algorithm is RSA.
A cipher suite is a combination of algorithms. RSA_AES_SHA is an example of a cipher suite. FIPS has approved specific cipher suites as strong. These use AES or 3DES for encryption, and SHA for integrity. FIPS does not consider other cipher suites strong.
Now why we want to enforce SSL3.0 when it is almost a completely different protocol as compared to SSL 2.0 ?
The reason being SSL2.0 as compared to SSL 3.0 is a much weaker protocol and prone to security hacks.
SSL Version 3.0 uses the BSAFE 3.0 implementation from RSA Data Security, Incorporated. BSAFE 3.0 includes a number of timing attack fixes and the SHA-1 hashing algorithm. The SHA-1 hashing algorithm is considered to be more secure than the MD5 hashing algorithm. SHA-1 allows SSL Version 3.0 to support additional cipher suites which use SHA-1 instead of MD5.
SSL Version 3.0 protocol reduces man-in-the-middle (MITM) type of attacks from occurring during SSL handshake processing. In SSL Version 2.0, it was possible, though unlikely, that a MITM attack could accomplish cipher specification weakening. Weakening the cipher could allow an unauthorized person to break the SSL session key.
A Possible scenario can be , someone intercepting the initial message in an SSL2.0 handshake can force the server and client to agree to the weakest mutually supported encryption standard. So if you are connecting to servers that support 40 bit export-weakened encryption, and transmitting sensitive info, you could have trouble
This is fixed by enforcing SSL3.0 from the registry and disabling older verions of SSL from here ,
HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols
refer KB 187498
Now coming to the second error as reported by the penetration testing , this occurs since although we have SSL3.0
enforced but due to the weak encryption schemes still configured in the registry we may reach a scenarion where in we fall back on the weakest mutually supported encryption standard as mentioned earlier.
SSL encryption ciphers are classified based on encryption key length as follows:
HIGH - key length larger than 128 bits
MEDIUM - key length equal to 128 bits
LOW - key length smaller than 128 bits
To get around this we need to make the changes in the registry to restrict certain algorithms and protocols in schannel.dll
To ensure that only high encryption keys are used , we need to make the following registry changes :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers]
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 64/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]
“Enabled”=dword:ffffffff
For detailed description refer KB http://support.microsoft.com/kb/245030
Note: If ISA server uses HTTPS and we want only the high encryption keys to be used we need to check
"Require 128 bit, encryption over HTTPS" in ISA (upto ISA Server 2006) , however this dose not enforce 128 bit encryption .
Refer KB : http://support.microsoft.com/kb/937293