Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability

Answered SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability

  • Thursday, June 14, 2012 6:33 PM
     
     
    Sign In to Vote
    0

    Our server failed the last PCI scan.   The description of the problem is below my questions.

    Windows Server 2008

    According to Qualys Security Labs one method to correct this to change the priority of the cipher suite, putting RC4 at the top of the list.

    Is this information correct?

    To change the order of the Cipher do I do this in group policy?

    I believe I have to disable SSL2 also. (I think I did that but I will have to reboot and retest to verify)

    Thanks

    Mitigating the BEAST attack on TLS

    https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

    This fixes the clients?

    MS12-006: Vulnerability in SSL/TLS could allow information disclosure: January 10, 2012

     

    Security Warning found on port/service "smtp (25/tcp)"

    Security Warning found on port/service "https (443/tcp)"

    Status
      Fail (This must be resolved for your device to be compliant).
     
        Plugin
       "SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability"

     
        Category
       "General "
     
     
        Priority
       "Medium Priority
     
        Synopsis
     
        It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services.
     
     
        Description
         A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system.
    TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.
    This script tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite, and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable.
    OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is initialized.
    Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHAN
    NEL\SendExtraRecord.
    Therefore, if multiple applications use the same SSL/TLS implementation, some may be vulnerable while others may not, depending on whether or not a countermeasure has been enabled.
    Note that this script detects the vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does not detect the BEAST attack where it exploits the vulnerability at HTTPS client-side (i.e., Internet browser). The detection at server-side does not necessarily mean your server is vulnerable to the BEAST attack because the attack exploits the vulnerability at client-side, and both SSL/TLS clients and servers can independently employ the split record countermeasure.

     

    ee also:
     
     http://www.openssl.org/~bodo/tls-cbc.txt
     
     
     http://vnhacker.blogspot.com/2011/09/beast.html
     
     http://technet.microsoft.com/en-us/security/bulletin/ms12-006
     
     http://support.microsoft.com/kb/2643584
     
     http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-
     
     
     
        Risk factor
        Medium / CVSS Base Score : 4.3 (CVSS2#AV:N/AC:M/Au:N/C:P/I:N/A:N) CVSS Temporal Score : 3.6 (CVSS2#E:F/RL:OF/RC:C) Public Exploit Available : true
     
     
     
     
     Plugin
    output
          Negotiated cipher suite: AES128-SHA|TLSv1|Kx=RSA|Au=RSA|Enc=AES(128)|Mac=SHA1
     
     
         CVE:
     
      CVE-2011-3389
     
     Addition Information
      
      
     
     
     
     
     
     
     
     
     
        Configure SSL/TLS servers to only use TLS 1.1 or TLS 1.2 if supported. Configure SSL/TLS servers to only support cipher suites that do not use block ciphers. Apply patches if available.
    Note that additional configuration may be required after the  installation of the MS12-006 security update in order to enable the split-record countermeasure.

     
         See also:
     
     http://support.microsoft.com/kb/2643584
     
     
     for
     
     details.

     

All Replies

  • Friday, June 15, 2012 6:31 AM
    Moderator
     
     
    Sign In to Vote
    0

    Hello,

     

    Thank you for your post.

     

    This is a quick note to let you know that we are performing research on this issue.

     

    Best Regards

    Elytis Cheng

    Elytis Cheng

    TechNet Community Support

     
  • Friday, June 15, 2012 6:38 PM
     
     
    Sign In to Vote
    0

    Hi,

    I have a same problem, and  change the register value SendExtraRecord at 1, and vulnerability is gone

    but the aplication that use sql server is no func,
    when change the register value in 2 or 0 the vulnerability
    reappears

     
  • Saturday, June 16, 2012 4:02 AM
     
     
    Sign In to Vote
    0

    MS12-006 implements a new behavior in SCHANNEL.DLL, causing it to send an extra record if SSL 3.0 or TLS 1.0 are specified and the cipher suite uses Cipher Block Chaining (CBC). The client must request this behavior. A recent IE update (MS11-099) ensures that Internet Explorer will request this behavior.

    The problem arises that not all SSL/TLS implementation support this additional record, so you may experience problems. Most commonly, you will find Internet Explorer 9.0 display an "Internet Explorer cannot display the webpage" error. Earlier version of IE may simply display a blank page.

    KB2643584<http://support.microsoft.com/kb/2643584> covers the workarounds:

    1. Client-Side: Force IE to use TLS 1.1 or TLS 1.2. Be careful with non-Windows servers with this solution. OpenSSL, for example, does not yet support TLS 1.1 or TLS 1.2 in the distribution build. Support has been added to the current development build, so vendors that leverage the OpenSSL library may start to include support. How do you detect if an application uses the OpenSSL library? In the application directory, look for the file ssleay32.dll. This is the OpenSSL library.

    2. Server-side: Disable SSL 3.0 and TLS 1.0 in the registry on the server.

    3. Modify the SendExtraRecord registry value to effectively disable the update. Please review the article for all the details and caveats about this workaround.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

     
  • Monday, June 18, 2012 1:46 PM
     
     
    Sign In to Vote
    0

    No, I don't think that is going to help me.

    I had already tried to fix the server using the fix posted at http://support.microsoft.com/kb/2643584

    MicrosoftFixit50774.msi 

    Message

    This Microsoft Fix does not apply to your operating system or application version.

    Please correct me if I'm wrong, but my understanding is Windows server 2008 (not R2) does not support TLS1.1 or TLS1.2. 

    Refering to MS12-006: 

    Changing the SendExtraRecord is not recomended. I'll give it a try to see what breaks.

    Note:

    After putting RC4 at the to of the list of ciphers our server passed the scan for the BEAST issuem, but it is still failing the PCI scan with this error message. (Qualys SSL Labs,   Grade A88 -  BEAST attack  Not vulnerable )

    Status
      Fail (This must be resolved for your device to be compliant).
     
        Plugin
       "SSL/TLS Protocol Initialization Vector Implementation Information Disclosure Vulnerability"

     
        Category
       "General "
     
     
        Priority
       "Medium Priority
     
        Synopsis
     
        It may be possible to obtain sensitive information from the remote host with SSL/TLS-enabled services.
     
     
        Description
         A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system.
    TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected.
    This script tries to establish an SSL/TLS remote connection using an affected SSL version and cipher suite, and then solicits return data. If returned application data is not fragmented with an empty or one-byte record, it is likely vulnerable.
    OpenSSL uses empty fragments as a countermeasure unless the 'SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS' option is specified when OpenSSL is initialized.
    Microsoft implemented one-byte fragments as a countermeasure, and the setting can be controlled via the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHAN
    NEL\SendExtraRecord.
    Therefore, if multiple applications use the same SSL/TLS implementation, some may be vulnerable while others may not, depending on whether or not a countermeasure has been enabled.
    Note that this script detects the vulnerability in the SSLv3/TLSv1 protocol implemented in the server. It does not detect the BEAST attack where it exploits the vulnerability at HTTPS client-side (i.e., Internet browser). The detection at server-side does not necessarily mean your server is vulnerable to the BEAST attack because the attack exploits the vulnerability at client-side, and both SSL/TLS clients and servers can independently employ the split record countermeasure.

    Thanks

     
  • Monday, June 18, 2012 6:06 PM
     
     
    Sign In to Vote
    0

    Just to muddy the water a little more...

    Comodo added this item to their list on 18 April 2012 and it failed at the next scan in May.. We tested with Qualyss and it failed on the beast attack vunerability.

    Using the tool from Nartac

    https://www.nartac.com/Products/IISCrypto/Default.aspx

    We rearranged the cypher order (make sure ALL the cyphers you want are checked, not just the one you want to move up the list, it removes all unchecked ones)

    Checked it again with Qualyss and it passed. Ran the Hacker Guardian scan and it passed. All was good...

    Just run the scan again with hacker guardian and it failed, but is still passing with Qualyss..

    Qui me amat, amet et canem meum


    • Edited by gchq_fox Monday, June 18, 2012 6:08 PM
    •  
     
  • Tuesday, June 19, 2012 10:14 PM
     
     Proposed
    Sign In to Vote
    0

    Yesterday I received this response from Comodo

    This vulnerability is causing a lot of problems.

    This afternoon I got a follow up. Originally this was reported as a false positive and rejected. I have resubmitted the report.. Watch this space

    Without writing a treatise on cryptographic flaws, the short answer to how we're handling this vulnerability is as follows:  You can report the fact that you've configured your server to prefer non-CBC cipher suites (as you have below as a compensating control via the 'Report as False Positive' links in the vulnerability report within the scanning interface and we'll evaluate the report and pass the server if it's satisfactory.

    Qui me amat, amet et canem meum

    • Proposed As Answer by Pogo2000 Wednesday, February 06, 2013 8:34 PM
    •  
     
  • Thursday, June 21, 2012 5:13 PM
     
     Answered
    Sign In to Vote
    1

    In short the answer seems to be...

    1. Remove SSL 2.0

    2. Arrange the cypher suite to prefer non-CBC cyphers

    Scan the server - you will get a fail on this.

    Submit a false positive report stating that

    1. SSL 2.0 has been disabled

    2. The cypher suite is arranged to prefer non-CBC cyphers

    The only way that the scan will pass is if all CBC cipher suites are disabled - but only very current IE and Opera browsers will be able to gain access, so they will accept a preference of RC4 as a compensating control for now.

    Qui me amat, amet et canem meum

    • Proposed As Answer by gchq_fox Thursday, June 21, 2012 5:14 PM
    • Marked As Answer by Mr See Friday, June 22, 2012 5:17 PM
    •  
     
  • Monday, July 23, 2012 11:37 AM
     
     
    Sign In to Vote
    0

    Submit a false positive report stating that

    1. SSL 2.0 has been disabled

    2. The cypher suite is arranged to prefer non-CBC cyphers


    Actually, it is NOT a false positive, because the attacker will not use the prefered cipher, but will force the server to use the vulnerable cipher instead, obviously... I think that disabling the m12-006 workaround and ONLY allow strong RC4 ciphers might solve the problem and will be compatible with almost evrything.

    To disable the m12-006 workaround on windows 2008, 2003, XP, Vista change the value of the following registry key to 2.

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendExtraRecord

    referece: http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx

     
  • Tuesday, March 19, 2013 10:23 AM
     
     
    Sign In to Vote
    0

    After investigating this issue, here are the steps in the shortest way to patch this vulnerability:
    download from this website IIS Crypto (depends on the .NET version installed on your server):
    https://www.nartac.com/Products/IISCrypto/Default.aspx

    the configuration must be similiar to the following photo:
    (all CBC ciphers must be removed)



    right after that:
    Start, run, regedit
    go to:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
    add DWORD named by:
    SendExtraRecord
    modify the value to 2

    restart the server.
    then check your cipher strength with the this online tool:
    https://www.ssllabs.com/ssltest/index.html

    you should get pretty much the same results:


    then run the PCI check again, this time your server should be compliant.

     
    • Edited by SolyMCP Thursday, March 28, 2013 1:53 PM
    •