Aracılığıyla paylaş

Taming the Beast (Browser Exploit Against SSL/TLS)

  • Makale

Two researchers recently discovered a known vulnerability that existed in CBC based ciphers, but was considered theoretically impractical, until then. This vulnerability exists in all CBC based ciphers used in SSL V3/TLS 1.0. The researchers Juliano Rizzo and Thai Duong demonstrated proof-of-concept code called BEAST (Browser Exploit Against SSL/TLS) at the Ekoparty security conference held in late September, 2011.

If you don’t remember, these 2 are the same guys who last year discovered the “Padding Oracle” crypto attack in ASP.NET. Smile

I will try to be as explanatory as possible. One of the researchers (Thai Duong) has published this on his blog here: https://vnhacker.blogspot.com/2011/09/beast.html. This blog contains a video link demonstrating the attack.

After this Microsoft released a Security Advisory article and a HOTFIX addressing the vulnerability on 26th September 2011.

https://technet.microsoft.com/en-us/security/advisory/2588513
https://support.microsoft.com/kb/2588513

INTRODUCTION

Now, before we proceed ahead, we need to understand few semantics of SSL in order to understand this vulnerability. As I aforementioned, this vulnerability exists in all CBC based ciphers used in SSL V3/TLS 1.0.

I also want to mention that I referred few things from internet, mostly from Wikipedia, and what I remember from my college days. I am glad I was one of the few that opted for Cryptography as one of the topics back in my engineering days. Smile

SSL Protocol: These are the following list of protocols which have been released till date:

  • SSL 1.0, 2.0 and 3.0
  • TLS 1.0 (or SSL 3.1, released in 1999)
  • TLS 1.1 (or SSL 3.2, released in 2006)
  • TLS 1.2 (or SSL 3.3, released in 2008)

NOTE: Windows Server 2008 R2 and Windows 7 are the only 2 OS which support TLS 1.1 and TLS 1.2 as of now. All the OS’s before this don’t support these 2 protocols.

Please refer the following blog post by me on support for SSL/TLS protocols on Windows.
https://blogs.msdn.com/b/kaushal/archive/2011/10/02/10218922.aspx

CIPHERS: Ciphers are cryptographic algorithms used for performing encryption/decryption. A “Plain text” is fed as input to CIPHERS to generate an encrypted text also known as “Cipher text”. There are 2 kinds of Ciphers generally used during SSL handshake:

  • Block Ciphers, like AES and DES
  • Stream Ciphers, like RC4

CBC (Cipher-block chaining) : It is a symmetric key algorithm, used for encryption/decryption. It is also referred as a block cipher. It firsts partitions the input message into separate cipher blocks of equal length. The nth or the last block sometimes may have to be padded to match the cipher’s block length. Now these blocks are encrypted one at a time.

In CBC, the plain text is XOR’d with the Initialization vector (IV) in the first block and with the cipher texts of the previous blocks before undergoing encryption. The IV is generally sued to make each message unique. Here is where the problem arises. I will explain this in the later section.

The below images below explain the encryption/decryption. The images from articles on Wikipedia helped me draw out these images in a colorful way, however they lacked continuity. So I used few dotted lines to indicate continuation of cipher operations.

The dotted lines below indicate continuity from 1st and second blocks to the nth block and vice-versa.

clip_image001

Encryption in CBC Mode

Courtesy: https://en.wikipedia.org/wiki/File:Cbc_encryption.png

clip_image003

Decryption in CBC Mode
Courtesy: https://en.wikipedia.org/wiki/File:Cbc_decryption.png  

SSL Handshake : SSL handshake is too big of a topic to be discussed here. Anyways we don’t need to discuss the complete handshake, What we need to know is, the 2 communicating entities, client and the server, decide on a common SSL/TLS protocol and cipher (Block Ciphers or Stream Ciphers) that they will be used to perform the encryption/decryption. The public key cryptography is used to decide these and during the latter part of the handshake, they decide on symmetric keys and perform encryption/decryption using the generated symmetric key and the ciphers decided earlier.

I invested some time and chalked out the image below. This explains the SSL handshake between client and server. This in reference to the Microsoft KB article 257951 on SSL handshake.

image

Chosen Plain-text recovery attack :

One of the methods used by the attackers, in order to gain access to the secret key being used by the communicating entities involved in a SSL handshake. In this method, the attacker choses arbitrary plain-texts and obtains corresponding cipher texts. The attacker makes predictive guesses depending upon the obtained cipher text, to form the original plain text.

This sounds unrealistic, as the attacker has to make predictions in order to crack it. However, modern day cryptography has become lot more easier as there are powerful hardware and software, capable of performing millions of calculations per second.

BEAST: Discussing the vulnerability

