Freigeben über

POODLE Vulnerability: Padding Oracle on Downgraded Legacy Encryption

  • Artikel

INTRODUCTION

POODLE abbreviates to Padding Oracle On Downgraded Legacy Encryption. This vulnerability was discovered by Bodo Möller, Thai Duong & Krzysztof Kotowicz from the GOOGLE security team and published here. I'm using the information published in this article as a reference for this blog post. This vulnerability has been listed in NVD; here is the link: CVE-2014-3566. Microsoft also has released a security bulleting on this issue: https://technet.microsoft.com/library/security/3009008.aspx

As the name suggests, POODLE exploits the design flaws of the legacy cryptographic protocol SSL 3.0.

  • Secure Socket Layer 3.0 or SSL 3.0 is a legacy cryptographic protocol which is a predecessor to TLS. It is considered obsolete and insecure due to many flaws in its design. For more technical details refer RFC 6101.
  • Transport Layer Security or TLS is a successor to SSL. There were several security flaws and design issue in SSL which lead to development of TLS 1.0 ( also sometimes referred to as SSL 3.1) . TLS 1.0 provides a fall-back mechanism to SSL 3.0 so that clients/servers which are not compatible with TLS
    1.0 can use SSL 3.0.

NOTE: SSL 2.0 alsoexists which is a predecessor to SSL 3.0. These are the version of SSL or TLS drafted till date:

  1. SSL 2.0
  2. SSL 3.0
  3. TLS 1.0 (version field 3.1)
  4. TLS 1.2 (version field 3.2)
  5. TLS 1.2 (version field 3.3)

 

  • Protocol Negotiation – The SSL/TLS protocol handshake allows the client and server to negotiate the latest protocol version common to the client and the server. If during negotiation if they fail to use TLS then they fall-back to SSL 3.0.

The POODLE attack exploits the fall-back mechanism to downgrade a secure connection to SSL 3.0 and then breaks the cryptographic security of SSL 3.0 to steal sensitive data such as HTTP cookies, HTTP Authorization header contents etc.

How does POODLE work?

To understand this attack knowledge of CBC mode encryption is required. Refer this post of mine to understand how this works: https://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx

SSL handshake: https://blogs.msdn.com/b/kaushal/archive/2013/08/03/ssl-handshake-and-https-bindings-on-iis.aspx

Almost all of the clients that exist today support SSL 3.0 and provide a fall-back mechanism from TLS 1.0 to SSL 3.0 (This downgrade purely exists for backward compatibility for legacy clients/servers). It uses this downgrade option to implement Man-in-the-Middle attack to exploit a vulnerability in SSL 3.0.

Many clients/servers have a fall-back mechanism to work with legacy server/clients. During the SSL handshake, the client offers the highest protocol version supported by it, if this is not supported on the server, then server responds with what is supported and re-attempts the handshake. However there is a problem with the fall-back mechanism from TLS 1.0
à
SSL 3.0. This fall-back can also be triggered by network glitches or by an attacker who resides in between client and the server.

Once the attacker has succeeded in downgrading the connection to SSL 3.0, he proceeds ahead. SSL 3.0 like any other protocol supports RC4 stream ciphers and block ciphers in CBC mode. RC4 is considered to be not secure; refer this blog post to know why: https://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

On the security of RC4 in TLS & WPA: https://www.isg.rhul.ac.uk/tls/

Also read this wiki article: https://en.wikipedia.org/wiki/RC4. Refer to section Roos' biases and key reconstruction from permutationand
Biased outputs of the RC4 which explains the problem in RC4.

Coming to the CBC mode encryption in SSL 3.0, it has a serious flaw. Its block cipher padding is not deterministic, and not covered by the MAC (Message Authentication Code). As a result of this the encrypted text is exposed to the Man-in-the-middle attack which uses oracle padding to retrieve the encrypted text. This has been well explained in the article I outlined earlier. Below, is a snippet of the article from Google Security team explaining the attack in detail:

