Raccoon Attack
Tags: raccoonattack
Published: 2020-10-14 16:18:31

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/o2qb7jfb97o31phzpi6x.jpg)

Raccoon is a timing vulnerability in the TLS specification that affects HTTPS and other services that rely on SSL and TLS. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication.

Raccoon allows attackers under certain conditions to break the encryption and read sensitive communications. The vulnerability is really hard to exploit and relies on very precise timing measurements and on a specific server configuration to be exploitable. 

Attack Overview

Diffie-Hellman (DH) key exchange is a well-established method for exchanging keys in TLS connections. When using Diffie-Hellman, both TLS peers generate private keys at random (a and b) and compute their public keys: g^a mod p and gb mod p. These public keys are sent in the TLS KeyExchange messages. Once both keys are received, both the client and server can compute a shared key gab mod p - called premaster secret - which is used to derive all TLS session keys with a specific key derivation function.

Our Raccoon attack exploits a TLS specification side channel; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. Since the resulting premaster secret is used as an input into the key derivation function, which is based on hash functions with different timing profiles, precise timing measurements may enable an attacker to construct an oracle from a TLS server. This oracle tells the attacker whether a computed premaster secret starts with zero or not. For example, the attacker could eavesdrop ga sent by the client, resend it to the server, and determine whether the resulting premaster secret starts with zero or not.

Learning one byte from a premaster secret would not help the attacker much. However, here the attack gets interesting. Imagine the attacker intercepted a ClientKeyExchange message containing the value ga. The attacker can now construct values related to ga and send them to the server in distinct TLS handshakes. More concretely, the attacker constructs values gri*ga, which lead to premaster secrets gri*b*gab. Based on the server timing behavior, the attacker can find values leading to premaster secrets starting with zero. In the end, this helps the attacker to construct a set of equations and use a solver for the Hidden Number Problem (HNP) to compute the original premaster secret established between the client and the server

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hksk0oe4rdxfpz326zz1.png)
 
Figure 1: Raccoon attack overview.  The attacker passively observes the public DH shares of a client-server connection and uses an oracle in the TLS key derivation to calculate the shared DH secret using a solver for the Hidden Number Problem.

TLS-DH(E): Transport Layer Security (TLS) relies on the DH assumption and adapts the DH key exchange to compute a shared key(ga)b between a client and a server. The shared key is used as a premaster secret to derive all necessary cryp-tographic material for the established connection. In practice,TLS peers can use two DH key exchange types: TLS-DH and TLS-DHE. In a TLS-DH connection, the server uses a static value b. In TLS-DHE, the server uses an ephemeral value b 

The Hidden Number Problem: In 1996, Boneh and Venkate-san presented the Hidden Number Problem (HNP) [16], orig-inally to show that using the most significant bits (MSB) ofa Diffie-Hellman secret is as secure as using the full secret.Their proof includes an algorithm that, given an oracle forthe MSBs of DH shared secrets where one side of the keyexchange is fixed, computes the entire secret for another suchkey exchange. The algorithm presented in that seminal workuses basis reduction in lattices to efficiently solve the ClosestVector Problem.While initially presented as part of a positive security result,the  HNP  and algorithms  for solving  it later found use  ascomponents  in  cryptographic attacks.   For example,  suchalgorithms have been used to break DSA, ECDSA, and qDSAwith biased or partially known nonces [9,11,17,23,48–50,62].Perhaps surprisingly, the original target of the HNP, Diffie-Hellman key exchange, remained hitherto unattacked.Weclose this gap by presenting the first full HNP-based attack on TLS-DH(E).

Raccoon  attack: The Raccoon  attack can  recover  TLS-DH(E)  premaster  secrets  from  passively-observed  TLS-DH(E) sessions by exploiting a side channel in the server and solving the Hidden Number Problem using lattice reduc-tion algorithms.  The attack requires that the server reusesthe same Diffie-Hellman share across sessions which is pro-vided by a server with static TLS-DH or by a server reusing ephemeral keys in TLS-DHE [61].On a high level, the attack works as follows (cf. Figure 1):1.The attacker records the TLS handshake, including both the client DH share gaand the server share gb.2.The attacker initiates new handshakes to the same server(therefore with the same gb), using gri·gafor some ran-domly chosen ri.  The premaster secret for these new sessions is(gri·ga)b=grib·gab. The attacker can com-pute the first term, and the second term is the targeted DH secret.3.For each handshake, the attacker measures the response time of the server. For some modulus sizes, DH secrets with leading zeroes will result in a faster server KDF computation, and hence a shorter server response time.4.Assume temporarily that the attacker can perfectly detect the above case.   Each such case can  be converted to an equation in the Hidden Number Problem.  When a sufficient number of equations has been determined, the HNP can be solved to calculate gab, the secret Diffie-Hellman value of the original handshake. The attacker can then decrypt the original TLS traffic to recover its plain text.

FACTS...............!!

Why is the attack called "Raccoon"?
Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)

How is this attack related to other TLS attacks?
Many of you would probably remember Bleichenbacher's attack (see also ROBOT for practical exploits). This adaptive chosen-ciphertext attack exploits server behavior differences by processing RSA PKCS#1 v1.5 messages. It allows the attacker to decrypt the premaster secret after a few thousands of connections. From the attacker model perspective, the Raccoon attack is very similar to Bleichenbacher's attack; the attacker also needs to send several modified Client Key Exchange messages to the server, observe its responses, and perform some cryptographic computations to reveal the premaster secret. In contrast to Bleichenbacher's attack, Raccoon targets the DH key exchange.

Lucky 13 is another cool attack you might have in mind when reading the description of the Raccoon attack. In Lucky 13, AlFardan and Paterson exploited different timing behaviors of HMACs computed over different TLS record lengths. This allowed them to distinguish valid from invalid paddings and apply CBC padding oracle attacks. The attack works in a BEAST attack scenario and allows the attacker to decrypt TLS records. In contrast, our Raccoon attack exploits the timing behavior difference resulting from the HMAC computations over premaster secrets of different lengths. It reveals the premaster secret and thus decrypts the whole connection based on a single eavesdropped Client Key Exchange message. Our Raccoon attack was inspired by the Lucky 13 side channel. 

Is this vulnerability really serious enough to deserve a name, a                logo and a web page?
It is a vulnerability in the TLS specification, so we think...yes.   In addition, it was fun to create them :)

You can contact me via mail:
Sumeer Anand, VIT Mumbai , sumeer.anand.vit.edu  

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/mjapk9rd7yr5pyk3l17o.png)