Remember the use of implicit IV’s while XOR’ing the plain text for successive blocks after the first block. This was a problem. The thing is that IV’s are supposed to be unique. Since the cipher text of the previous block is used as an IV in the current block mode of operation, the uniqueness is actually lost, and as I know that my previous cipher text is the IV for the current block.

  • This vulnerability was addressed in TLS 1.1 and TLS 1.2, by usage of “Explicit IV’s” for each block. Hence, TLS 1.1 and TLS 1.2 are not susceptible to this attack. I will once again emphasize on the fact that this vulnerability is seen only in CBC based Ciphers like AES, DES and Triple DES.
  • OPENSSL addressed this in TLS 1.0 by inserting TLS packets with zero-length payloads and random padding. However, this solution is disabled by default due to incompatibility with certain SSL stacks.
  • I’m not going to discuss how the attack works, please refer the blog article by one of the researchers: https://vnhacker.blogspot.com/2011/09/beast.html. They use the Chosen plain text recovery attack, a known attack which was considered to be theoretically impossible until they cracked it.
  • There are few catches here:
    • This attack is not easily implemented. It cannot be cracked by just observing the encrypted traffic.
    • The attacker should know in prior which secure site is being browsed.
    • The attacker has to implement a Man-in-the-Middle attack in order to do this. So the attacker has to be within the same network where this attack has to be implemented.
    • Multiple requests have to be sent across the wire before he could crack it i.e., he has to mix his traffic with the SSL traffic that the entities are communicating to each other without either of them realizing it.
    • This only lets the attacker to guess one plain text block at a time.

Workaround/Solutions

Server Side Fix:

  1. Prioritize the RC4 cipher suites rather than CB. RC4 is a stream cipher, since the attack is effective against CBC based Ciphers.

    • Go to Start, click on run and type “gpedit.msc”.

    • Go to Local Computer Policy --> Administrative Templates --> Network --> SSL Configuration Settings

    • Move “TLS_RSA_WITH_RC4_128_SHA” to the top of the priority list. The GUI suggests how to modify the settings.

      How to modify this setting:

      • Open a blank notepad document.
      • Copy and paste the list of available suites into it.
      • Arrange the suites in the correct order; remove any suites you don't want to use.
      • Place a comma at the end of every suite name except the last. Make sure there are NO embedded spaces.
      • Remove all the line breaks so that the cipher suite names are on a single, long line.
      • Copy the cipher-suite line to the clipboard, and then paste it into the edit box. The maximum length is 1023 characters.
  2. Enable TLS 1.1 and/or TLS 1.2 on servers running Windows 7 or Windows Server 2008 R2. Refer Microsoft Knowledge Base Article 2588513 to use the automated Microsoft Fix it solution to enable or disable this workaround for TLS 1.1.

Warning : Web clients that don’t support TLS 1.1 or 1.2 will perform the SSL negotiation with lower SSL/TLS versions, voiding the workaround. So better implement both the workarounds on IIS 7.5.

The above KB article adds the following registry key when run on server side:

image

NOTE: Unfortunately the above solution doesn’t apply to Windows Server 2003/Windows XP, the cipher suites prority is hard coded. On Windows Server 2003, they will probably have to disable the CBC based ciphers; however this might cause incompatibility with clients trying to connect to these servers.

Browser Side Fix:

Among browsers as of now only 2 of them include support for TLS 1.1 and TLS 1.2

  • IE 8/IE 9, running on Windows 7 or Windows Server 2008 R2.
  • Opera V10 onwards.

IE, like IIS relies on SCHANNEL for encryption or decryption, hence it supports only those protocols that are supported by the underlying OS. However, this is not true for non-Microsoft products; they have their own implementation and include support for these protocols specifically.

  1. Enable TLS 1.1 and/or 1.2 in Internet Explorer on systems running Windows 7 or Windows Server 2008 R2. To change the default protocol version to be used for HTTPS requests, perform the following steps:

    • On the Internet Explorer Tools menu, click Internet Options.
    • In the Internet Options dialog box, click the “Advanced” tab and scroll to the bottom.
    • In the Security category, select the Use TLS 1.1 and/or Use TLS 1.2 checkboxes.
    • Click OK.
    • Exit and restart Internet Explorer.

    Note: See Microsoft Knowledge Base Article 2588513 to use the automated Microsoft Fix it solution to enable or disable this workaround for TLS 1.1. Warning: Web servers that don’t support TLS 1.1 or 1.2 will perform the SSL negotiation with lower SSL/TLS versions, voiding the workaround.

  2. Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones. These may render many web-sites non-functional. So if you don’t want to block ActiveX Controls and Active Scripting for such sites, then add sites that you trust to the “Trusted Sites Zone”.

  3. Clear cookies and don’t navigate to HTTP and HTTPS websites at the same time. First, clear all cookies. Then, while browsing close all HTTP Web sites, including sites that mix HTTP and HTTPS, before and during use of HTTPS. Finally log out of all HTTPS Web sites that require authentication before resuming the HTTP traffic.

Recommended reading on this:

The irony is that major internet browsers (Chrome, Firefox and Safari) still don’t provide support for TLS 1.1 and TLS 1.2. They continue to use a security protocols which is a decade old. Its been 5 years since TLS 1.1 was released, yet this hasn’t been implemented by them.

