Disingenuous Poodle: Browsers Falling On Ssl 3.0

Yesterday Bodo Möller of Google, published a blog detailing a design vulnerability of SSL 3.0 [RFC5246] which allows cyber attackers to calculate the plaintext content of secure connections. This means that supposedly encrypted traffic between clients and servers can be intercepted. Attackers may also then be able to steal cookies, potentially allowing control over a victims email, banking and social networking accounts.

SSL 3.0

Introduced in 1996, the majority of browsers support SSL 3.0. The intention was to allow encrypted communication, facilitated by client-server security handshakes that created encrypting and decrypting keys.

Google researchers have now exposed a flaw in SSL 3.0 which they have coined POODLE (Padding Oracle On Downgraded Legacy Encryption). Simply put, SSL 3.0 encryption is now obsolete.

The Exploit

For backward compatibility, many servers support the use of legacy protocols (SSL 3.0 among them). The exploit utilises this approach to downgrade encrypted connections that use the newer Transport Layer Security (TLS) protocol to that of SSL 3.0. Thereby ensuring that the victim is vulnerable to attack. Once SSL 3.0 is triggered, decryption of secure HTTP cookies is possible using a simple man-in-the-middle (MiTM) attack.

MiTM attacks require attackers to place themselves between their victims (client) and their service provider (server). This means that the most vulnerable areas for this attack are unprotected networks and WiFi hotspots. However, an attacker could also go to the effort of deploying customised malware onto the client machine to proxy requests and therefore conduct local MiTM attacks.

Delving Deeper

It is known that RC4 (used by SSL 3.0) has biases, these result in incremental leaking of information from multiple connections which hold the same information, for example, usernames and passwords. Problems with CBC encryption have now also been uncovered.

The problem stems from block cipher padding that is used by cipher-block chaining (CBC) encryption not being deterministic and additionally not being covered by the Message Authentication Code (MAC). This means that padding integrity is unverifiable upon decryption. Attackers can leverage this vulnerability by using fast blockwise chosen-plaintext attacks. See “Here Come The Ninjas” by Thai Duong and Juliano Rizzo for more details.

To launch the POODLE attack:

Follow the steps below:

1. Run a JavaScript agent on http://example.com to get the victim browser to send cookie-bearing HTTPS requests to https://example.com.

2. Intercept and modify the SSL records sent by browser. This must be done to ensure a non-negotiable chance of example.com acceptance of the modified record.

3. After acceptance, the attacker can now decrypt one byte of the cookies.

If each block C consists of 16 bytes, C[0]-c[15], and the size of the cookie is known, the SSL 3.0 CBC cipher suites’ normal MAC size is 20 bytes.

An encrypted POST request under the CBC layer is as follows:

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

An attacker can control the request path and body and by doing so, can induce requests which result in the following conditions:

1. Padding fills an entire block, encrypted into Cn.

2. The first, as-of-yet unknown byte of the Cookie, appears as the final byte in an earlier block, encrypted into Ci.

Cn is then replaced by Ci and then this modified SSL record is forwarded by the attacker to the server. The server should then reject this record, however the attack will then try again with another request. Once in 256 requests the server will accept the modified record allowing the attacker to conclude that:

DK(Ci)[15]⊕Cn1[15]=15,

and thus that

Pi[15]=15⊕Cn1[15]⊕Ci1[15].

The above reveals the cookies first previously unknown byte. By changing the sizes of the request path and body simultaneously, the attacker can proceed to the next byte. This is done by keeping the request size the same but moving the positions of the headers. This process can be repeated until the attacker has decrypted as much of the cookies as desired. Expected effort is 256 SSL 3.0 requests per byte.

Whilst the padding does hide the payload size, inducing requests:

 GET /, GET /A, GET /AA, …

Will allow an attacker to reveal the point at which the block boundary is crossed, this means that after at most, 16 requests, the padding size will be revealed and thereby the size of the cookies.

To see this method in more detail view “This Poodle Bites: Exploiting the SSL 3.0 Fallback” by Bodo Möller, Thai Duong and Krzysztof Kotowicz, here.

Testing for POODLE

There are two sites that you can use to test for POODLE vulnerability:

To test your browser:

http://www.poodlescan.com

To test a server:

https://www.poodletest.com

There are also tests which can be conducted with GNU, Wget and cURL.

GNU Wget

% wget --secure-protocol=SSLv3 -O /dev/null https://example.com/

If a connection is established then the url tested is vulnerable.

cURL

% curl -3 https://example.com/ > /dev/null

Will result in..

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

100   163  100   176    0     0    454      0 --:--:-- --:--:-- --:--:--   654

If vulnerable the connection may be similar to the above. If not vulnerable the connection attempt will result in an error.

For more detail, see .@sknn’s tumblr here.

POODLE Mitigation

Google researchers Bodo Möller, Thai Duong and Krzysztof Kotowicz assert that the best mitigation of this bug is to disable client and server support of SSL 3.0 or SSL 3.0 RC4 stream/CBC-mode ciphers. However this may result in compatibility problems. Möller advises support for TLS_FALLBACK_SCSV (Transport Layer Security Signaling Cipher Suite Value). This mechanism stops the attacker from triggering the use of SSL 3.0 by addressing the problems arising from the retrying of failed connections. Furthermore, the mechanism additionally prevents future attacks by also addressing the possible triggering of TLS 1.2 to 1.1 and 1.0.

Google Chrome is reported to have supported TLS_FALLBACK_SCSV since February and have not identified any compatibility problems thus far. Testing of disabling the use of SSL 3.0 was begun yesterday by Google, they have warned that sites dependent on SSL 3.0 will need to be updated quickly as these sites will not be fully accessible by Chrome users.

End users should check their browsers, and disable SSL 3.0, if it is supported. There is already a Chromium patch and Mozilla will be disabling SSL 3.0 by default in Firefox 34, which will be available on 25^th of November. However to disable SSL 3.0 use in Firefox now, download the SSL Version Control add-on.