The most severe problem of CBC encryption in SSL 3.0 is that its block cipher padding is not deterministic, and not covered by the MAC (Message Authentication Code): thus the integrity of padding cannot be fully verified when decrypting. Padding by 1 to L bytes (where L is the block size in bytes) is used to obtain an integral number of blocks before performing blockwise CBC (cipher-block chaining) encryption. The weakness is the easiest to exploit if there's an entire block of padding; which (before encryption) consists of L-1 arbitrary bytes followed by a single byte of value L-1. To process an incoming ciphertext record Ci…Cn also given an initialization vector C0 (where each Ci is one block), the recipient first determines Pi… Pn as Pi = Dk (Ci) ⊕ Ci-1, 1 (where Dk denotes block-cipher decryption using per-connection key K), then checks and removes the padding at the end and finally checks and removes a MAC. Now observe that if there's a full block of padding and an attacker replaces Cn by any earlier ciphertext block C from the same encrypted stream, the ciphertext will still be accepted if Dk (Ci) ⊕ Cn-1 happens to have L-1 as its final byte, but will in all likelihood be rejected otherwise, giving rise to a padding oracle attack [tls-cbc].

In the web setting, this SSL 3.0 weakness can be exploited by a man-in-the middle attacker to decrypt "secure" HTTP cookies; using techniques from the BEAST attack (BEAST). To launch the POODLE attack (Padding Oracle On Downgraded Legacy Encryption), run a JavaScript agent on evil.com (or on https://examplecom) to get the victim's browser to send cookie-bearing HTTPS requests to https://example.com, and Intercept and modify the SSL records sent by the browser in such a way that there's a non-negligible chance that example.com will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies.

Assume that each block C has 16 bytes, C[0]…C[15] . (Eight-byte blocks can be handled similarly.) Also assume for now; that the size of the cookies is known. (Later we will show how to start the attack if it isn't) The MAC size in SSL 3.0 CBC cipher suites is typically 20 bytes, so below the CBC layer, an encrypted POST request will look as follows:

POST /path Cookie: name=value… \r\n\r\nbody || 20-byte MAC || padding

The attacker controls both the request path and the request body, and thus can induce requests such that the following two conditions hold:

  • The padding fills an entire block (encrypted into Cn).
  • The cookies' first as of-yet unknown byte appears as the final byte in an earlier block (encrypted into Ci)

The attacker then replaces Cn by Ci and forwards this modified SSL record to the server. Usually, the server will reject this record, and the attacker will simply try again with a new request. Occasionally (on average, once in 256 requests), the server will accept the modified record, and the attacker will conclude that Dk (Ci)[15] ⊕ Cn-1[15]=15, and thus that Pi[15] = 15 ⊕ Cn-1[15] ⊕ Ci-1[15] . This reveals the cookies' first previously unknown byte. The attacker proceeds to the next byte by changing the sizes of request path and body simultaneously such that the request size stays the same but the position of the headers is shifted, continuing until it has decrypted as much of the cookies as desired. The expected overall effort is 256 SSL 3.0 requests per byte.

As the padding hides the exact size of the payload, the cookies' size is not immediately apparent, but inducing requests GET /, GET /A, GET /AA, … allows the attacker to observe at which point the block boundary gets crossed: after at most 16 such requests this will reveal the padding size and thus the size of the cookies.

The attack is pretty much similar to BEAST as it uses the oracle padding attack. However unlike BEAST there is no work-around mechanism or a fix that can be deployed to fix this vulnerability in SSL 3.0.

Workaround/Solution

The attack works by establishing a secure connection using SSL 3.0. Therefore, one could simply disable the SSL 3.0 protocol at their end to safeguard themselves against this attack.

However if the client/server supports only SSL 3.0 then there is no workaround. The Google security team has submitted a draft which suggests the TLS_FALLBACK_SCSV mechanism to address the protocol downgrade problem. They have already implemented this in their own products. Read this article for more details: https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

So to summarize, to protect against this attack one has to disable SSL 3.0 on the server/client. I will summarize the steps for doing this on IIS 6 and higher, Microsoft Azure Web Sites, Firefox, Chrome and IE.

For IIS Web Server (version 6.0 and higher)

Note that IIS relies on the cryptographic implementation provided by Windows (SChannel) for secure communication (HTTPS). So IIS uses the SChannel component to implement HTTPS communication with various clients.

  1. Click Start, click Run, type regedit, and then click OK.

  2. In Registry Editor, locate the following registry key (if not present you can create it)

    HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server

  3. On the Edit menu, click Add
    Value.

  4. In the Data
    Type list, click DWORD.

  5. In the Value
    Name box, type Enabled, and then click OK. 

  6. Type 00000000 in Binary Editor to set the value of the new key equal to "0".

  7. Click OK. Restart the computer.

NOTE: the above is a server wide change and will affect all the server side components which use SCHANNEL.

Another way to do this is:

  • Launch notepad.exe
  • Copy the below in to notepad:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]"Enabled"=dword:00000000
  • Save the file as disablessl3.reg (Note that the file extension is .reg)
  • Double click this file.
  • You would receive a prompt saying it is going to make changes to the registry. Click on OK.
  • Restart the computer for the changes to take effect.

For Microsoft Azure Web Sites

SSL 3.0 has been disabled by default for all sites running on Azure Websites. The product group has published a blog on how to disable this for Azure
VM and Cloud Services:

https://azure.microsoft.com/blog/2014/10/19/how-to-disable-ssl-3-0-in-azure-websites-roles-and-virtual-machines/

For Internet Explorer

Similar to IIS, IE also uses the SChannel component of Windows for cryptography and encryption. However it uses the client component of SChannel. To disable SSL 3.0 for IE follow the below instructions:

  1. Launch Internet Explorer.

  2. Go to Tools à
    Internet Options
    à
    Advanced tab.

  3. Scroll down to the bottom and here you will find the protocol list for IE. Uncheck SSL 3.0.

  4. Click on OK and restart the browser for the changes to take effect.

For Google Chrome

Google Chrome will be removing support for SSL .30 completely in its upcoming versions. Read this for more details: https://googleonlinesecurity.blogspot.com.au/2014/10/this-poodle-bites-exploiting-ssl-30.html

  1. Right click at your Chrome's desktop icon and click on Properties

  2. At the end of the target field enter:
    "  --ssl-version-min=tls1" (with space but without quotes).

  3. Click on Apply and then click on OK.

  4. Restart Chrome completely via the menu or with [Ctrl + Shift + Q]

For Mozilla Firefox

As per Mozilla security blog, SSL 3.0 will be disabled by default in Firefox v34, which will be released on Nov 25th 2014.

  1. For users who cannot wait, Firefox has released SSL Version Control Firefox extension to disable SSLv3 immediately.

  2. Click on the above link and click on Add to Firefox button.

  3. This doesn't require a restart.

The above extension changes the security.tls.version.min to 1. There are 2 keys which govern the SSL protocol for Firefox. They are:

  1. security.tls.version.min specifies the minimum supported protocol version.
  2. security.tls.version.max specifies the maximum supported protocol version.

Both security.tls.version.min and security.tls.version.max currently range from 0 to 3. If security.tls.version.min and security.tls.version.max are equal, only one protocol version will be supported. The behavior is undefined if security.tls.version.min is larger than the security.tls.version.max value.

Value

Protocol

0

SSL 3.0

1

TLS 1.0

2

TLS 1.1

3

TLS 1.2

 

You can access the above mentioned keys in Firefox by typing about:config in the address bar. Enter TLS in the search bar to retrieve TLS related settings.

NOTE: Please refer Google, Firefox and other related browser documentation for detailed information on the corresponding browsers.

 

Hope this article helps. Provide comments, for any corrections.

Comments

  • Anonymous
    October 23, 2014
    Nice article, and good explanation about Firefox SSL protocol numbering. Check this article with some additional info about disabling SSLv3 on Linux web servers, in addition to IIS and browsers. mohammadoweis.hubpages.com/.../What-you-need-to-know-about-Poodle-vulnerability

  • Anonymous
    February 03, 2015
    Comprehensive article on Poodle and covering the fixes as well. Good one

  • Anonymous
    June 25, 2015
    I have implemented all the changes on my servers but the Nessus scan is still throwing out POODLE detections, namely "It appears that TLSv1 or newer is supported on the server. However, the Fallback SCSV mechanism is not supported, allowing connections to be "rolled back" to SSLv3." How do I change the Fallback SCSV mechanism to stop these detections?