This poodle bites: using holes in SSL 3.0
Those who are interested in web security are already aware of yet another SSL vulnerability called POODLE. We will examine in detail what this vulnerability is and in what way it allows an attacker to get to seemingly protected user data, as well as tell how the Mail.Ru Group team handled this beast.
A comprehensive explanation of the mechanism for using POODLE is given in This POODLE Bites: Exploiting The SSL 3.0 Fallback ; Below we provide a translation of this article.
For those who are not too interested in the details of the activity of the malicious dog, recall that POODLE is a vulnerability in SSL 3, an old version of the protocol that survives the second ten. There are two ways to deal with vulnerability:
- Put on the server a patch that prohibits the rollback to SSL3 during the handshake process when it is not possible to connect via TLS. The catch is that this method only works if the patch is on both the server and the client. Currently, this is only implemented with Google Chrome (starting in February 2014) and is planned for the next Firefox update. It turns out that the safety of users to a certain extent falls on the shoulders of the users themselves.
- Disable SSL 3 on the servers, and that's the end. Simple and elegant, but there is one “but.” Most browsers use TLS version 1.0 and higher, but there are still people in the world who are not ready to part with the legacy of the past called Internet Explorer version 6, which simply does not support new versions of the protocol in the default configuration.
Our statistics show that through IE6, 0.2% of users enter Mail.Ru Mail. And although in absolute terms this is not such a small figure, we believe that safety is first and foremost. Therefore, we disabled the ability to connect to the client via SSL3 in Mail, Cloud, Calendar, authorization center and Mail.Ru for business.
For IE6 users, this means that Mail.Ru Mail, as well as other services that have chosen this method of combating POODLE, will no longer be available to them. It is unlikely that there are many followers of IE6 among the Habr audience, but we advise you to make sure that your relatives and friends who are not too friendly with modern technologies have updated their browsers.
In the case of services that chose the first way to protect against vulnerabilities, if you are a Chrome user who regularly updates automatically, congratulations, you are protected. If you prefer other browsers, we recommend using fresh Chrome, at least when accessing public Wi-Fi, because in this case you are vulnerable. Why then? This can be found in the translation below.
SSL 3.0 [RFC6101] is an outdated and insecure protocol. In solving most of the practical problems, it was already replaced by successors, protocols TLS 1.0 [RFC2246], TLS 1.1 [RFC4346] and TLS 1.2 [RFC5246], however, they retain backward compatibility with SSL 3.0 for interaction with older systems. This avoids problems with client devices when introducing new versions of protocols on servers.
But even if both the client and the server support TLS, the level of security in SSL 3.0 is still an issue, since many clients use older protocols to deal with server compatibility bugs. And here we would like to discuss how attackers can exploit this situation and crack the SSL 3.0 protocol. We are talking about the POODLE attack (Padding Oracle On Downgraded Legacy Encryption), due to which it is possible, for example, to intercept Secure HTTP cookies or the contents of HTTP authorization headers.
We will also recommend what actions to be taken on clients and servers to counter such an attack. If simply disabling SSL 3.0 is not suitable for compatibility reasons, then in existing versions of TLS you need to use TLS_FALLBACK_SCSV.
Description of POODLE VulnerabilitiesTo ensure compatibility with older versions of servers, many TLS clients use downgrade dance: first, an attempt is made to establish communication using the protocol of the latest version. If communication is not established, a new attempt is made, but using the older protocol. Unlike the normal version determination procedure supported by both parties (for example, the client accesses via TLS 1.2 and the server responds according to TLS 1.0), the above scheme may be triggered due to network errors or malicious actions. If the attackers controlling the network between the client and the server interfere and prevent the connection with the protocol version TLS 1.0 or higher, then the clients themselves switch to using SSL 3.0.
The protocol uses RC4 stream encryption, or block encryption in CBC mode. The main problem of RC4 is the presence of offsets: the more connections and encryption streams are used to send the same data (for example, password or HTTP cookies), the more information can be extracted from the traffic that helps to decrypt. Below we show how to combine an effective attack on CBC encryption using SSL 3.0 (provided that the attacker can modify the network exchange between the client and server). At the same time, unlike the BEAST and Lucky 13 vulnerabilities, there are no workarounds here. We only have the unsafe SSL 3.0 protocol, and to ensure strong encryption, you should avoid using it.
The most serious problem with CBC encryption in SSL 3.0 is that padding can be arbitrary (with the exception of the last byte), and MAC (Message Authentication Code) does not apply to it. The integrity of the add-on cannot be fully confirmed during decryption, since in SSL 3.0 the message is first signed using the MAC, then it is supplemented with padding, and after that it is encrypted with a block cipher. Padding from 1 to L bytes (where L is the block size in bytes) is used to obtain an integer number of blocks before encryption. It is easiest to break through protection if there is a whole block of padding, which (before encryption) consists of L-1 arbitrary bytes, followed by a single byte with a value of L-1. To process an incoming encrypted record C 1 ... C nwhen the initialization vector C0 is also given (where each C i is one block), the receiving side first determines P 1 ... P n as P i = D K (C i ) ⊕ C i-1 (D K stands for decryption of one block with session key K). Then the padding at the end of the message is verified and deleted, and finally the MAC signature is verified and deleted.
If the last block C n is entirely padding, and the attacker replaces C n with any earlier encrypted block C i from the same stream, the message will still be accepted, provided that D K (Ci ) ⊕ C n-1 has the last byte of L-1, otherwise it will probably be rejected, which makes it possible to conduct a Padding Oracle attack.
Outside of laboratory conditions, the weakness of SSL 3.0 can be exploited in MITM attacks when an attacker decrypts Secure HTTP cookies using the BEAST attack technique. To carry out a POODLE attack, you need:
- Run JS on www.evil.com so that the victim’s browser sends a cookie containing an HTTPS request to https://example.com
- Intercept and modify the SSL entry so that there is a good enough chance that example.com will accept the modified entry. If this happens, the attacker will be able to decrypt one byte from the cookie
Suppose that each block C contains 16 bytes - C  ... C . Also, let us know that the size of cookies has become known to us (below we show how to conduct an attack without knowing the size of cookies). The MAC size in SSL 3.0 is usually 20 bytes, so the “encrypted POST” under the CBC layer will look like this:
POST / path Cookie: name = value ... \ r \ n \ r \ n body ǁ 20 byte MAC ǁ padding
Attacker controls path and request body, and therefore can initiate requests that satisfy two conditions:
- Padding fills the entire block (encrypted in C n )
- The first, as yet unknown, cookie byte is substituted as the last in the earlier block (encrypted in C i )
Next, the attacker replaces C n with C i and redirects this modified record to the server.
Most often, the server does not accept it, and then the attacker sends a new request. Sometimes (approximately once per 256 attempts) the server accepts a modified record and the attacker concludes that D k (C i )  ⊕ C n-1  = 15, and therefore P i  = 15 ⊕ C n -1  ⊕ C i-1[fifteen]. This reveals the first byte of the cookie, previously unknown. The attacker moves on to the next byte, while simultaneously resizing the path and body of the request so that the size of the request does not change, but the location of the headers moves. This is done until the cookie is decrypted in its entirety. The expected total workload is 256 SSL 3.0 requests per byte.
Since padding hides the exact size of the payload, the size of the cookie does not immediately become apparent. But the requests GET /, GET / A, GET / AA, ... allow the attacker to calculate the boundaries of the blocks. A maximum of 16 such queries is enough to find out the size of the add-on, and therefore the size of the cookie.
RecommendationsThe above attack requires a connection via SSL 3.0, so disabling it in the client or on the server (or on both sides) allows you to completely avoid troubles. If at least one side supports only SSL 3.0, then medicine is powerless, and a serious update is necessary to avoid insecure encryption. If SSL 3.0 is not the only supported protocol and it is not disabled, then an attack is possible with a downgrade dance (switching the client to lower versions for the sake of compatibility with the server).
Disabling SSL 3.0 may not be practical if you need to work periodically with older systems. The TLS_FALLBACK_SCSV mechanism solves a common problem for different versions of the protocol, and we believe that this is especially critical for systems supporting compatibility with SSL 3.0. The following describes the operation of TLS_FALLBACK_SCSV.
TLS clients using downgrade dance must include the value 0x56, 0x00 in ClientHello.cipher_suites during each downgrade protocol version. This value serves as a signal due to which updated servers can refuse to establish a connection in the event of a downgrade attack. Clients should always upgrade to the next lower version (for example, if you started with TLS 1.2, then try on TLS 1.1, then on TLS 1.0, then SSL 3.0). In the case of TLS_FALLBACK_SCSV, skipping the version can also prevent a successful connection.
TLS servers, when 0x56, 0x00 in ClientHello.cipher_suites are encountered in the incoming connection, compare ClientHello.cipher_version with the highest protocol version supported by the server. If the server supports a higher version than the client, then the connection breaks with an error.
Such use of TLS_FALLBACK_SCSV gives confidence that SSL 3.0 will be used only when working with older systems: attackers can no longer initiate a downgrade of the protocol. If both sides allow SSL 3.0, but one of them does not support TLS_FALLBACK_SCSV, then an attack is still possible.
List of references
- [BEAST] T. Duong, J. Rizzo: “ Here Come The ⊕ Ninjas, ” 2011.
- [draft-ietf-tls-downgrade-scsv-00] B. Möller, A. Langley: “TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”, Internet-Draft draft-ietf-tls-downgrade-scsv -00 , 2014.
- [Lucky13] NJ AlFardan, KG Paterson: “ Lucky Thirteen: Breaking the TLS and DTLS Record Protocols ”, IEEE Symposium on Security and Privacy, 2013.
- [RC4biases] NJ AlFardan, DJ Bernstein, KG Paterson, B. Poettering, JCN Schuldt: “ On the Security of RC4 in TLS and WPA ”, USENIX Security Symposium, 2013.
- [RFC2246] T. Dierks, C. Allen: “The TLS Protocol Version 1.0,” RFC2246 , 1998.
- [RFC4346] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.1,” RFC4346 , 2006.
- [RFC5246] T. Dierks, E. Rescorla: “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC5246 , 2008.
- [RFC6101] A. Freier, P. Karlton, P. Kocher: “The Secure Sockets Layer (SSL) Protocol Version 3.0”, RFC6101 , 1996 (published as Historic RFC in 2011).
- [tlscbc] B. Möller: “Security of CBC Ciphersuites in SSL / TLS: Problems and Countermeasures”, http://www.openssl.org/~bodo/tlscbc.txt , 2004.