Taming the Beast (Browser Exploit Against SSL/TLS)

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: http://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 26^th September 2011. </p>

</font>http://technet.microsoft.com/en-us/security/advisory/2588513
http://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.
http://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.

Encryption in CBC Mode
Courtesy: http://en.wikipedia.org/wiki/File:Cbc_encryption.png

Decryption in CBC Mode
Courtesy: http://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.

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: http://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:

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. </p>
  How to modify this setting:
  </font></div>
  - 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.
  </li> </ul> </li>
- 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.