The POODLE attack (Padding Oracle on Downgraded Legacy Encryption) exploits a vulnerability in the SSL 3.0 protocol (CVE-2014-3566). This vulnerability lets an attacker eavesdrop on communication encrypted using SSLv3. The vulnerability is no longer present in the Transport Layer Security protocol (TLS), which is the successor to SSL (Secure Socket Layer).

The recent Acunetix 2020 Web Application Vulnerability Report shows that as many as 3.9% of web servers are still vulnerable to POODLE, which means they still support the SSL 3.0 protocol, despite the fact that the TLS protocol was introduced in 1999. Even more (over 30%) servers are vulnerable to the BEAST attack because they support TLS 1.0.

Why do web servers support old protocols? Perhaps the administrators of those servers wanted to make sure that users can access them using very old browsers. However, we suspect that it’s more likely that such servers use very old server software with very old configurations.

What Can an Attacker Do with POODLE?
The POODLE vulnerability lets the attacker eavesdrop on encrypted communication. This means that the attacker can steal confidential data that is transmitted, for example, passwords or session cookies, and then impersonate the user. This can have very serious consequences, including losing control over the web application (for example, if the attacker impersonates an admin).

The attack is not very easy because it needs to be successful in three stages:

In the first stage, the attacker must perform a successful man-in-the-middle attack (MITM). The attacker can now listen to all communication between the client and the server as well as add to this communication (impersonate the client or the server). However, if this is a secure connection, communication is encrypted using SSL/TLS, so the attacker cannot understand what is being sent.
In the second stage, the attacker must convince the server to use the old SSL 3.0 protocol. The attacker can do this by dropping connections – after a number of such drop-outs, the server will try an older protocol, thinking that the client cannot use a newer protocol such as TLS 1.2. This is called a protocol downgrade attack or downgrade dance.
In the third stage, when the client and the server are communicating using SSL 3.0, the attacker can use the POODLE attack to decrypt selected parts of the communication and steal confidential information.
To make sure that the POODLE attack succeeds, the attacker should also be able to trick the user browser into running JavaScript, for example, using social engineering.
How Does POODLE Work?
The POODLE attack is possible due to several features of the SSL/TLS protocol. You can read more about how these protocols work in our article series on SSL/TLS. For now, all you need to know is that SSL/TLS lets the server and the browser use sets of different algorithms to encrypt communication – these are called cipher suites.

The POODLE vulnerability affects cipher suites that include symmetric encryption together with block ciphers, for example, AES or DES algorithms. In such cases, the client and the server first agree on a secret key using asymmetric encryption (a private key and a public key). Then, all communication is encrypted symmetrically using this key. In the case of block ciphers, data is encrypted in blocks of fixed length, for example, 8 bytes or 16 bytes.

Cipher suites that are vulnerable to POODLE also use cipher-block chaining (CBC mode). This means that the value of each block depends on the value of the previous block – it is calculated by using the logical operation XOR. Also, a random data block is added at the start – this is called an initialization vector. This is necessary so that every time data is encrypted, it looks different (and therefore the attacker cannot figure out the data based on similarities).

What Is MAC-Then-Encrypt?
To understand POODLE, you must first understand MAC and MAC-then-Encrypt.

The SSL/TLS protocol not only guarantees that the data is confidential. It also guarantees that the data has not been tampered with. For example, you do not want someone to be able to inject their own account number when you try to transfer money between accounts in an online bank.

To guarantee that the data is not corrupt, every encrypted fragment of data has a checksum – a MAC (message authentication code). The MAC can only be calculated if you have the encryption key. If the MAC is wrong, it means that someone has tampered with the message.

The SSL 3.0 protocol uses the MAC-then-Encrypt approach. This means that first, the algorithm calculates the MAC value, then it adds that MAC value at the end of the data, and then it encrypts the whole thing, including padding.

What Is Padding?
A block cipher needs all data to be a multiple of the block size. For example, if the block size is 8, data must have 64, 80, or 336 bytes (a multiple of 8). If it is not a multiple of 8, it needs to be padded with unimportant data just to reach the right length.

Most web server implementations use the following padding technique:

