POODLE & BEAST

Some attacks target the implementation of padding in TLS specifically. These attacks include Padding Oracle On Downgraded Legacy Encryption (POODLE) and Browser Exploit Against SSL/TLS (BEAST).

---

Padding in SSL 3.0

POODLE and BEAST are two padding oracle attacks that target encrypted data transmitted in SSL 3.0. Successfully exploiting these attacks allows an attacker to decrypt network traffic to compromise confidential data such as credentials. However, to do so an attacker needs to intercept ciphertexts and needs to be able to communicate with the target server.

The padding scheme used in SSL 3.0 is as follows:

• the last byte is the length of the padding (excluding the length itself)
• all padding bytes can have an arbitrary value

As an example, let's assume we are using an 8-byte block length and our plaintext is the 4 bytes DE AD BE EF. That means we require 4 bytes of padding. The last byte is the length of the padding excluding the length itself, so it has to be 03. The remaining padding bytes can be arbitrary, so the byte stream DE AD BE EF 00 00 00 03 is correctly padded.

---

POODLE Attack

The POODLE attack was discovered in 2014 and completely broke SSL 3.0. To exploit it, an attacker forces the victim to send a specifically crafted request that contains a full block of padding. This means that the attacker already knows the last byte of the padding block as it is the size of the padding. The attacker intercepts the ciphertext and changes data in the last block. If this results in a different padding size, the web server interprets data differently, resulting in a MAC error, since SSL 3.0 uses a MAC to provide integrity protection. However, if the padding size remains correct, the webserver computes the MAC correctly and no MAC error is thrown. Just like in a textbook padding oracle attack, this leaks an intermediary result of the CBC-mode to the attacker, enabling him to compute a byte of the plaintext. Applying this attack recursively allows for the decryption of entire ciphertext blocks.

This vulnerability is the result of the fact that padding bytes can be arbitrary except for the length field, as well as the fact that the webserver displays different behavior for an incorrect padding length. In particular, the web server throws a MAC error as the MAC is incorrect if the padding length is incorrect.

---

BEAST Attack

The BEAST attack discovered in 2011 works similarly. The attacker intercepts a correct ciphertext and then sends a crafted ciphertext to the target server. This allows the attacker to deduce information about a plaintext block. However, depending on the block size, a block might be sufficiently large to make a brute-force attack on a whole block infeasible. Thus, BEAST additionally relies on a technique that changes the original plaintext slightly by injecting additional characters to ensure that only one byte in the resulting plaintext block is unknown. This allows the attacker to brute-force the plaintext byte by byte.

However, BEAST is a theoretical attack due to the nature of its exploitation. Exploiting it in practice is rather difficult. That is because BEAST needs to bypass the same-origin policy that modern web browsers implement to work properly. It therefore requires a separate attack, a same-origin policy bypass, for practical exploitation, making the risk of a real-world attack small.

---

Tools & Prevention

We can use the tool TLS-Breaker to execute a POODLE attack if a target web server supports SSL 3.0. TLS-Breaker is a collection of exploits for a variety of TLS attacks. It requires Java to run. We can install it using the following commands:

[!bash!]$ sudo apt install maven
[!bash!]$ git clone https://github.com/tls-attacker/TLS-Breaker
[!bash!]$ cd TLS-Breaker/
[!bash!]$ mvn clean install -DskipTests=true

We can then run the POODLE detection tool like so:

[!bash!]$ java -jar apps/poodle-1.0.0.jar -h

Let's have a look at an example of a web server vulnerable to POODLE. We can specify the IP and port using the -connect flag:

[!bash!]$ java -jar apps/poodle-1.0.0.jar -connect 127.0.0.1:30001
 Server started on port 8001
23:14:08 [main] INFO : ClientTcpTransportHandler - Connection established from ports 41918 -> 30001
23:14:09 [main] INFO : WorkflowExecutor - Connecting to 127.0.0.1:30001
23:14:09 [main] INFO : ClientTcpTransportHandler - Connection established from ports 41952 -> 30001
23:14:09 [main] INFO : SendAction - Sending messages (127.0.0.1:30001): CLIENT_HELLO, 
23:14:09 [main] INFO : ReceiveAction - Received Messages (127.0.0.1:30001): SERVER_HELLO, CERTIFICATE, SERVER_HELLO_DONE, 
23:14:09 [main] INFO : Attacker - Vulnerability status: VULNERABILITY_POSSIBLE

On the other hand, if a web server is not vulnerable, we get the following output:

[!bash!]$ java -jar apps/poodle-1.0.0.jar -connect 127.0.0.1:443
 Server started on port 8001
23:15:48 [main] INFO : ClientTcpTransportHandler - Connection established from ports 53412 -> 443
23:15:48 [main] INFO : WorkflowExecutor - Connecting to 127.0.0.1:443
23:15:48 [main] INFO : ClientTcpTransportHandler - Connection established from ports 53414 -> 443
23:15:48 [main] INFO : SendAction - Sending messages (127.0.0.1:443): CLIENT_HELLO, 
23:15:48 [main] INFO : ReceiveAction - Received Messages (127.0.0.1:443): Alert(FATAL,HANDSHAKE_FAILURE), 
23:15:48 [main] INFO : Attacker - Vulnerability status: NOT_VULNERABLE

For more details on how to exploit a POODLE attack, check out the wiki of the TLS-Breaker project here.

Prevention

POODLE can be prevented by disabling the use of SSL 3.0 entirely. Even if a web server supports newer TLS versions, a client might be able to force the use of SSL 3.0 by manipulating handshake messages. Therefore, SSL 3.0 should be completely disabled and not be supported even for legacy reasons.

For instance, disabling SSL 3.0 in the Apache2 web server can be achieved using the following directive:

SSLProtocol all -SSlv3