End of SSL with POODLE

In this article we will learn about the how SSL has reaches its end with various vulnerabilities. This article will also cover the recent vulnerability discovered by Google researchers and is termed as a POODLE attack.

Introduction

Secure Socket Layer (SSL) protocol was discovered to provide secure transmission between two parties. This protocol became industry standard and was widely adopted by Vendors in their products to give a secure channel for data transmission. However from time to time this various vulnerabilities like Man in the middle attack (MITM), POODLE attack etc. was discovered in SSL protocol resulting in different versions of this protocol termed as 1.0, 2.0, and 3.0. Due to this a new standard has been developed named as TLS and it also has its various version namely TLS 1.0, TLS 1.1, TLS 1.2. Since SSL was widely adopted so it would not have been economical to replace all SSL products with TLS. Thus TLS have been made backward compatible with SSL to provide smooth user experience.

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

Even if both client and server are TLS compatible, many clients offer a protocol downgrade dance to avoid any interoperability bugs. Due to this behavior a new Vulnerability termed as POODLE (Padding Oracle on Downgraded Legacy Encryption) was discovered Due to this vulnerability attacker can steal bearer tokens such as HTTP cookies. This vulnerability is covered in the next section.

What is POODLE attack

As is stated above, many TLS clients offer a protocol downgrade dance to avoid any interoperability bugs. This means that whenever a handshake starts, highest protocol version supported by client is presented. If server is not compatible with the protocol version presented by client, then handshake fails and later the handshake is successful by server informing the best TLS/SSL version it can support. Here is the point. If the network between client and server is controlled by an attacker then it can impersonate for both entities and can cause the connection to fall back to SSL 3.0. So the initial vector for this attack is the protocol downgrade dance supported by clients.

Once the channel between the entities is moved down to SSL 3.0 then this vulnerability can be exploited. Vulnerability exploited is the known Oracle Padding attack. Since SSL authenticate before encryption, this design flaw in SSL has made this vulnerability possible. Oracle padding attack is done against the CBC mode ciphers in the SSLv3.

Below diagram shows the process through which CBC works. As we can see the encryption in this attack is sequential and not parallelized which is also the disadvantage of CBC mode.

Source: Wikipedia 1

Now since for PADDLE attack we have to assume that attacker has full control over the network between client and servers, so the attacker can only see the cipher text blocks but what if the attacker picks up the block which contains important information like cookies and XOR it with the previous cipher text block (Remember the attacker can see the cipher text since he has control over the network).

Now CBC modes works in blocks and the last block is usually padded so that decryption is error free. HTTPS connections are accepted by servers once it verifies the data integrity but in SSLv3, since the cipher padding is not deterministic thus the integrity of padding cannot be verified since it is not covered by the Message Authentication Code (MAC). During CBC decryption, the last byte which is padding byte contains a number between 0 to 7 which states that how many bytes are added for padding. Thus the recipient removes those numbers of bytes and ignores their contents.

Attackers can create a JavaScript to send crafted requests so that last byte is the cookie byte. To understand this let's suppose that the c0,c1..c7 are the last 8 cookie bytes. Now since the attacker has control over the network he can see the ciphertext which we can assume to be p0,p1…p7 in this case, Thus the encryption will work like c0-XOR-p0,c1-XOR-p1 and so on. Attacker can replace the last encrypted byte which is a padding byte with c7 and XOR it with p7.Then the resulting content is XOR with padding byte. If the result is 7 then the message is intact and clear text can be obtained. This has a probability of 1 in 256. So to decrypt 'n' bytes of plaintext an average number of 256*n requests have to be made so as to be accepted by the server.

TLS 1.0 is not vulnerable because TLS requires that all padding bytes must have the same value.

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

What to do now?

Since many legacy servers still use SSLv3, the severity of this attack is critical. So below steps can be followed to handle this vulnerability

• FOR SSL clients and servers: If you want to completely avoid it then disable SSLv3 usage and upgrade to TLS patched versions.
• FOR TLS clients and servers: TLS clients that do protocol downgrade dance should include the TLS_FALLBACK_SCSV in ClientHello.cipher_suites in any fallback handshakes. This value will indicate that a possible downgrade attack is underway and the connection will be refused. TLS on seeing TLS_FALLBACK_SCSV in ClientHello.cipher_suites will check the SSL/TLS version stated by client and if TLS server has a highest version then that connection will be terminated. Thus using this mechanism other than a needy SSL implementation, downgrade dance can be avoided.

References

• https://www.openssl.org/~bodo/ssl-poodle.pdf