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.
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.
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.
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.
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
Decryption in CBC Mode
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: 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.
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.
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.
- 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:
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.
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.
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”.
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:
- Microsoft Security Advisory (2588513): Vulnerability in SSL/TLS Could Allow Information Disclosure
- Is SSL broken? – More about Security Advisory:
- BEAST: https://vnhacker.blogspot.com/2011/09/beast.html
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.