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 GOLDENDOODLE attack
Although not POODLE per se, Zombie POODLE is in many ways a resurrection of the well-known POODLE TLS (aka POODLE BITES or POODLE 2.0) attack. POODLE TLS and Zombie POODLE both exploit server stacks which behave differently when receiving TLS records with valid MAC and invalid (non-deterministic) padding. This is known as a ‘padding oracle’.
The difference is that Zombie POODLE generically refers to the exploitation of a wide-range of implementation errors which create this valid MAC/invalid pad oracle. While POODLE TLS specifically implies that the stack does not validate padding bytes, Zombie POODLE typically implies that the implementation did validate padding bytes but inadvertently leaked the result.
For more details on how I came to identify this behavior, please check out this background post and also this one which details GOLDENDOODLE. As discussed in my other posts, I developed a new TLS CBC padding oracle scanner and used it scan the top 1 million web site domains as ranked by Alexa
Scan data from before Citrix and F5 released advisories revealed 68 different behavior profiles across roughly 3,800 domains flagged with Zombie POODLE. (Many hosts technically have Zombie POODLE and GOLDENDOODLE, but to avoid double-counting, these hosts are not considered in this count).
The most common Zombie POODLE behavior was associated primarily with Citrix NetScaler making use of SSL hardware acceleration but also may be found on some configurations of other TLS stacks. These systems respond to all MAC or padding errors in application data by resetting the TCP connection, but if the MAC is correct, the server will first send a TLS Bad Record MAC alert. This behavior was observed on more than 2,500 domains.
As a possible explanation for this behavior, I offer this flawed TLS CBC decryption process:
- Incoming TLS record is decrypted
- Final byte of plaintext is interpreted as a padding length
- MAC value is extracted using the padding length from #2
- Expected MAC is calculated and compared to the value from #3
- If value from #3 and #4 do not match, reset the TCP socket
- Compare padding byte values for uniformity
- If padding is non-uniform, send TLS alert and TCP reset
The oracle constructed to exploit this behavior can be seen as an inversion of the original POODLE oracle. In a POODLE TLS attack, TLS alerts signify correct padding length (and therefore MAC). In a Zombie POODLE attack against this behavior, a TLS alert instead indicates correct padding length (and MAC).
Detecting and Remediating Zombie POODLE
Zombie POODLE is one of the many TLS CBC padding oracles Tripwire IP360 detects. Affected systems will be reported as ID #415753, “TLS CBC Padding Oracle Vulnerability”. Citrix
have already released advisories and subsequent advisories are being tracked on GitHub
The best solution for Zombie POODLE (and all other TLS CBC padding oracles) is to simply disable the use of TLS CBC ciphers. Deprioritizing these ciphers can also help thwart real-world attacks. The attacker cannot typically force the selection of a specific cipher and therefore can only execute a CBC padding oracle attack if the client/server normally negotiate a vulnerable cipher. For this reason, it should not be seen as a full mitigation.
I have also released my Go based padding oracle scanner on GitHub for scanning outside of IP360. A more exhaustive Java based scanner will also be published on the Ruhr University Bochum – Chair for Network and Data Security GitHub. I would like to especially thank Juraj Somorovsky, Robert Merget, and Nimrod Aviram for their helpful feedback on my research.
For more information, check out the following additional blog posts: