Aracılığıyla paylaş

Fixing the BEAST

  • Makale

Earlier I had posted a blog explaining the BEAST vulnerability observed in TLS 1.0 & SSL 3.0. Here is the blog link: https://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx

Microsoft released MS12-006 patch last week to address BEAST. As usual, after this updateSmile, we were bombarded with cases.

After applying this update, supposedly many applications were in a broken state (mostly 3rd party). Everyone was blaming MS (as usual) for the problem. I don’t think most of them understood what this patch was all about. Reading further you would realize what broke the applications.

The security patch implemented a solution which was present in the RFC documentation and is as per the RFC 2246. Below is a snippet from the rfc:

6.2.1. Fragmentation The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType may be coalesced into a single TLSPlaintext record, or a single message may be fragmented across several records). struct { uint8 major, minor; } ProtocolVersion;

Dierks & Allen Standards Track [Page 16]

RFC 2246 The TLS Protocol Version 1.0 January 1999

enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext;

 

Now, I need not explain what the BEAST vulnerability is all about. You can refer my blog for this.

MS12-006 FIX for BEAST

  1. The security patch mainly addresses the vulnerability in protocols TLS 1.0 & SSL 3.0.
  2. The BEAST vulnerability is addressed by splitting (or fragmenting) the application data in to SSL records in the fashion 1/(n-1). This is explained in RFC2246 (section 6.2.1 Fragmentation).

This is where the problem arises, most of the applications haven’t implemented the RFC correctly. They assume that the application data will be packed into a single packet. Whenever the data is split into records, they don’t understand the response and leads to incompatibility between them.

Please refer this link for supported protocols on Windows OS: https://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

Addressing the compatibility issues

KB2643584 was introduced to address the compatibility issues caused by the MS12-006 security patch.

  1. It contains fixit links to enable TLS 1.1 protocol for IE (Client) and Windows based Servers.
    NOTE: This is applicable to Windows 7 and Windows Server 2008 R2 only.
  2. Disable the fragmentation/splitting of records which causes the in-compatibility. This is done via a editing the registry. Below are the steps to change the registry:

    • Click Start, click Run, type regedit in the Open box, and then click OK.

    • Locate and then click the following subkey in the registry:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    • On the Edit menu, point to New, and then click DWORD Value.

    • Type SendExtraRecord for the name of the DWORD, and then press ENTER.

    • Right-click SendExtraRecord, and then click Modify.

    • In the Value data box, type 2 to disable the split record in schannel, and then click OK.

    • Exit Registry Editor.

NOTE: The above registry key disables the patch applied on the server and the server is exposed to the vulnerability again. In this case you will have to disable all CBC based ciphers and prioritize RC4 based ciphers.

Splitting of records is the only real solution available for the following OS’s as they don’t support TLS 1.1 & TLS 1.2:

  • Windows XP
  • Windows Vista
  • Windows Server 2003
  • Windows Server 2008

On Vista and Windows Server 2008, one can prioritize the RC4 based ciphers over CBC based ciphers. This cannot be done in XP or 2003 though.

Till then Ciao! Smile

Comments

  • Anonymous
    January 23, 2012
    The KB article (support.microsoft.com/.../2643584) accompanying the MS12-006 advisory suggests that users of SCHANNEL (developers) should "send a Secure flag to schannel during session initialization". Is that "secure flag" documented anywhere? I've looked in all sorts of places, and haven't found it.

  • Anonymous
    February 10, 2012
    Alun, If you look at the RFC, it defines the data structure for the record:

struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext;

this is the type which is important: "opaque fragment[TLSPlaintext.length];" Basically the fix was to fragment data into smaller records.

  • Anonymous
    May 29, 2012
    So after applying MS12-006, does IIS 6.0 on Win Srvr 2003 automatically opt in by sending the Secure flag to SChannel? Or do you have to turn this on somehow?

  • Anonymous
    February 20, 2013
    Hi, On windows2008 R2 I can see that KB2585542 has been applied. But still BEAST status: vulnerable. What else need to be applied?  Isn't MicrosoftFixit50774.msi (support.microsoft.com/.../2643584) included in www.microsoft.com/.../details.aspx ? Thanks.

  • Anonymous
    February 27, 2013
    Mike can you let me know as to what lead to the status being vulnerable. The details of the report perhaps would help here. The KB 2585542 contains the fix for the Beast. Once you install that it should take care of the Beast vulnerability. However the Fixit link provided is used to turn the update on or off by setting the SendExtraRecord flag to the corresponding value. Check KB 2643584 for more details. Sorry for the delayed response.

  • Anonymous
    March 03, 2013
    Hello, Similarly (I'm a completely different Michael) we are seeing the Nessus Vulnerability scanner identify Windows 2008 servers(R2 SP1 and RTM SP2; both Standard and Enterprise) as vulnerable to this (MS12-006, CVE-2011-3389). There is also the odd 2003 server mixed in as well. I have tried contacting Tenable but they assure me this is not a false positive. These servers are not accessible from the Internet but I did find a downloadable tool available at www.bolet.org/TestSSLServer that found similar results. I suspect these tools are simply looking for TLS1.0 is enabled and CBC mode available which will always find an issue as that is, to my understanding, not how Microsoft addressed thee issue with their patch. Can you suggest any further tools, MS or third party, or testing so we can be sure the MS patch has taken affect as expected?

  • Anonymous
    March 03, 2013
    Ah, I see now. As per support.microsoft.com/.../2643584 further configuration is required to enforce the Secure flag once the update is installed, but Microsoft do not suggest you do this as it can break some application compatibility. Hence why modifying the ciphers available to not include any CBC based and prioritising RC4 based ciphers is the only graceful method to work around this issue.

  • Anonymous
    March 06, 2013
    Michael, There isn't tool provided by MS as of now which does such security analysis. However, I know you may have done this, but I want to know if they shared what data they analyzed to infer that the server is vulnerable. regards, Kaushal

  • Anonymous
    September 26, 2013
    community.qualys.com/.../updated-ssltls-deployment-best-practices-deprecate-rc4