POODLE Attack Explained

POODLE stands for ( “Padding Oracle On Downgraded Legacy Encryption”). In this vulnerability, an attacker which is Man-in-the-Middle(MiTM) first

• Downgrade the TLS connection to SSLv3.
• Then if the cipher suite uses RC4 or Block cipher in CBC mode, attacker can retrieve partial bytes of encrypted text and later on can get full plain text.

Let’s see how each of them work.

Downgrading connection to SSLv3

This can be done by repeatedly dropping the session and eventually client will try with lower SSL version.

Before explaining how the attack works, let’s look at the some basic ingredients for recipe of disaster!.

Remember that in TLS connection when both side generate same master secret, afterward they generate session keys using PRF/HKDF function. These session keys are client_write_MAC_secret, server_write_MAC_secret client_write_key, server_write_key, client_write_IV, server_write_IV.

These keys are used for symmetric encryption and calculating HMAC.

Normally when you want to send encrypted data, one does encryption as well as calculate keyed hash (HMAC) using MAC secret. This is done to avoid tampering with encrypted data. Now there are 3 ways how HMAC can be calculated.

Mac-then-Encrypt: Here first MAC of plain text is calculated, it is then append to plain text, padding is added to make it integral multiple of block size and then encryption is performed.On receiver side, first cipher text has to be decrypted and then MAC on the decrypted text is calculated , afterward MAC verification take place.

Encrypt-then-MAC: In this scenario, first encrypt and then calculate MAC of encrypted text. So on receiver side, first a MAC is computed on received cipher text and only if it is valid, decryption is performed. [Cipher_Text, MAC(Cipher_Text) ]

Encrypt-and-MAC: Encryption & then MAC is taken of plain text. [Cipher_Text, MAC(Plain_Text) ]

CBC (Cipher Block Chaining) Mode for Block Cipher: Block cipher operate on multiple of block of plain text. What block size is to be used is feature of underlying algorithm like DES uses block if 8 bytes while AES uses 16 bytes.Padding is used for left over bytes to make it integral multiple of block size.

How blocks are padded

Lets see block size is 8 bytes. Since the message is smaller than block size, 3 bytes of padding is applied and the last byte tell the length of padding and all the padded bytes should also contain value 0x03.

Padding before a CBC block encryption.

If a block is already integral multiple of block size, still another padding block is added which will contain all 8 bytes as 0x08

During decryption, last byte of last block is checked for padding and all the bytes in that block must contain that value.

Note: Content of padding bytes are not covered by MAC and also the content of padding is not defined by TLS specification.

How CBC Encryption/ Decryption works:

CBC Encryption (www.wikipedia.org)

Cₙ = E ( Pₙ ⊕ Cₙ_₁ ) where C₀ =IV and E is encryption function for e.g. AES/DES, Pₙ is plain text of block size.

Similarly for decryption, which is reverse process once first start with last block.

CBC Decryption(www.wikipedia.org)

Pₙ = D(Cₙ) ⊕ Cₙ_₁

In SSLv3, CBC is used with Mac-then-Encrypt, so a MAC is first calculated on plain text and afterward CBC encryption is applied. The first step is to get integral number of blocks of block size.

Attacker insert a javascript code which simultaneously creates lot of connection in background. This connection URL is crafted such that it is integral multiple of block size. Note that in this case an extra block of padding inserted whose last byte will always be 15.

Suppose that you know the cookie value is in the 3rd block of ciphertext. This is easy to know since the format of HTTP GET request is fixed. For example

CBC Encryption of HTTP GET request which has Cookie

Attacker intercept cipher text and replace Cₙ by C₃ and after 1 in 256 retries this complete encrypted block will be accepted, which means last byte of decrypted block is 15. Why 1 in 256 ? because the javascript code to request URL keep change something or other in the URL, which changes the previous block MAC and once the decryption operation result last byte as 15 and only then MAC verification succeed.

15 = D(C₃) ⊕ Cₙ_₁[15]

We know from encryption equation that

Cₙ = E ( Pₙ ⊕ Cₙ_₁ ) ====> Cₙ = E ( Pₙ) ⊕ E(Cₙ_₁ ) replace C₃ by this in above equation we get.

15 = D (E ( P₃) ⊕ E(C₂ ) ) ⊕ Cₙ_₁ , simplifying this we get

15 = P₃ ⊕ C₂ ⊕ Cₙ_₁ ….XOR both side by 15 ⊕P₃, we get

P₃[15] = C₂ ⊕ Cₙ_₁ ⊕ 15 so we found last byte of 3rd block.

Similarly we can found rest of the bytes of P₃ by shifting the Plain text such P₃[15] now contain penultimate byte of cookie and like that one can get complete Cookie Value.

Mitigation

• Disable SSLv3 on client as well as Servers.
• Client should use this cipher TLS_FALLBACK_SCSV. This tells the server that client is degrading to a lower SSL version but it is capable of higher version than this. This signals the server some man in the middle is trying to play with connection and hence connection is aborted.

CVE-ID: https://nvd.nist.gov/vuln/detail/CVE-2014-3566

Reference:

ImperialViolet

This POODLE bites: exploiting the SSL 3.0 fallback