www.tripwire.com Open in urlscan Pro
2606:4700::6812:fb0  Public Scan

Form analysis
1 forms found in the DOM

GET /search

<form action="/search" method="get" id="views-exposed-form-site-search-page-1" accept-charset="UTF-8">
  <div class="form-row">
    <fieldset class="js-form-item js-form-type-textfield form-type-textfield js-form-item-keys form-item-keys form-no-label form-group">
      <label for="edit-keys" class="sr-only">Keywords</label>
      <input data-bef-auto-submit-exclude="" placeholder="Search for keywords" data-drupal-selector="edit-keys" type="text" id="edit-keys" name="keys" value="" size="30" maxlength="128" class="form-text form-control">
    </fieldset>
    <fieldset class="js-form-item js-form-type-select form-type-select js-form-item-sort-bef-combine form-item-sort-bef-combine form-no-label form-group">
      <label for="edit-sort-bef-combine" class="sr-only">Sort</label>
      <select class="form-control form-select" data-drupal-selector="edit-sort-bef-combine" id="edit-sort-bef-combine" name="sort_bef_combine">
        <option value="search_api_relevance_1_DESC">Best match</option>
        <option value="published_at_DESC">Newest first</option>
        <option value="published_at_ASC">Oldest first</option>
        <option value="title_ASC">Title A-Z</option>
        <option value="title_DESC">Title Z-A</option>
      </select>
    </fieldset>
    <div data-drupal-selector="edit-actions" class="form-actions js-form-wrapper form-group" id="edit-actions"><input data-bef-auto-submit-click="" class="search-button button js-form-submit form-submit btn btn-primary form-control"
        data-drupal-selector="edit-submit-site-search" type="submit" id="edit-submit-site-search" value="">
    </div>
  </div>
</form>

Text Content

Cookie Preferences
Introducing Zombie POODLE and GOLDENDOODLE | Tripwire Skip to main content
 * Email Us
 * 800-328-1000


SECONDARY NAVIGATION

 * Customer Portal
 * Partner Portal
 * GET A DEMO

 * Products Toggle Dropdown
    * Tripwire Enterprise
    * Tripwire ExpertOps
    * Tripwire IP360
    * Tripwire LogCenter
    * View All Products

 * Solutions Toggle Dropdown
    * Security Configuration Management
    * File Integrity and Change Monitoring
    * Vulnerability Management
    * Cloud
    * Compliance
    * Industries

 * Services
 * Resources Toggle Dropdown
    * Upcoming Events
    * On-Demand Webinars
    * Datasheets
    * Case Studies
    * Guides
    * Training
    * View all Resources

 * Blog
 * About Toggle Dropdown
    * Careers
    * Leadership
    * Newsroom
    * Partners
    * Contact Us

Keywords Sort Best matchNewest firstOldest firstTitle A-ZTitle Z-A


 1. Home
 2. Blog
 3. Introducing Zombie POODLE and GOLDENDOODLE

INTRODUCING ZOMBIE POODLE AND GOLDENDOODLE


Posted on February 4, 2019


Image

I’m excited to announce that I will be presenting at this year’s Black Hat Asia
about my research into detecting and exploiting CBC padding oracles! Zombie
POODLE and GOLDENDOODLE are the names I’ve given to the vulnerabilities I’ll be
discussing. Similar to ROBOT, DROWN and many other vulnerabilities affecting
HTTPS, these issues stem from continued use of cryptographic modes which should
have been long ago deprecated and yet are inexplicably still supported in
TLSv1.2. In this case, the troublesome feature is that TLSv1.2 supports CBC mode
ciphersuites. To understand these flaws, it’s important to have a little
background on block ciphers and cipher-block chaining (CBC) mode. A block cipher
operates on discrete blocks of data as opposed to a stream cipher that would
encrypt individual bits. AES is an example of a block cipher, while RC4 is a
stream cipher. AES can only encrypt or decrypt 128-bit blocks of data. It is not
possible to directly encrypt or decrypt more or less bits with AES without
defining a mode of operation. CBC is a mode of operation for block ciphers in
which ciphertexts are chained together via XOR. By doing this, repeated
plaintext will not lead to repeated ciphertext, and modification of a ciphertext
block will also change the plaintext in the following block. A high-level
overview of AES-CBC mode encryption in TLS is as follows:
 1. Plaintext message is split into discrete 16-byte blocks of data
 2. An initialization vector (IV) is randomly generated
 3. First block is encrypted using the selected block cipher and key
 4. Block cipher output is XORed with the initialization vector
 5. Result from #4 is stored as the first block of ciphertext
 6. The next block of plaintext is passed to the block cipher
 7. Output from the block cipher is XORed with the previous ciphertext block
 8. Result from #7 is stored as the next block of ciphertext
 9. Steps 6-8 are repeated until all plaintext is consumed

