Geekly Articles each Day
📜 ⬆️ ⬇️

This poodle bites: using SSL 3.0 holes



Interested in web security habrazhiteli already aware of another vulnerability in SSL, called POODLE. We will take a closer look at what this vulnerability is and exactly how an attacker can get to seemingly protected user data, and also describe how the Mail.Ru Group team dealt with this beast.

An exhaustive explanation of the mechanism of using POODLE is given in the article This POODLE Bites: Exploiting The SSL 3.0 Fallback ; Below is a translation of this article.

For those who are not too interested in the details of the activity of a malicious dog, we recall that POODLE is a vulnerability in SSL 3, the old version of the protocol, which survives the second dozen. There are two ways to deal with a vulnerability:

Our statistics show that through IE6, 0.2% of users log into Mail.Ru. And, although in absolute terms it is not such a small figure, we believe that safety is first and foremost. Therefore, we have disabled the ability to connect with the client via SSL3 in Mail, Cloud, Calendar, authorization center and Mail.Ru for Business.
')
For IE6 users, this means Mail.Ru Mail, as well as other services that have chosen this method of dealing with POODLE, will no longer be available to them. It is unlikely that there are many IE6 supporters among Habr's 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 have chosen the first way to protect against a vulnerability, 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 exactly then? This can be learned from the translation below.

SSL 3.0 [RFC6101] is an outdated and insecure protocol. When solving most practical tasks, it has already been replaced by successors, the TLS 1.0 [RFC2246], TLS 1.1 [RFC4346] and TLS 1.2 [RFC5246] protocols, but they maintain backward compatibility with SSL 3.0 for interoperability with older systems. This allows you to avoid problems with client devices when introducing new versions of protocols on servers.

But even if both the client and the server support TLS, the security level in SSL 3.0 is still an issue, as 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 hack the SSL 3.0 protocol. It will be about POODLE- attack (Padding Oracle On Downgraded Legacy Encryption), through which you can, for example, intercept a Secure HTTP-cookie or the contents of HTTP-authorization headers.

We will also recommend what measures need to be taken on clients and servers to counter such an attack. If simply turning off SSL 3.0 does not suit you for compatibility reasons, then in the existing versions of TLS you need to use TLS_FALLBACK_SCSV.

Description of the POODLE vulnerability

For compatibility with older versions of servers, many TLS clients use downgrade dance: first, an attempt is made to establish a connection using the latest version protocol. If the connection is not established, a new attempt is made, but under the older protocol. Unlike the normal version determination procedure supported by both parties (for example, a client accesses TLS 1.2 and the server responds with TLS 1.0), the above scheme can be triggered due to network errors or malicious actions. If the attackers who control the network between the client and the server interfere and prevent from establishing a connection with the TLS version 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 with RC4 is the presence of offsets: the more connections and encryption streams are used to send the same data (for example, a password or an HTTP cookie), the more information can be extracted from the traffic, which helps decrypt. Below it will be shown how to combine an effective attack on CBC encryption using SSL 3.0 (provided that an attacker can modify the network exchange between the client and the server). At the same time, unlike the vulnerabilities of BEAST and Lucky 13, there are no workarounds. We only have insecure SSL 3.0 protocol, and to ensure strong encryption, we should avoid using it.

The most serious problem of CBC-encryption in SSL 3.0 is that the addition of blocks (padding) can be arbitrary (except for the last byte), it is not covered by the MAC (Message Authentication Code). The integrity of the add-on cannot be fully confirmed during the decryption, since in SSL 3.0 the message is first signed with the MAC, then padding complemented, 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 the protection if there is a whole padding block that (before encryption) consists of L-1 arbitrary bytes, followed by a single byte with the value L-1. To process the incoming encrypted entry C 1 ... C n , when the initialization vector C0 is also given (where each C i is one block), the receiving party first determines P 1 ... P n as P i = D K (C i ) ⊕ C i- 1 (D K denotes decryption of a single block using the session key K). Then the padding is checked and removed at the end of the message, and finally the MAC signature is checked and deleted.

If the last C n block is entirely padding, and the attacker replaces C n with any earlier encrypted C i block from the same stream, the message will still be accepted, provided that D K (C i ) C n-1 has the last byte is L-1, otherwise it will probably be rejected, which makes it possible to carry out an attack on the Padding Oracle.

Outside the lab, SSL 3.0 weakness can be used in MITM attacks when an attacker decrypts Secure HTTP cookies using the BEAST attack technique. To implement a POODLE attack, you need:

Suppose that each C block contains 16 bytes - C [0] ... C [15]. We also assume that the size of the cookie has become known to us (we will show below how to launch an attack without knowing the size of the cookie). The MAC size in SSL 3.0 is usually 20 bytes, so that “under a layer” of a CBC encrypted POST will look like this:

POST / path Cookie: name = value ... \ r \ n \ r \ n body ǁ 20 byte MAC padding

The attacker controls the path and the body of the request, and therefore can initiate requests that satisfy two conditions:

Next, the attacker replaces C n with C i and redirects this modified entry 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 ) [15] ⊕ C n-1 [15] = 15, and therefore P i [15] = 15 ⊕ C n -1 [15] ⊕ C i-1 [15]. This reveals the first byte of the cookie, previously unknown. The attacker proceeds to the next byte, 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 has been deciphered entirely. The expected total effort is 256 SSL 3.0 requests per byte.

Since the padding hides the exact size of the useful content, the size of the cookie does not immediately become apparent. But GET /, GET / A, GET / AA, ... queries allow an attacker to calculate block boundaries. A maximum of 16 such requests is enough to find out the size of the add-on, and therefore the size of the cookie.

Recommendations

The above attack requires SSL 3.0 connection, so disabling it on the client or on the server (or on both sides) allows you to completely avoid trouble. If at least one side supports only SSL 3.0, then medicine is powerless here, and a serious update is needed to avoid unsafe encryption. If SSL 3.0 is not the only supported protocol and it is not disabled, then the attack is possible with downgrade dance (switching the client to lower versions for compatibility with the server).

Disabling SSL 3.0 may be impractical if you need to periodically work with older systems. The TLS_FALLBACK_SCSV mechanism solves a common problem for different protocol versions, and we believe that this is especially critical for systems that support SSL 3.0 compatibility. The following explains the algorithm of TLS_FALLBACK_SCSV.

TLS clients using downgrade dance should include the value 0x56, 0x00 in ClientHello.cipher_suites during each downgrade of the protocol version. This value serves as a signal due to which the 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 started with TLS 1.2, then try TLS 1.1, then TLS 1.0, then SSL 3.0). In the case of TLS_FALLBACK_SCSV, skipping a version can also prevent a successful connection.

TLS servers, when an incoming connection encounters 0x56, 0x00 in ClientHello.cipher_suites, 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 is terminated with an error.

This use of TLS_FALLBACK_SCSV makes sure 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 the attack is still possible.

Bibliography

Source: https://habr.com/ru/post/241113/

More articles:


All Articles