First we will look at the BEAST attack and later we will explain its successor, the CRIME attack.

BEAST attack

The BEAST (browser exploit against SSL/TLS) was developed by researchers Thai Duong and Juliano Rizzo and can be carried out on TLS v1.0.TLS v 1.2 is not vulnerable to a BEAST attack. The CVE for a BEAST attack is CVE-2011-3389. Whenever you log in to any https page, after your authentication you can see your authenticated page and, if you look carefully at the URL, you can see the session ID. A session ID is a random number or combination of numbers and string that maintains the state of the page; it is assigned by the website server to the client browser. The Session ID can be found either in the cookie or in the URL of the web browser .Usually, all the session IDs will be encrypted to prevent hijacking of the session. I can break down this BEAST attack into three steps for simplicity. Step 1: An attacker sends a malicious JavaScript to run on your machine (this can be sent via CSRF, Social engineering ,A Drive-by download, the returned page can contain a JavaScript, etc.).This malicious script runs on the victim’s machine and can capture the entire header info and the encrypted cookie that is assigned from the web server (running TLS 1.0) and can then send the information to any website. Step 2: SSL/TLS can encrypt data with two kinds of ciphers: block ciphers, such as AES and DES, and stream ciphers like RC4.TLS v1.0 gives precedence to the block cipher rather than stream ciphers. This is where our vulnerability exists. If we have two identical plain text messages then, after encryption, we have the same cipher text so the pattern in plaintext is reflected in the cipher text. This is bad. In order to prevent this, we use cipher block chaining (CBC mode chaining).In CBC, if we want to encrypt block A, first we need to XOR with A-1. If it is the first block we cannot XOR with A-1 data so here we take the initialization vector. Step 3: The attacker compares the encrypted session details and the unencrypted data sent by the script to find the initialization vector. Once you get this information, we could decrypt the future cookies sent from the web server. You can check whether your website is vulnerable to BEAST attacks by doing a scan from SSL Labs: https://www.ssllabs.com/index.html.

Workaround for BEAST attacks

Mitigation Open the Local Group Policy Editor.

At a command prompt, enter “gpedit.msc”. The Group Policy Object Editor appears. Expand Computer Configuration, Administrative Templates, and Network, and then click SSL Configuration Settings. Under SSL Configuration Settings, double click the SSL Cipher Suite Order setting.

The cipher suites, TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_RC4_128_MD5, must be put first on the line.

CRIME (Compression Ratio Info-Leak Mass Exploitation)

CRIME (compression ratio info-leak made easy/compression ratio info-leak mass exploitation) is a new attack that was developed by two security researchers, Juliano Rizzo and Thai Duong. It decrypts the session cookies from the hypertext transfer protocol secure (HTTPS) connections by means of brute force. The so-called CRIME attack induces a vulnerable web browser into percolating a cookie authentication, created when a user starts a HTTPS session with a website. The obtained cookie can be used by hackers to log in to the victim’s account on the site. The cookie is obtained by tricking the browser into sending encrypted compressed requests to secure websites and exploiting the information negligently leaked in the process. Some extra data that has been tweaked by malicious JavaScript code is also embedded along with the cookies within each request. The differences in size of the compressed messages are measured to determine the cookie’s contents, character by character. This is possible because TLS/SSL and SPDY use a compression algorithm called DEFLATE, which works by eliminating duplicate strings.

CRIME works against TLS/SSL Compression and SPDY (a special HTTP-like protocol developed by Google, and used sparingly around the web). The recent statistics gathered by SSL Pulse show that about 42% of the servers support SSL compression and 0.8% supports SPDY. SSL compression, as it is an optional feature that may or may not be enabled by default –it’s not necessary to be explicitly configured. However, SPDY would be explicitly designed into your web application.

Vulnerable Systems

TLS 1.0. SPDY protocol (Google). Applications that uses TLS compression. Mozilla Firefox (older versions) that support SPDY. Google Chrome (older versions) that supported both TLS and SPDY.

Mechanism of the C.R.I.M.E Attack

Analysis

