Enforcing SSL 3.0 and removing weak encryption vulnerability over SSL ( IIS 6.0 and ISA )

Posted: Dec 11, 2008  6 comments  

Average Rating

Share this Post

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.

require-128-bit-ssl

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

 

Comments

I have made the registry changes as required and rebooted the server.

If I then test it using a browser with only SSL 2.0 Enabled, I can still get to the web site (over HTTPS). Based on this test, the registry change had no effect.

Is this not a valid method of testing?

Is there a tool I can use to verify what level of SSL the server is requiring?

Thanks.

Mar 05 2009 by Anonymous

Yes, if you go to http://www.serversniff.net, you can use their free tool to check the web server:

http://www.serversniff.net/content.php?do=ssl

Mar 10 2009 by Anonymous

Very interesting artilce

Im not very familiar in cryptography but I received some questions about a customer, so Im trying to get up to speed...

My questions is, in IIS6, if  we install a Certificat that is Version3 (SHA-1, RSA1024,..), do we still need to perform Registry  changes ?

Thks

jc

Mar 11 2009 by Anonymous

This help me on the PCI test, Thanks.

Oct 01 2009 by sathai