What is POODLE Attack?

Table of Contents

1 History
2 Blame the need for graceful degradation of security
3 Preparation for the IoT inevitable
4 Case Study
- 4.1 The POODLE Attack
5 Prevention
- 5.1 A POODLE TLS Attack

The POODLE attack (which stands for “Padding Oracle On Downgraded Legacy Encryption”) is a man-in-the-middle exploit which takes advantage of Internet and security software clients’ fallback to SSL 3.0. If an attacker exploits this vulnerability successfully, on average only 256 SSL 3.0 requests are required to reveal one byte of encrypted messages.

The Poodle attack was discovered by Google people is a huge thing. It will not be difficult to fix, because most systems do not have to support SSLv3. Fixing these will only mean changing configuration so that SSL failback is not permitted. However, once again this flaw points out that the weakest link in safety is often the graceful degradation mechanisms that promote interoperability. Logic that degrades security for interoperability is difficult to achieve and often easy to use. Usually the attacker connects while pretending to be the “stupidest” main, allowing the “smarter” principal to reduce security to the lowest it will.

It’s not all new. What might be new is an idea of what such defects may imply on the emerging Internet-of – Things domain.

History

Poodle is a design flaw (that is, related to the protocol, not to a certain execution) that only succeeds because a mechanism exists that addresses fragmentation in the TLS space of the client / server.

Poodle can simply take advantage of an SSLv3 connexion. SSLv3 was replaced a decade ago by a better protocol, and almost nobody uses it. So how can this attack still be so successful? It is simply successful by employing a faulty security degradation mechanism which has been developed to work around customer-server fragmentation.

Blame the need for graceful degradation of security

We have the web for decades, with billions of users and yet decades after a new security protocol, each device must always be programmed with complicated and defective ‘graceful degradation’ mechanisms, as old SSLv3 devices are still on board. SSLv3 connexions represent only 0.65 percent of all secure connexions, but nobody wants its device / software to be the only one that refuses connexions. We are all held back because of this “fragmentation” and the double quota is there because 0,65 percent barely deserves to be called “fragmentation.”

Preparation for the IoT inevitable

IoT has zero to little security today. It improves one day, but the long tail of less secure device (let alone totally insecure) is going to be long and thick for decades. And so, mechanisms of graceful security degradation known to be nearly impossible to do right in a security community will last for decades.

Since it is so difficult to correct graceful security degradation and the security of IoT will have to be full of it, we must prepare ourselves for the day-by-day supply of Poodles. Means of recovering from Poodle-du-jour are therefore at least as important as making our systems safe in the first place.

Case Study

The POODLE Attack