To understand the CRIME weakness, we need to understand the working of lossless data compression in SPDY and TLS/SSL (DEFLATE algorithm). Lossless data compression finds the redundancies in the body of the data and then these redundancies are represented in a smaller fashion. Consider this example: Assume that “AAAAABCDEFGH” is the source data that is being transported across a HTTPS connection. The mechanism of compression algorithm replaces the redundant sequence “AAAAA” with “5A,” thereby achieving a 25% compression ratio. Hence we get AAAAABCDEFGH = 5ABCDEFGH. Encrypted data has no redundancies and the output should be uniformly random. The encrypted output pattern gives information on how the data is being encrypted and some hints about the input data. So, for the effective working of compression plus encryption in the TLS/SSL, the input should be first compressed and then encrypted. Let’s consider two strings that use the compression scheme and encrypt the output. [plain] Data (Source) Compressed Encrypted

ABCDEFGHIJKL = ABCDEFGHIJKL = Z@%fkT2r$#!B AAAAABCDEFGH = 5ABCDEFGH = jhG*4m#$A [/plain] We find that the first string, “ABCDEFGHIJKL,” is not compressed because it doesn’t contain any redundancy. The second string, “AAAAABCDEFGH,” is compressed because it does contain a redundancy, thus the encrypted output is made smaller. When comparing the string outputs, we find that compression happens before encryption and also that the encrypted output of the second string is shorter than the encrypted output of the first string. Thus we could conclude that the encrypted output of the second string has more redundancy compared to the other string.

Breaking encryption by analyzing the compression algorithm

An attacker could decrypt the source data by understanding the underlying compression algorithm. Let us consider this example; [plain] Data (Source) Compressed Encrypted

XYZABCDEFGHIJK = XYZABCDEFGHIJK = At9XeCNVxKt@XZC [/plain] It is obvious that the attacker doesn’t know what the source data and the compressed data, but he can see the encrypted data. In order to decrypt or find the unknown data, as a first step he adds an input “XYZ” along with the source data. At this point, he only knows his own input and the encrypted data. [plain] Data (Source) Compressed Encrypted

XYZ [Unknown Data] = [Totally Unknown] = At9XeCNVxKt@XZC [/plain] The “compression before encryption” associated with the security mechanism helps the attacker to find the unknown data, which purely depends on the value that is being supplied by the attacker, along with the unknown source data. Here the attacker tries three different input strings along with the source data. [plain] Data (Source) Compressed Encrypted

ZZZ [Unknown Data] = [Totally Unknown] = QvnQSHvQWB3QR YYY [Unknown Data] = [Totally Unknown] = ffB&M7sya*u7F AAA [Unknown Data] = [Totally Unknown] = rAW^26uffH%8 [/plain] When the attacker inputs the string ‘AAA’ along with the source data, the redundancy of the data is increased and hence makes better compression of the data, thereby making the encrypted data length smaller. This in turn helps the attacker to confirm the existence of the string “A” in the source data. The attacker could repeat this technique with different values and infer the unknown source data fully. The offender adds some content in the source data, HTTP cookies (with session information). This data is compressed and encrypted. The attacker then analyzes the encrypted data by changing the control input, hence gaining insight into the redundancy of the data that gets compressed and ultimately learning the contents of the HTTP cookies.

Mitigation

A CRIME attack can be mitigated by disabling the compression mechanism of HTTPS requests. Therefore, the TLS/SSL auto compression of the web browsers/websites should be disabled. The compression method used on the server side is directly dependent on the compression mechanism on the client side, so if the data compression mechanism is disabled at the client side, the data at server side is automatically processed without compression, thereby preventing the CRIME attack. When the compression technique is enabled, use the cipher-chaining block (CBC) ciphers, which incorporate random padding up to 255 bytes. This technique would increase the number of trials an offender needs to infer the sensitive data. Implementing restrictions on cross-site requests known as CSRF (cross-site request forgery) on the client side helps to defeat the CRIME attack. TLS compression on the web servers should be. Upgrading web browsers, such as Mozilla and Chrome, that use TLS compression is recommended (IE browsers are not vulnerable to CRIME attacks).

Sources

Security impact of the rizzodu SSL TLS Development best practices CipherSuite mitigation for beast New attack SSltls information leak hijiack  Crime information leakage attack against ssltls Details on the crime attack Crime new ssltls attack for hijacking Crime tls attack  Security researchers