CBC mode decryption reverses this process by decrypting each block and XORing it
with the previous ciphertext block (or IV) to recover the plaintext from that
block. Wikipedia has a nice illustration of how this works:
Image

Credit: CBC decryption illustration by WhiteTimberwolf,
https://commons.wikimedia.org/w/index.php?curid=26434095 Since AES-CBC only
works with multiples of 128-bits, inputs may require extra bits to be evenly
divided into blocks. These extra bits are called padding, and TLS prescribes a
specific format for this padding. If a server reveals whether the padding
conforms to a specific format, it is leaking information about the decryption to
an attacker and may create the opportunity for a chosen ciphertext attack. The
POODLE attack leverages the fact that SSLv3 did not prescribe a deterministic
format for padding and therefore could not fully validate these bytes. The
implication is that an attacker with the ability to relocate an interesting
ciphertext block to replace a block of padding can decrypt the last byte of the
targeted block if the server confirms a proper padding. This is what is known as
a padding oracle, and it’s really not as hard as it sounds to exploit.


WHAT WAS POODLE?

In the wake of POODLE being revealed, it was quickly discovered that POODLE also
affected many systems without SSLv3 because these systems incorrectly used the
SSLv3 padding function in their TLS implementations. For an excellent
illustration of how the POODLE attack works, I recommend reading the older
write-ups from Adam Langley or Matthew Green. At a high-level though, for this
attack to work, the attacker must be able to trigger requests from a victim to
an authenticated resource while actively intercepting and modifying the
resulting SSL records. In other words, the victim’s web browser must have
authenticated session cookies for a service using a vulnerable TLS stack. The
attacker then simply needs to get the victim to load a web page in that browser
including attacker-controlled JavaScript. To be 100% clear, the JavaScript can
run in any origin and does not need to be injected into the HTTPS session. For a
man-in-the-middle, this can be as simple as injecting JavaScript into any HTTP
connection. The attacker JavaScript must then produce HTTPS requests such that
the session cookie is aligned to the end of a ciphertext block and so that the
overall length of the plaintext is an exact multiple of the block size. (This
message length will ensure that the last ciphertext block is only padding
bytes.) Although this sounds challenging, it is more or less just an arithmetic
problem based on things like hostname length and whatever default headers the
victim’s browser sends. As an example, let's consider a request to
https://Example.com. In order to encrypt this request, the client must calculate
a message authentication code (MAC), append this value to the request and then
add padding to fill the final block. The result (for TLS) is as follows with MAC
bytes replaced with XX:  
Image

Each row on the right represents a block which will be fed into the block cipher
and chained together with XOR to produce 8 corresponding ciphertext blocks which
will be encapsulated by a TLS record layer and then sent to the server.
Image

In this case, because the request length plus the 20-byte MAC is a multiple of
the block size, the final block consists entirely of padding bytes. This is
interesting because the padding bytes are not included in the message
authentication code. In a basic POODLE TLS attack, the above request would have
been produced by JavaScript with the URL and headers specifically crafted so
that the last block is entirely padding. The POODLE attacker allows the HTTPS
handshake to occur without interference, but when the encrypted application data
payload is sent, they replace the last ciphertext block (e.g. full of padding)
with the ciphertext block expected to have a session cookie. The altered TLS
record now looks like this:
Image