Even OpenSSL doesn’t include support for TLS 1.1/TLS 1.2, so as a result, even Apache doesn’t support these protocols. Hopefully, they would realize the importance of security and adopt these new IETF standards.

Its time that we move on and adapt the new security protocols. I guess the time has arrived. Smile

Comments

  • Anonymous
    October 03, 2011
    CBC isn't a cipher, it's a mode (a method of using a cipher). Other modes include EBC, OFB, and CTR, and all of these can be applied to symmetic ciphers algorithms such as AES, DES and Triple DES.

  • Anonymous
    October 03, 2011
    David, I totally agree with you. CBC is a mode of operation and not a cipher. I have mostly referred in my blog as "This vulnerability exists in all CBC based ciphers", I noticed that I made a small typo while referring to the CBC diagrams. Thanks for pointing it out. :)

  • Anonymous
    November 20, 2012
    Was there a fix for this in a Windows update - presume it added the  prefered ordering?

  • Anonymous
    November 21, 2012
    @Brian It was fixed in MS12-006. You can read more about it here: blogs.msdn.com/.../fixing-the-beast.aspx

  • Anonymous
    December 14, 2012
    So how does one disable the CBC 'mode' in IIS6?

  • Anonymous
    June 02, 2013
    CBC isn't a cipher, it's a mode (a method of using a cipher). Other modes include EBC, OFB, and CTR, and all of these can be applied to symmetic ciphers algorithms such as AES, DES and Triple DES.

  • Anonymous
    June 03, 2013
    Thanks for the comment. I mentioned these as CBC based ciphers (I have never explicitly called this as CBC ciphers). As you know CBC is a mode of operation. For the readers, here is the Wikipedia article on the block mode ciphers: en.wikipedia.org/.../Block_cipher_mode_of_operation

  • Anonymous
    October 24, 2013
    Is this document stills applicable nowadays if i want to expose a IIS 7.5 on the internet ? Thanks for your help.

  • Anonymous
    November 13, 2013
    yes this is still applicable.

  • Anonymous
    December 21, 2013
    A question regarding the re-order process. Can I just remove the CBC ciphers and be done with it? Also, can you point me in the direction of a remediation for CBC and other weak ciphers on a Windows 2003 server, although 2003 is not susceptible, these are failures for PCI. Thanks Don

  • Anonymous
    January 01, 2014
    @ Don.. Yes you can remove the CBC ciphers. However re-ordering should just be fine. On 2003, you will have to disable the CBC based ciphers. This can be done via registry.

  • Anonymous
    April 13, 2014
    I have to totally remove the BEAST vulnerability so i have to remove all the entries of the BLOCK Ciphers suits from my SSL Configuration Settings as BEAST attack all the BLOCK ciphers. so i'm thinking of removing all the entries of the BLOCK Ciphers from my SSL Configuration Settings so i need to know that which are the cipher suits i need to remove and which i have to put in the SSL Configuration Settings other than your mentioned cipher suite "TLS_RSA_WITH_RC4_128_SHA". Thanks Shubham

  • Anonymous
    April 14, 2014
    @Shubham, it is not viable to remove all the Block mode ciphers from the list. There is a fix already issued to mitigate this issue. Please read my post here: blogs.msdn.com/.../fixing-the-beast.aspx

  • Anonymous
    April 14, 2014
    yeah you have written that we have to prioritize the RC4 based ciphers over CBC based ciphers so i need to know that which are the cipher suits i need to prioritized and put in the SSL Configuration Settings other than your mentioned cipher suite "TLS_RSA_WITH_RC4_128_SHA". could you please provide me the list of all the RC4 Cipher suits which i have to prioritized. Thanks Shubham

  • Anonymous
    April 15, 2014
    @Shubham This is what I wrote: 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. If you have installed this KB 2643584 then you need to do that.

  • Anonymous
    April 20, 2014
    My problem is that i have to remove the BEAST vulnerability from the server side so i have gone through the server side fix that you have mentioned in this blog. In that you have written "Prioritize the RC4 cipher suites rather than CB" in the first point that's why i was asking that which are the cipher suits i need to prioritized and put in the SSL Configuration Settings other than your mentioned cipher suite "TLS_RSA_WITH_RC4_128_SHA". or anything you can suggest me so that I can remove BEAST vulnerability from the server side. I'm using JBOSS Version: 5.0.1.GA  as my application Server. Thanks, Shubham

  • Anonymous
    April 21, 2014
    @Shubham This post was written before a fix was release by MS for BEAST vulnerability. Please refer this post for updated fix: blogs.msdn.com/.../fixing-the-beast.aspx

  • Anonymous
    July 09, 2014
    @Kaushal: Even if we follow remediation for beast then also our servers are vulnerable.... bcoz we are using RC4 as a fix..... As far I know RC4 is weak cipher.... is there any other remedy for it

  • Anonymous
    July 15, 2014
    please refer my previous response.