Discovering the SSLv3 POODLE Vulnerability in Linux

1. Overview

In this tutorial, we’ll look at the SSLv3 POODLE security vulnerability. This flaw allows attackers to exploit the SSLv3 protocol and obtain sensitive information. We’ll discuss what it is and how the attack takes place, and lastly, we’ll look at how to protect our systems from it.

2. The POODLE Vulnerability in Details

POODLE (Padding Oracle On Downgraded Legacy Encryption) is a vulnerability affecting older encryption standards, specifically Secure Socket Layer (SSL) version 3. It allows a man-in-the-middle attacker to decrypt ciphertext using a padding Oracle side-channel attack when exploited.

2.1. How the Attack Works

Let’s look at the components of the attack to understand how it works (Padding and Padding Oracle).

Cryptographic algorithms ensure that the data being encrypted fits into fixed-length blocks. For example, in block ciphers or symmetric encryption modes like CBC (Cipher Block Chaining), all data should have a fixed-length block. These block sizes vary, and they should always be a multiple of 8. If the data is not a multiple of 8, it must be padded with unimportant data until it reaches the right length.

Padding Oracle is a system that can detect and report whether the padding used in decryption is correct or not. This mechanism allows an attacker to know or guess why the data sent to the server is rejected (Padding Oracle attack). The attacker modifies encrypted data and resends it. The server will respond with an error message indicating that either the padding or message authentication code (MAC) is incorrect. Thus, they can modify and resend again.

2.2. Stages of the Attack

For the attack to be successful, the following three stages must be completed successfully since they are interdependent.

In the first stage, the attacker must initiate a man-in-the-middle attack. This attack must be successful since it allows the attacker to monitor all communication between the client and the server. Additionally, the attacker can also impersonate the client or the server.

Following this, the attacker must trick the server into using the SSL 3.0 protocol. This is possible through the downgrade attack or downgrade dance, where an attacker drops connections until the server tries a different protocol (in this case, SSL v3).

Lastly, since the client and server are now communicating through SSL 3.0, the attacker utilizes the POODLE attack and uses it to decrypt parts of the communication. After that, he can access confidential information being shared ( this means either the intercepted client’s or server’s session and view the information in unencrypted data).

2.3. The Impact of the Attack

A successful attack can result in the theft of confidential data, such as passwords and session cookies, which then leads to the impersonation of the actual user. This can have very serious effects, including legitimate users of an application being locked out, denied services or even deleted.

3. How to Discover POODLE Attack

Now, let’s look at how we can detect if this vulnerability affects our systems (both clients and servers). We’ll use Nmap and openssl to find out if the vulnerability exists.

Firstly, to test a server or a client, we’ll need its IP address or domain name and a port:

$ nmap -sV --script ssl-poodle -p 443 sonosa.or.kr          
Nmap scan report for sonosa.or.kr (210.113.47.112)
Host is up (0.45s latency).
PORT    STATE SERVICE   VERSION
443/tcp open  ssl/https
| ssl-poodle: 
|   VULNERABLE:
|   SSL POODLE information leak
|     State: VULNERABLE
|     IDs:  BID:70574  CVE:CVE-2014-3566
|           The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other
|           products, uses nondeterministic CBC padding, which makes it easier
|           for man-in-the-middle attackers to obtain cleartext data via a
|           padding-oracle attack, aka the "POODLE" issue.
|     Disclosure date: 2014-10-14
|     Check results:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Nmap done: 1 IP address (1 host up) scanned in 183.90 seconds

Nmap establishes a secure connection and determines whether the server/client supports CBC ciphers over SSLv3 using the script. If it does, then it’s vulnerable.

Secondly, let’s look at how we use the openssl command to test for POODLE. OpenSSL is a cryptography toolkit implementing SSL (v2/v3) and TLS (v1) protocols and their related cryptography.

Let’s run the openssl against a target:

$ openssl s_client -connect sonosa.or.kr:443       
CONNECTED(00000003)
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: EDF0A3BE58CA64C03165DB3028290414E081225F392085498B7CE294FE751168
    Session-ID-ctx:

If the server is vulnerable to POODLE, the command will result in a successful SSLv3 handshake. After that, it will connect. However, if the server does not support SSLv3 or is properly configured to mitigate POODLE, the command will produce an error or display information indicating that the connection has been refused or terminated.

4. Securing Against POODLE Attack

To protect our systems from the POODLE attack, we must configure our computers not to run SSL v1.3. Further, we shouldn’t use any older versions of SSL or TLS since they are deprecated, and some of them are vulnerable to POODLE. The best way to protect our systems is to disable SSLv3.

Now, let’s look at the various ways we can disable SSLv3 in our systems.

Firstly, for systems running Apache, we need to edit the configuration file located in /etc/apache2/mods-available/ssl.conf:

$ sudo vi /etc/apache2/mods-available/ssl.conf 
SSLProtocol TLSv1.2

This line disables sslv3 by only allowing TLSV1.2 (often, it is set to all, i.e., SSLProtocol all). Alternatively, we can allow all other versions except sslv3 by using this option:

SSLProtocol all -SSLv3

On the other hand, for systems running NGINX, we need to edit the /etc/nginx/nginx.conf file. Let’s find the following line:

$ sudo vi /etc/nginx/nginx.conf
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE

To disable SSLv3, we need to remove it from the list:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

Likewise, we can explicitly define the protocol we want in use or just disable the SSLv3 and leave the other versions:

ssl_protocols TLSv1.2 ;

If we’re running tomcat, we need to find this line in the server.xml connector and remove SSLv3:

sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2"

After making the above changes, we must ensure that we restart the server service.

We should note that disabling SSLv3 may result in compatibility and performance issues. Compatibility issues may arise since some older systems do not support the latest protocols like TLS.

Additionally, on the server side, we can mitigate this attack by implementing secure padding schemes, handling error messages properly to prevent information leakage, and avoiding timing disparities in server responses.

5. Conclusion

In this tutorial, we’ve discussed the SSLV3 POODLE vulnerability. Firstly, we looked at the POODLE attack and how it’s exploited by attackers. Following, we looked at how we can discover this vulnerability in our systems using the Nmap and openssl tools. Lastly, we looked at the various ways we can protect our systems from this attack.