These Recently Discovered POODLEs Can Bypass Your TLS

These Recently Discovered POODLEs Can Bypass Your TLS
Thu, 02/21/2019 – 11:01

Networks which require support for backwards compatibility with older ciphers and cryptographic methods may also have to avoid upgrading to TLS 1.3, because that’s been dropped too. And that’s unfortunate because having to maintain backwards compatibility with older cryptographic standards makes networks vulnerable to some pretty terrible exploits. Terrible exploits such as Zombie POODLE and GOLDENDOODLE, recently discovered by Tripwire’s Craig Young. Young wrote:

Zombie POODLE and GOLDENDOODLE are the names I’ve given to the vulnerabilities I’ll be discussing. Similar to ROBOT, DROWN and many other vulnerabilities affecting HTTPS, these issues stem from continued use of cryptographic modes which should have been long ago deprecated and yet are inexplicably still supported in TLSv1.2. In this case, the troublesome feature is that TLSv1.2 supports CBC mode ciphersuites.”

These worrisome new discoveries are related to POODLE, a previously known padding exploit. Patrick Nohe explains:

“POODLE worked by attacking the padding used with block ciphers. When encryption is done with a block cipher, the length of the data being input needs to be an exact multiple of the block’s length in bytes. For instance, with triple DES, the block length is 8 bytes (64 bits), for AES it’s 16 bytes (128 bits), so before encryption can be performed using either of those ciphers you’d need to pad the input to be a multiple of the block length.”

The simplest way to be safe from Zombie POODLE and GOLDENDOODLE is to implement TLS 1.3, because then there’d be no padding to exploit. That’s going to be a real challenge for networks that must support older technologies and networks which require the ability to implement packet inspection.

Citrix load balancers may be vulnerable to the recently discovered Zombie POODLE and GOLDENDOODLE exploits, because that’s how Craig Young discovered them.

The Citrix-specific Zombie POODLE and GOLDENDOODLE vulnerability has been recorded as CVE-2019-6485. Here’s how that particular vulnerability is described:

“A vulnerability has been identified in the Citrix Application Delivery Controller (ADC) formally known as NetScaler ADC and NetScaler Gateway platforms using hardware acceleration that could allow an attacker to exploit the appliance to decrypt TLS traffic. This vulnerability does not directly allow an attacker to obtain the TLS private key.”

Fortunately, the fine people at Citrix have already been deploying patches which address Zombie POODLE and GOLDENDOODLE. If your network has any NetScaler or ADC devices, upgrade to these new firmware versions as soon as you can:

  • Citrix ADC and NetScaler Gateway version 12.1 build 50.31 and later
  • Citrix ADC and NetScaler Gateway version 12.0 build 60.9 and later
  • Citrix ADC and NetScaler Gateway version 11.1 build 60.14 and later
  • Citrix ADC and NetScaler Gateway version 11.0 build 72.17 and later
  • Citrix ADC and NetScaler Gateway version 10.5 build 69.5 and later

Load balancers from other vendors, web application firewalls, and remote access SSL VPNs may still be subject to Zombie POODLE and GOLDENDOODLE if you use TLS 1.2 or TLS 1.1. If your network needs to stick with TLS 1.2, you can mitigate against these padding exploits by completely disabling all support for CBC encryption suites.

If Zombie POODLE and GOLDENDOODLE has you biting your nails, Young is ready to present his full findings at Black Hat Asia in Singapore at some point during the March 26th to March 29th event. What do we have to look forward to? Here’s a brief description from Black Hat Asia’s website:

“HTTPS is the backbone for online privacy and commerce – yet, for two decades, the underlying TLS protocol received little more than a series of band-aid fixes. Rather than deprecating cryptographic techniques with known weakness, the TLSv1.2 specification has a long list of workarounds, countermeasures and caveats, which must be carefully followed to prevent attack. This is evident from the fact that PKCS #1 v1.5 padding, RC4 encryption, and CBC mode ciphers can all be used in TLSv1.2.

This session will highlight research into more effective testing and exploitation techniques for CBC padding oracles. We’ll uncover how a slight tweak to POODLE resurrected the vulnerability in a major enterprise HTTPS implementation more than three years after it had been patched.”

I’m eagerly anticipating more information about these very inconvenient and dangerous new vulnerabilities!

Related posts

tls security, tls vulnerability, poodle exploit
Guest Blogger: Kim Crawley

Organizations and enterprises are gradually adopting the new TLS 1.3 to encrypt their internet traffic with the latest standard. That’s great, and for more than one reason. TLS 1.3 has mandatory perfect forward secrecy because it uses the Ephemeral Diffie-Hellman key exchange protocol. That means that keys can’t be used to decrypt previously generated ciphertext, an obviously significant security improvement. Unfortunately, some networks may not be able to implement TLS 1.3 because of mandatory perfect forward secrecy. As I’ve written previously:

“Network security devices such as components of intrusion prevention systems inspect packets which travel through them, looking for malware or other types of cyber attacks. An intrusion prevention system will typically use decryption keys used throughout the network to decrypt packets so their contents can be inspected. Web firewalls often look for indications of SQL injection attacks with packet inspection. But if specific keys are only used for limited data transmission sessions, packet inspection becomes very challenging indeed.

If only the endpoints of TLS 1.3 sessions, the specific clients and servers, have decryption keys, the security appliances that exist somewhere in between become blind to the content of their packets.”

So, if a network’s security solution requires the ability to conduct packet inspection, TLS 1.3 may have to be avoided and TLS 1.2 may have to stay.

*** This is a Security Bloggers Network syndicated blog from Rss blog authored by kdobieski. Read the original post at: