Image
Image
Prevalence
My most recent scans for GOLDENDOODLE (March 2019) identified exactly 750 vulnerable domains with 57 different distinct behaviors out of the Alexa top 1M. This is down only slightly from initial scans in August 2018 which identified closer to 1,000 domains. This drop indicates that some number of sites did in fact deploy updates or configuration changes perhaps in response to advisories from Citrix and F5. Domains affected by GOLDENDOODLE include dozens of high-profile financial, government/military, and eCommerce sites. Although there were only 750 domains detected in my scan, it is worth noting that in fact almost a quarter of these domains were in the top 100k rankings. The most common GOLDENDOODLE behavior in my data set was detected on 118 domains. On these hosts, incomplete or inconsistent padding leads to a TCP timeout while well-formed padding yields an HTTPS reply even if the MAC was incorrect. (A TCP timeout state means that the server did not send any packets after receiving a padding error even when the client sends a message to close the TLS socket.) The next most common GOLDENDOODLE behavior is quite similar except that there is a TLS handshake failure alert instead of a TCP timeout. This behavior was present on an additional 88 domains and another closely related behavior was observed on 74 hosts. The difference on these hosts is that they sent the more appropriate TLS Bad Record MAC alert rather than a handshake failure alert.GOLDENDOODLE Attack Implications
The impact of a GOLDENDOODLE attack is almost identical to POODLE exploit but there is one major difference. The additional flexibility from MAC validation failures allows GOLDENDOODLE to be exploited with far fewer requests than POODLE. In POODLE, the attacker is effectively rolling a 256-sided die and simply waiting for each time in lands on 15 (for AES). For GOLDENDOODLE, the attacker can systematically test all possible bytes until the correct byte is discovered (or all others are ruled out). This means that any byte can be decrypted with at most 255 intercepted requests. The search window can typically be reduced further since the targeted bytes will be printable ASCII characters (per HTTP). This means there are really at most 94 connections needed for any byte found in HTTPS. This may be reduced even further if the higher-level application uses a specific character set. For example, the Cisco ASA I tested uses fixed-case ASCII hexadecimal strings meaning that each byte will require at most 15 requests to decrypt giving a possibly exponential speed-up when compared to POODLE TLS.More GOLDENDOODLES?
There are almost certainly more hosts with GOLDENDOODLE behavior than I’ve identified with my scanner. This is because my scanner does not exhaustively test all combinations of TLS protocol and ciphersuite. Although I am aware that some systems are only vulnerable when using a specific cipher/protocol, I opted to focus on whatever protocol/cipher combination the server prefers when presented with a client hello offering several CBC suites and supporting TLSv1 to TLSv1.2. A more comprehensive review of TLS CBC padding oracles on the Internet will be included in the USENIX Security 2019 proceedings.Special Thanks
I would like to especially thank Robert Merget, Juraj Somorovsky, and Nimrod Aviram for inviting me to collaborate with them and co-author their awesome paper titled, Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities which will be presented at USENIX Security 2019 in August. You can find more information about their research on GitHubAdditional Reading
For more information, check out the following additional blog posts:- Introducing Zombie POODLE and GOLDENDOODLE (CBC padding oracle attack background)
- TLS CBC Padding Oracles in 2019
- What is Zombie POODLE?
