Poodle and Doodle, FUD and the Sucuri WAF

On any given day, Sucuri sees thousands of clients go through the PCI compliance process. The requirements outlined by the Payment Card Industry Data Security Standards (PCI DSS) are mandatory for any website accepting credit card payment, and this process can be very stressful for website owners not familiar with these guidelines. Failure to comply with PCI requirements could result in penalties, large fines, or even lose the ability to take online credit card payments. 

False Positive PCI Vulnerability Reports

We have recently seen a number of false positive reports for clients using our Web Application Firewall (WAF) related to a collection of vulnerabilities (CVE-2019-5592). 

• Zombie POODLE (Invalid padding with valid MAC)
• GOLDENDOODLE (Valid padding with an invalid MAC)
• 0-Length OpenSSL (Invalid Mac/Valid Pad, 0-length record)
• Sleeping POODLE (invalid padding with valid MAC)

These false positives are originating from a handful of PCI compliance specialists who have wrongly flagged websites using our WAF as non-compliant. As an ecommerce website who depends on revenue, I can only imagine how distressing it would be to receive an email with a warning that you have failed PCI compliance — and these empty claims that the WAF is vulnerable have no basis and have not been proven. 

POODLE & DOODLE: Vulnerability Details

By leveraging these vulnerabilities, a bad actor may be able to decipher TLS connections — essentially, peek inside encrypted traffic. This is a very complex hack to achieve, and I’ll describe a bit further in detail how the vulnerability works and why WAF users are protected.

What’s happening here is the block cypher ECDHE-RSA-AES256-SHA384 on TLSv1.2  that the WAF uses can, in certain circumstances, be leveraged in these attacks. But this doesn’t mean that the WAF is vulnerable, only that the block cypher exists on the WAF.

Block cypher ECDHE-RSA-AES256-SHA384 is expressly listed as approved by NIST on page 26 of NIST.SP.800-52r2.pdf. You can find a redirect to this resource on page 70 of PCI-DSS-v4_0.pdf, the most current relevant standards. 

There is nothing wrong with this block cypher itself — in certain circumstances it is possible to leverage an attack on it, but due to our proprietary WAF rules and technology, any site using the WAF would be protected against these attacks. 

False Positives Based on Unfounded Claims

The PCI compliance specialists responsible for these false positives have demanded that Sucuri remove ECDHE-RSA-AES256-SHA384 — and one very misinformed PCI compliance specialist even went as far as to demand the WAF fully remove TLSv1.2.

TLSv1.2 will be retired one day. PCI will likely give a couple of years warning when that happens, just as they did when TLSv1.1 and TLSv1.0  were retired before — but I don’t expect it to happen any time within the next year. The only PCI approved protocols today are TLSv1.2 and TLSv1.3, but 1.3 is still fairly new. We expect there to be a large number of browsers and other web app clients dependent on 1.2 for quite some time, so the idea of relying on 1.3 alone is a mad proposition.

I have had to get into protracted discussions with a couple of these PCI compliance specialists where they make claims and demands. However, they have not been able to prove the WAF is as vulnerable as they claim — and we are not going to be sharing details of our mitigation methods. 

I have yet to even see an attempt to prove a site behind the WAF is vulnerable to these attacks. Instead, only empty claims which I expect are based on some simple script they are using that confirms that the WAF is using this particular cypher. Well recognized tests such as https://www.ssllabs.com/ssltest/analyze.html and https://www.immuniweb.com/ssl/ both confirm the existence of this protocol and cypher on the WAF, and specifically confirm the WAF is not vulnerable to these attacks.

In Conclusion

If you really want to prove an application or WAF is vulnerable to some attack, you need to provide a replicable Proof of Concept to back up the claim — for example, this (unrelated) PoC. But, as I have said, it’s very hard to actually leverage these attacks and would take a deep understanding of the HTTPS stack and a lot of hard work to present such a PoC. We can’t do it for them, we can only set the challenge.

Apart from the unnecessary distress that these false positives cause for our WAF users, what especially bothers me about these unfounded claims is that they tend to act as a distraction from real improvements that could be made to a website owner’s security posture.