In terms of SSL-related vulnerabilities, we’ve been through some serious threats like BEAST, CRIME, HEARTBLEED, and now… POODLE. POODLE is newly discovered attack against the 15-year-old, but extremely common, SSL version 3 protocol. It’s not a cute as it sounds.

POODLE stands for Padding Oracle On Downgraded Legacy Encryption, and it can essentially allow an attacker, with access to network traffic, to disclose plaintext data being sent over encrypted SSL version 3 connections. Furthermore, the attacker would be able to downgrade clients to this vulnerable protocol beforehand, meaning that the only prerequisite is that both the server and client support SSL version 3 – neither have to be using it by default.

The attack specifically affects CBC-based ciphers (that’s cipher-block chaining mode ciphers) as used in SSL version 3. Unlike other CBC vulnerabilities, like BEAST and Lucky-13, there is no reasonable workaround. The only non-CBC ciphers are RC4, which is also known to be vulnerable as a result of biases in the keystream. In other words, we shouldn’t use SSL version 3 at all anymore.

Could my organisation be vulnerable?

It is likely that your organisation is vulnerable, unless it has previously made a decision to disable SSL version 3 in both clients (e.g. internet browsers) and servers. Support for SSL version 3 is extremely high at the point that this vulnerability was disclosed, with almost every browser and server permitting its use.

An attacker could exploit the issue if they are able to intercept network traffic. This is most likely to occur on public/open Wi-Fi networks, as a prime example, although can be performed on internal corporate networks if an attacker is able to first sniff traffic via a separate attack.

How can we detect the issue?

SureCloud’s on-demand and PCI scans will check for the POODLE vulnerability on SSL/TLS services by default. It tests whether the service has disabled support for SSL version 3, and whether the SVSC (Signalling Cipher Suite Value) countermeasure has been applied, as well as ensuring that the alternative and more recent TLS protocols are supported.

If a host is vulnerable to the POODLE attack, it will be raised as “SSLv3 Padding Oracle On Downgraded Legacy Encryption Vulnerability (POODLE)” with ID 78479.

What can we do to protect our organisation’s users?

Avoiding networks on which communications can be intercepted, such as open Wi-Fi, is always good practice, and especially important now since POODLE could defeat secure connections.

As servers begin to gradually disable SSL version 3, connections to those endpoints will not be vulnerable to attack. To be certain that users can still access these sites, they should be using modern browsers that support TLS version 1.0 and higher. This includes just about all browsers in use today, with the exception of Internet Explorer 6 on Windows XP – these users should at least upgrade their browser as a matter of urgency.

Furthermore, users should continue to keep their browsers up-to-date in the future, since vendors will gradually be releasing a countermeasure (SCSV) and should eventually disable SSL version 3 support entirely.

If users want to jump-the-gun and have SSL version 3 disabled now, this can be achieved with most major browsers. Doing so will protect the user’s browser connections from the POODLE attack, but may prevent them from accessing some legacy web servers that have not enabled TLS.

• In Internet Explorer, open Internet Options > Advanced, and scroll down to the “Use SSL 3.0” option. Untick this option and Apply settings. Or apply via Group Policy.
• In FireFox, install this add-on and use it to disable SSL 3.
• In Google Chrome, you can create a specific shortcut that will start Chrome without support for SSL 3. It is important that the shortcut is used every time you start the browser.

1. Create a shortcut to chrome.exe.
2. Right-click the shortcut a select Properties.
3. At the end of the Target value, after the double-quote, append a space and then –ssl-version-min=tls1 e.g. “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –-ssl-version-min=tls1
4. Click OK (you may also need to grant Administrator permissions)

What can we do to protect connections to our servers?

Eventually, a standard known as SCSV (Signalling Cipher Suite Value) is expected to be rolled out to SSL/TLS servers via patches. Where this standard is also supported by the client, connections cannot be forcefully downgraded from TLS.

However, both in the short-term, and as an effective long-term solution, hosts should consider disabling SSL 3.0. This will protect all users who connect to the service from the POODLE attack, but may prevent some legacy browsers from connecting at all (such as Internet Explorer 6). If IE6 users make-up a significant-enough proportion of your user base, you might not wish to disable SSL 3 (although you should consider taking action by encouraging those users to upgrade).

• For Apache 2.2.23+, add/modify the following directive accordingly:
  SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
• For older version of Apache:
  SSLProtocol TLSv1
• For nginx, add/modify the following directive:
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
• For IIS, use Nartac’s IIS Crypto tool to disable SSL 3, or consider manually configuring the supported protocols within the registry at
  HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols (consult relevant documentation)

Get in touch

Should you have any questions regarding this or any security related matter please do not hesitate to get in touch by opening a support ticket or emailing SureCloud Support.

References

https://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exp…

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

https://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulne…

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-e…

https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-02

Whilst every effort is made to ensure the accuracy and robustness of any information presented, it is not possible for SureCloud to test every possible scenario an organization may face, and SureCloud cannot be held liable for any loss or damage which may arise from taking action on any of the contents provided. SureCloud strongly advises that all recommendations, solutions and detection methods detailed, are thoroughly reviewed and tested in non-production environments before being considered suitable for production release, in-line with any existing internal change control procedures.