To work with legacy servers, several TLS clients perform downgrade dances: in a pristine attempt, offer the client-supported highest protocol version; if that handshake fails, try (maybe repeatedly) on previous protocol versions. This downgrade can even be triggered by network crashes, or by active attackers (as opposed to the correct version negotiation of protocols (where the client offers TLS 1.2, the server may react by, say, TLS 1.0, if an attacker that controls a network between the client and a server interfers with the attempted handshake of TLS 1.0 or later, such clients may confine themselves readily.

The SSL 3.0.Encryption in SSL 3.0 uses either the ciffer of the stream RC4, or the cypher block of the CBC mode RC4 is well known to have bias [RC4-biases], which means more and more information is being leaked when a similar secret (like a password or HTTP cookie) is sent over a number of connexions, encrypted with numerous RC4 streams. We show how to combine an efficient assault on CBC cryptography, as used by SSL 3.0, if the assailant can modify network transmissions between a client and the server as well. Unfortunately, there is no reasonable solution to the BEAST [BEAST] and Lucky 13 [Lucky-13] attacks. In order to secure encryption SSL 3.0 is not possible at all. The most serious problem of CBC encryption in SSL 3.0 is that it is not deterministic to padd its block cypher padding and does not include the MAC (Message Authentication Code): the integrity of padding can not therefore be verified when it is decrypted. Padding by 1 to L bytes (where L is the bytes of block size) is used in order to achieve an integral number of blocks before CBC (Chip-block chaining) encryption is performed blockwise. The deficiency is most easy to exploit if an entire padding block is present, which is made up of L−1arbitrary bytes followed by one byte of L−1 value (before encryption). To process a C1 ciphertextrecord … Cn also provides initialization vector C0 (where each Ci is one block) and determines P1 first … Pn as Pi = DK(Ci) −Ci-001(where DK denotes a per-connection key for block-cipherde encryption K), controls and removes the padding at the end, checks and then removes the MAC. Now note that if there is a whole block of padded and an attacker replaces Cn by an earlier ciphertext block Ci of the same encrypted stream then ciphertext is still accepted if the DK(Ci) is L-001 but probably otherwise rejected, leading to a padding oracle assault[tls−cbc]. In the web setting the weakness of the SSL 3.0 can be exploited by a m To launch POODLE attack, run a JavaScript agent on malil.com (or on http:/example.com), to get your browser to send HTPS cookie-carrying requests to https:/example.com, and to intercept and modify the SSL records from the browser so that example.com accepts the modified record an anonymous opportunity. The attackers can decrypt one byte of their cookies if the modified record is allowed. Suppose each block C has 16 bytes, C[0] … C. (Eight-byte blocks may be processed in a similar way). Assume also that cookies are known for now. SSL 3.0 CBC cypher suites are typically 20bytes in size and, under the CBC layer, an encrypted POST request is as follows: POST /path cookie: name = value … \r\n\r\nbody / padding 20-byte MAC \ padding The assailant is controlling the request path and the request body, and can thus induce queries such that the two following conditions holly:

The server usually rejects this record and the attacker just tries with a new request again. On average once in 256 requests, the server will accept the modified record, and the attacker will conclude that DK(Ci) Alternative to CN-1 = 15, which is why Pi = 15 Alternative to CN-1 Alternative to CI-1, may be accepted as a result. This reveals the first unknown cookies. The attacher proceeds to the next byte by changing the sizes of the request path and body simultaneously to ensure that the request size remains the same, while the position of the headers remains shifted until the desired cookies have been decrypted. The expected overall effort is 256 SSL 3.0 requests per byte. allows the attacker to toobserve the point at which the border crosses the block: after a minimum of 16 such requests, the blocking size will be disclosed, and thus the size of the cookies. RecommendationsThe attack described above requires an SSL 3.0 connexion to be established, disabling the SSL 3.0 protocol on the client or in the server (or both). When SSL 3.0 is not disabled, or the only possible protocol version, then an attack is possible if the client uses downgrade dance for interoperability. If it is occasionally required to work with legacy systems, the disabled SSL 3.0 may not be practical. Similar downgrades of protocol versions are always concerned with newer versions of protocols (though not almost as severe as SSL 3.0). The [draught-ietf−tls-downgrade-scsv−00] mechanism TLS FALLLBACK SCSV addresses the broader problem across protocol versions and considers it particularly important for systems that maintain SSL 3.0 compatibility. The following recommendations should sum up TLS FALLBACK SCSV works. The value of CLS FALLBAR SCSV 0x56, 0x00 (TLS FALLBAR SCSV) in ClientHello.cipher suites should be included in the following recommendations. This is a signal that allows updated servers to reject the connexion in the event of a downgrade attack. Clients should always go back to the following version (If they start with TLS 1.2, try TLS 1.1 next, then TLS 1.0, then SSL 3.0 then). (When a version is skipped by TLS FALLBACK SCSV, the successful handshake could also be totally prevented if a handshake is used for a version of the server). In TLS Servers, where a connexion includes 0x56, 0x00(TLS FALLBACK SCSV) in ClientHello.cipher suites, compare ClientHello.client version to the highest server-supported protocols. Reject the connexion with a fatal alarm if the server supports a version higher than the one specified by the client (preferably the inappropriate fallback from the [draught-ietf-tls-downgrade-scsv-00]).

By using TLS FALLBACK SCSV, SSL 3.0 is only used when a legacy implementation is involved; attacker can no longer downgrade a protocol. (Attack remains possible where SSL 3.0 is allowed by both parties, but the client is not updated to supportTLS FALLBACK SCSV, provided that downgrade to SSL 3.0 is carried out).

Prevention

One approach to mitigating the POODLE attack is to disable SSL 3.0 completely on the client and server side. However, some old servers or clients do not support TLS 1.0 or higher. The authors of the article on POODLE attacks therefore also encourage the implementation of the TLS FALLBACK SCSV browser and server that will prevent downgrade attacks.

The implementation of ‘anti-POODLE record splitting’ is another mitigation. It divides the records into several parts and ensures that none can be attacked. However, the division problem is that, while valid under the specification, compatibility problems may also occur due to problems in server-side deployments.

The article Transport Layer Security lists a full list of browser versions and levels of vulnerability to various attacks (including POODLE).

In addition to TLS FALLBACK SCSV, Opera 25 implemented this mitigation.

Google’s Chrome browser has already supported TLS FALLBACK SCSV with their servers. Google stated in October 2014 that it planned to completely remove SSL 3.0 support from its products within a couple of months. SSL 3.0 in Chrome 40, released in January 2015, has been disabled by default. Fallback to SSL 3.0 in Chrome 39, released in November 2014, was disabled.

In Firefox 34 and 31.3, Mozilla disabled SSL 3.0 and added TLS FALLBACK SCSV support in Firefox 35, which was released in December 2014.

Microsoft has issued a security advisory explaining how to disable SSL 3.0 in Internet Explorer and Windows OS, and Microsoft has published on October 29, 2014 a fix that disables SSL 3.0 in Windows Vista / Server 2003 and above on Internet Explorer and have announced a plan that will deactivate SSL3.0 in its products and services by default in a few months ‘ time. On February 10, 2015, Microsoft disabled fallback to SSL 3.0 on Internet Explorer 11 for Protect Mode sites and on April 14, 2015 on other sites.

A POODLE TLS Attack

On December 8, 2014, a new version of the original POODLE attack was announced. This attack exploited CBC encryption mode implementation flaws in the TLS 1.0-1.2 protocols. Although TLS require servers to check the padding, there are implementations that fail to properly validate it, which makes some servers vulnerable to POODLE, even when SSL 3.0 is disabled. Before this vulnerability was announced, SSL Pulse showed that “around 10% of servers are vulnerable to the TLS POODLE attack.” The CVE-ID for the implementation of F5 Networks is CVE-2014-8730. In the NIST NVD, it is stated that this CVE-ID is only for use in the F5 Network implementation of TLS and, for implementation errors, other suppliers whose products fail to validate the padding mistake in their A10 Networks and Cisco Systems must issue their own CVE-IDs. This is not a protocol but an implementation error.

The POODLE attack on TLS has been found to be easier than the initial SSL POODLE attack. Clients do not need to be downgraded to SSL 3.0, so less steps are needed to successfully launch an attack.