What is GOLDENDOODLE Attack?

Image

This post is one in a series of posts describing TLS CBC padding oracles I have identified on popular web sites. The other posts in this series include an overview of CBC padding oracles, a walkthrough of how I came to develop a new CBC padding oracle scanner, and a write-up on the Zombie POODLE attack. GOLDENDOODLE is the name I’ve given for exploiting modern TLS stacks using the classic CBC padding oracle technique described by Serge Vaudenay in 2002. GOLDENDOODLE can be used to hijack authenticated TLS sessions if the server reveals the padding validity of application data records in such a way that a MiTM attacker can recognize well-formed padding independently form a valid Message Authentication Code (MAC). This includes, but is not limited to, cases such as Cisco ASA CVE-2015-4458 where systems completely fail to validate MAC. From a practical standpoint, the difference between GOLDENDOODLE and Zombie POODLE or POODLE TLS is performance. As noted in a separate blog detailing how I came to research this topic and identify this behavior, GOLDENDOODLE attacks can be achieved with far fewer requests because the attacker has more control to manipulate the ciphertext without breaking the oracle response. GOLDENDOODLE oracles allow the attacker to confirm guessed values for plaintext bytes rather than waiting for random occurrences. In this post, I will detail the specifics of GOLDENDOODLE as observed during my scans of the Alexa top ranked sites.

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 GitHub

Additional 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?