The last byte of the last block must always contain the padding length. That value represents the number of previous bytes that are padded. For example, if 4 bytes are padded, the value of the block is: xx-xx-xx-yy-yy-yy-yy-04 (yy represents padding). This is an SSL requirement.
In most implementations, the values of all padding bytes are the same as the length value. For example, if 4 out of 8 bytes are padded, the value of the block is: xx-xx-xx-04-04-04-04-04.
If the length of the data is a multiple of the block size, for example, 336, there must be an extra block added with only padding: 07-07-07-07-07-07-07-07. This is necessary because if the last byte did not represent padding, the algorithm cannot recognize padding from real data.
Note that SSL does not check padding bytes (except the padding length), so as long as the last byte is between 00 and 07, the block will be accepted. For example, an xx-xx-xx-12-34-56-78-04 block will be accepted.

What Is a Padding Oracle?
The padding oracle is a situation when the attacker knows or can guess why the data that they sent to the server is rejected: whether it is because the padding was incorrect or whether the MAC was wrong.

Imagine the following situation:

The attacker receives data from the browser and knows that this data contains a password. The attacker knows that this is an HTTP POST request and knows exactly where the password is located in this request.
The attacker modifies the encrypted data and sends it to the server.
The server responds to the attacker saying that the data is wrong. However, it can respond with two types of errors: it may tell the attacker that the padding was wrong or that the MAC was wrong. This makes the POODLE attack possible.
Padding oracles are used for other attacks, too. Some protocols don’t respond directly but may, for example, first check the padding and only later check the MAC. In those cases, if the attacker gets a quick response, it’s a padding error, but if the response takes a bit longer, it’s a MAC error.

The Anatomy of the POODLE Attack
To perform a typical POODLE attack and steal a web session cookie, the attacker does the following:

The attacker tricks the victim’s browser into running JavaScript code that lets the attacker perform the attack.
The attacker’s JavaScript code tricks the user browser into sending multiple legitimate requests to the server. These requests include the session cookie.
The JavaScript code modifies the connection URL (adding extra characters) so that the length of the data sent to the server is a multiple of the block size (for example, 8). This means that the last block will contain only padding (see the explanation above).
The attacker knows which blocks of data contain the session cookie. For example, the data may have 10 blocks and the attacker knows that the third and fourth blocks contain the session cookie value.
The attacker copies the entire third block to the last block and sends it to the server many times, changing something in the connection URL every time so that the MAC is different.
After at most 256 times, the message will be accepted. This means that the last byte of the third block, after decryption, will be the number 07, which signifies correct padding.
Now the attacker knows the decrypted last byte and they can combine it with previous blocks using XOR operations to obtain the real last byte of the third block.
The attacker can then make the connection URL one byte longer and repeat the steps above to get the next piece of the cookie. And then repeat again for the fourth block of data.
If the cookie length is 16, the attacker will know the cookie after no more than 4096 requests, which takes at most a few minutes.
How to Know if Your Web Server Is Vulnerable to POODLE
To know if your web server is vulnerable to POODLE, you only need to know if it supports SSL 3.0. You can find out if your web server supports SSL 3.0 using Acunetix. You can also do it manually, but with Acunetix you can also find web vulnerabilities and much more.

There were also old implementations of the TLS protocol that were vulnerable to POODLE. However, all modern TLS implementations are safe.

Note that while POODLE is a network vulnerability, it also affects web servers and web browsers.

How to Fix the POODLE Vulnerability
To protect your server against POODLE and BEAST, configure it to support only TLS 1.2 and no older protocols. All older SSL and TLS versions are now officially deprecated and all modern browsers such as Chrome, Firefox, and Internet Explorer support TLS 1.2.

Apache Web Server
Edit the SSLProtocol directive in the ssl.conf file, which is usually located in /etc/httpd/conf.d/ssl.conf. For example, if you have:

SSLProtocol all
change it to:

SSLProtocol TLSv1.2
Then, restart httpd.

NGINX
Edit the ssl_protocols directive in the nginx.conf file. For example, if you have:

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
change it to:

ssl_protocols TLSv1.2;
Then, restart nginx.

Microsoft IIS
To disable TLS 1.0 in Microsoft IIS, you must edit the registry settings in Microsoft Windows.

Open the registry editor
Find the key HKLM SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server
Change the DWORD value of the Enabled entry to 0.
Create a DisabledByDefault entry and change the DWORD value to 1.
Repeat the above steps for all versions of SSL and for TLS 1.1.