Back in early October 2014, we saw the original Poodle vulnerability, which targeted SSLv3. This week, we're seeing a new vulnerability that targets some TLS implementations—made known on Monday, December 8, 2014—and called PoodleTLS, or by its more official name: CVE-2014-8730. We've seen a number of questions in the community about this new vulnerability so we wanted to touch on it briefly—while we don't feel this new vulnerability is a major concern to most users, we did want to give an overview of what's known so you can determine the best course of action for your environment.
How CVE-2014-8730 works:
The POODLE attack takes advantage of when the receiver does not validate the additional data (“padding bytes”) added to a message during the encryption process. The SSL v3.0 specification did not require the receiver validate the padding bytes making the SSL v3.0 specification vulnerable to POODLE. The TLS specification does require the receiver validate the padding bytes but some TLS implementations do not validate the padding bytes and those implementations that do not validate the padding bytes are vulnerable to POODLE.
What's impacted by CVE-2014-8730?
So far it seems that this new Poodle variation only affects F5 and A10 devices. The CVE ID tracks the vulnerability for only these products (CVE-2014-8730). There likely will not be one single CVE ID for PoodleTLS—each implementation/technology that is susceptible to PoodleTLS will have their own CVE ID.
How can Rapid7 help you protect yourself from PoodleTLS?
A new check for Nexpose (added in 5.11.0) detects if TLS implementations do not validate padding bytes. The check will give you complete coverage for devices that are known to be vulnerable, and the check will detect devices that are not known to be vulnerable. That said, the check can generate considerable traffic while it detects if the TLS implementation is vulnerable to POODLE and must be enabled in the scan template before you scan. We have created a step-by-step guide on how to implement this specific check over on this blog post—if you have never implemented a check like this in Nexpose we strongly recommend that you first read the post.
h/t to Alex Hin and Justin Pagano for their contributions to this post.