Upon receipt, the vulnerable server will first decrypt the ciphertext as per the
CBC decryption process. In doing so, the plaintext output from the last block
will be the result of a bitwise XOR the 'Block 7' ciphertext with the deciphered
Block 5. This means that the last block of plaintext will effectively be random.
The final byte of this plaintext will be interpreted as a padding length vector
that I will refer to as n. For a proper TLS implementation, the server will
verify that the last n+1 bytes all have the value n. If this is not true, the
server is expected to reject the message with a generic 'Bad Record MAC' TLS
alert. POODLE TLS vulnerable implementations fail to perform this check and will
instead simply remove the last n+1 bytes. The final 20 bytes of the remaining
buffer are set aside and compared to the MAC calculated from the remaining
bytes. The only way for the MAC to be valid in this case is if the plaintext had
ended with 0x0F. The attacker is able to observe this based on whether the
server rejects or accepts the modified record. If the record is accepted, the
attacker now knows that the last byte of the block cipher output from Block 5
XOR'd with the last byte of the Block 7 ciphertext yields the value 0x0F. The
attacker can now compute the plaintext of the last byte from Block 5:
Image

Where P5[15] denotes the last byte of the Block 5 plaintext and Cn[15] denotes
the last byte of ciphertext block n. The attacker would then adjust the URL and
headers in the controlled HTTPS request so that another byte of plaintext will
align with the end of a block. For example, the requested path could be trimmed
by a byte to shift the position of the cookie value while simultaneously adding
a 15 byte header to maintain the 16 byte padding length. (A 15 byte header will
add 17 bytes due to the CRLF line ending.) This process repeats until all
desired bytes have been decrypted. On average, each byte will take 256 requests
to decrypt since the encrypted bytes are effectively random. It seemed back in
2014 or early 2015 that all the popular stacks with POODLE TLS had been
discovered and patches had been issued. That’s why I was quite surprised when I
developed a generic CBC padding oracle detection tool and found that POODLE is
actually still readily exploitable on at least one prominent middlebox/load
balancer product by only making a very slight tweak to the underlying oracle.
Because I had thought POODLE died years before (and because ROPOODLE doesn’t
roll off the tongue), I affectionately called this finding Zombie POODLE. Citrix
has now released a patch for Zombie POODLE under the ID CVE-2019-6485. I
strongly encourage all Citrix users to upgrade immediately. The other finding,
GOLDENDOODLE was named with tongue firmly planted in cheek as a cousin to
POODLE. It is quite similar to POODLE in that they both allow a
man-in-the-middle to decrypt certain data like session cookies. The similarity
ends, however, when considering attack performance. Whereas POODLE requires an
average of 256 tampered requests per byte being decrypted, each request in the
GOLDENDOODLE attack allows the attacker to guess the value of a plaintext byte.
In practical terms, this means that an uppercase hexadecimal session ID will
require at most only 16 requests per byte.


FAQ

Q: Do we really need another named crypto vulnerability? A: NO. I absolutely
didn’t need to name these, but naming vulnerabilities is fun, and you know
what’s said about all work and no play. Plus, names have made it easier when
communicating with vendors. Q: Exactly how much sleep should I lose over this?
A: For most people, the answer is none or at least no more than was warranted by
POODLE. Although these conditions can be exploited in a practical manner and
could expose access to thousands of systems, the attacks have certain
preconditions which limit the likelihood of widespread exploitation.
Exploitation requires a man-in-the-middle position, and the exploitation must be
tuned somewhat for different environments to determine block offsets of
authentication tokens being targeted. Q: How can I detect these flaws on my
network? A: Currently, Tripwire IP360’s generic CBC padding oracle detection is
the only tool known to detect these conditions. Public testing tools will be
made available at the time of my talk. Q: I’m a vendor making products with a
proprietary TLS stack or hardware TLS acceleration. Can I test my product
already? A: I have made a Go-based scanning tool which is available (under
embargo) to vendors looking to test their systems.

CRAIG YOUNG



View Profile


FOOTER MENU


PRODUCTS & SERVICES

 * Tripwire Enterprise
 * Tripwire IP360
 * Tripwire LogCenter
 * Tripwire ExpertOps
 * Services
 * View All Products
 * Fortra Products


SOLUTIONS

 * By Security Need
 * By Compliance Need
 * By Industry


RESOURCES

 * Upcoming Events
 * On-Demand Webinars
 * Datasheets
 * Training
 * Request a Quote
 * Start a Demo


ABOUT

 * Fortra
 * Patents
 * Customer Support
 * Report a Vulnerability


CONTACT INFORMATION


PRIVACY POLICY


COOKIE POLICY


IMPRESSUM

Copyright © Fortra, LLC and its group of companies. All trademarks and
registered trademarks are the property of their respective owners.