4

The SSL 3.0 Vulnerability – POODLE Bug (AKA POODLEbleed)

Created on Oct 15 2014, 5:52 PM by Brook Chelmo

SSLv3_poodle-300px.png

A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).

(Updated Dec. 9, 2014) Recently, a new variant of the POODLE vulnerability (CVE-2014-8730) was found to affect even versions of TLS, the successor to the SSL protocol.  This new vulnerability works against sites that use load balancers that have incorrectly implemented encryption padding checks, and may affect around 10% of servers.  Certain models of F5 and A10 load balancers are susceptible, and as part of best practices we recommend that users apply vendor-supplied patches as they become available.

It is important to note that this is NOT a flaw in SSL certificates, their private keys, or their design but in the old SSLv3 protocol.  SSL Certificates are not affected and customers with certificates on servers supporting SSL 3.0 do not need to replace them.

It’s believed to not be as serious as the Heartbleed bug in OpenSSL, since the attacker needs to have a privileged position in the network to exploit the latest.  The usage of Hotspots, public Wi-Fi, makes this attack a real problem. This type of attack falls into the “Man-in-the-middle” category. 

Background

While SSL 3.0 was introduced in 1996, it is currently supported by nearly 95% of Web browsers according to Netcraft’s latest report.  Many Transport Layer Socket (TLS) clients downgrade their cryptography protocol to SSL 3.0 when working with legacy servers. According to Google, an attacker that controls the network between the computer and server could interfere with the handshake process used to verify which cryptography protocol the server can accept using a “protocol downgrade dance”. This will force computers to use the older SSL 3.0 protocol to protect data that is being sent. Attackers can then exploit the bug by carrying out a man-in-the-middle (MITM) attack to decrypt secure HTTP cookies, which could let them steal information or take control of the victim’s online accounts.  Although, at the time to writing, webmasters have been disabling SSL 3.0 and moving to TLSv1 and above at a rapid pace, there still remains a lot of work to be done.  If Heartbleed taught us anything, it’s that the largest companies act fast while many small companies drag their heels in patching critical vulnerabilities. 

What Businesses Need to Do

In order to mitigate the bug there are a few courses of action:

  1. Check to see if your webservers are vulnerable using our free SSL Toolbox.
  2. Disable SSL 3.0 altogether, or disable SSL 3.0 CBC-mode ciphers
  3. A cloud-based Web Application Firewall can help protect against this kind of vulnerability.  For more information please visit our website.
  4. Be leery of any spam messages from scammers trying to capitalize on uncertainty and a lack of technical knowledge.
  5. If applicable, implement F5’s patch.  For information on A10 Networks, please click here for their patch.

My fellow colleague Christoffer Olausson gives a few tips on how to fix this on Apache:

> SSLProtocol All -SSLv2 -SSLv3                   <- Removes SSLv2 and SSLv3

> apachectl configtest                                   <- Test your configuration

> sudo service apache restart                      <- Restart server

At the time of writing Google and Mozilla have either removed SSL 3.0 support from their browsers or are in the process of doing so.

What End-Users Need to Do

For end-users accessing websites Symantec recommends:

  1. Check to see if SSL 3.0 is disabled on your browser (for example, in Internet Explorer it is under Internet Options, Advanced Settings).
  2. Avoid MITM attacks by making sure “HTTPS” is always on the websites you visit.
  3. Monitor any notices from the vendors you use regarding recommendations to update software or passwords.
  4. Avoid potential phishing emails from attackers asking you to update your password – to avoid going to an impersonated website, stick with the official site domain.

More Information

Symantec has published knowledge base articles on the subject for your reference.  See below:

Symantec Managed PKI for SSL Users

https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=AR2182

Symantec Trust Center/Trust Center Enterprise Users

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR2183

Stay Connected

Stay connected with us for more updates on this vulnerability and others.  Follow us on Twitter, Facebook, or visit our technical forums for issues with managing SSL and code-signing certificates.

  • POODLEbleed
  • SSLv3
  • Poodle bug
  • Products
  • bug
  • website security solutions
  • SSL
  • POODLE Attack
  • SSL 3.0
  • DigiCert Complete Website Security
  • DigiCert SSL TLS Certificates
  • vulnerability
  • Products and Solutions
  • POODLE

Comments

  • 0

    Is there any detection signatures for this yet?

  • 0

    Dear lspells,

    Thank you very much for the ssl3_check_scripts toolkit. We used it to scan our network ranges and it was very useful. Great work :-)

    However, I have a small question/remark about it: when performing a scan, the script is testing the ciphers using the following command (e.g. for DES-CBC3-SHA):

    openssl s_client -cipher "DES-CBC3-SHA" -connect <server-name>:443

    On a web server with SSLv3 DISABLED, this particular command sometimes reports the connection to be successful, because the client and the server are negotiating the following SSL parameters:

    SSL-Session:
        Protocol  : TLSv1
        Cipher    : DES-CBC3-SHA

    In this case, your script does not care about the protocol used (TLSv1) and reports the host to be vulnerable. My question is: why aren't you using the "-ssl3" flag to restrict the test to SSLv3 only? If you do so, on a server with SSLv3 DISABLED, the following behavior occurs:

    openssl s_client -cipher "DES-CBC3-SHA" -connect <server-name>:443 -ssl3
      CONNECTED(00000003)
      883:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:545:

    ... which would mean that SSLv3 has been properly disabled.

    Is there a particular reason to consider this protocol/cipher combination (TLSv1 with DES-CBC3-SHA) to be vulnerable or is it a mistake in the testing script? I'm primarily asking because on some configurations (e.g. Microsoft IIS or Microsoft TMG Reverse Proxy under Windows Server 2008 R2 SP1), it is not easy (maybe not possible?) to cleanly disable this particular cipher.

    Thank you in advance for a short feedback and Best Regards.

    Greetings from Switzerland :-)

  • 0

    Dear

    I have disable SSLv3 but your script says SSLv3 Detected

    ./ssl3_cipher_check.sh ******** 443

    Testing *******:443 for support of SSL3.0 ciphers...

    NULL-MD5...YES - SSL 3.0 cipher detected
    NULL-SHA...YES - SSL 3.0 cipher detected
    EXP-RC4-MD5...YES - SSL 3.0 cipher detected
    RC4-MD5...YES - SSL 3.0 cipher detected
    RC4-SHA...YES - SSL 3.0 cipher detected
    EXP-RC2-CBC-MD5...YES - SSL 3.0 cipher detected
    IDEA-CBC-SHA...YES - SSL 3.0 cipher detected
    EXP-DES-CBC-SHA...YES - SSL 3.0 cipher detected
    DES-CBC-SHA...YES - SSL 3.0 cipher detected
    DES-CBC3-SHA...YES - SSL 3.0 cipher detected
    EXP-DH-DSS-DES-CBC-SHA...NO (no cipher match)
    DH-DSS-DES-CBC-SHA...NO (no cipher match)
    DH-DSS-DES-CBC3-SHA...NO (no cipher match)
    EXP-DH-RSA-DES-CBC-SHA...NO (no cipher match)
    DH-RSA-DES-CBC-SHA...NO (no cipher match)
    DH-RSA-DES-CBC3-SHA...NO (no cipher match)
    EXP-DHE-DSS-DES-CBC-SHA...NO (no cipher match)
    DHE-DSS-CBC-SHA...NO (no cipher match)
    DHE-DSS-DES-CBC3-SHA...NO (no cipher match)
    EXP-DHE-RSA-DES-CBC-SHA...NO (no cipher match)
    DHE-RSA-DES-CBC-SHA...NO (no cipher match)
    DHE-RSA-DES-CBC3-SHA...NO (no cipher match)
    EXP-ADH-RC4-MD5...YES - SSL 3.0 cipher detected
    ADH-RC4-MD5...YES - SSL 3.0 cipher detected
    EXP-ADH-DES-CBC-SHA...YES - SSL 3.0 cipher detected
    ADH-DES-CBC-SHA...YES - SSL 3.0 cipher detected
    ADH-DES-CBC3-SHA...YES - SSL 3.0 cipher detected

    SSL3 ciphers were detected on server **********:443

    and other says

    /ssl3_scan.sh ********

    *******:443 - SSL3.0 ciphers NOT supported

  • 1
    If you manage an entire data center or a corporate intranet, the problem is a little harder.  Never fear, though, because I used my lunch hour to solve the problem for you.
    The first script, ssl3_cipher_check.sh, checks a single target for the presence of SSL 3.0 support.  The results will be similar to the following: 
    # ssl3_cipher_check.sh 192.168.1.51 443
    Testing 192.168.1.51:443 for support of SSL3.0 ciphers...
    YES - SSL 3.0 support detected on 192.168.1.51:443
    The second script, ssl3_scan.sh, allows you to test an entire network range.  Using a network range specified in CIDR notation or a format compatible with nmap, the script detects and checks the standard and alternate ports commonly used for HTTPS on all hosts in the network range.  Results will be similar to the following:
    # ./ssl3_scan.sh 192.168.1.0/24
    Beginning test... please be patient...
    192.168.1.17:443 - SSL3.0 ciphers NOT supported
    192.168.1.35:443 - SSL3.0 ciphers NOT supported
    192.168.1.34:443 - SSL3.0 ciphers NOT supported
    192.168.1.51:443 - SSL3.0 ciphers supported
    192.168.1.58:443 - SSL3.0 ciphers supported
    How you decide to mitigate the risk is on you.
  • 0
  • 0

    foofoo_2, thanks for your comments.  There is a better way!  And I updated the scripts to do it that way.  I'd really like it if you would try the updated scripts (attached to my original post) and let me know how those work out.  They should be more reliable and faster.  :-) 

  • 0

    Yes, that may be an error.  Try the updated scripts posted to my original reply.

  • 0

    Thanks for the updated version of the scripts. Like this it works as expected :-)

    I'm going to make more detailed tests tomorrow and let you know the results.

  • 0

    Great info, above!  This Security Response blog post may be of interest:

    Poodle: Vulnerability in old version of SSL represents new threat
    https://www-secure.symantec.com/connect/blogs/poodle-vulnerability-old-version-ssl-represents-new-threat

  • 3

    SEPM 12.1 RU5 uses OpenSSL 1.0.1h, and according to the link below, OpenSSL versions prior to OpenSSL 1.0.1j are vulnerable to Poodle.  With that being said, Symantec, Are you working to update your SEPM software to include OpenSSL version 1.0.1j or later?  If so, what is the projected timeframe on an update?  If not, is there a way we can modify/update the software to mitigate this vulnerability?

    https://www.openssl.org/news/vulnerabilities.htmlhttps://www.us-cert.gov/ncas/alerts/TA14-290A

    Thanks

2 pages