NOTE FROM CLEMENT:

Often times in my classes I get ask why it is necessary to understand what is a Message Authenticaiton code (MAC), why do I need to understand block versus stream ciphers,  whey do I need to understand the different modes of encryption.  As you read the article below, you will realize that it is necessary to understand these in order to make sense of modern attacks such as Poodle.   See a great article produce by SOPHOS below.   This article is from Paul Ducklin who is very adept at explaining complex attacks in simple terms. 

Imagine that you're a hacker who has taken over a Wi-Fi access point at a coffee shop.

You don't need to be there in person; you just need to be able to login to the access point as root (UNIX's name for the system administrator).

If you can do that, you can almost certainly spy on, and sneakily modify, everyone's network traffic.

However, you're out of luck for coffee shop customers who are using HTTPS, because that traffic is encrypted.

At least, that's the theory.

But by modifying traffic as it passes through your rogue access point, you can interfere with the way HTTPS connections are established.

That means you may be able to trick both ends of the connection – typically a browser and a server – into downgrading their security, falling back to using an old and less secure HTTPS version known as SSL 3.0.

If you can do that, you may then be able to extract confidential data, thanks to a bug known as CVE-2014-3566.

That's not much of a name, so the Google researchers who worked out this attack have dubbed it POODLE, short for Padding Oracle On Downgraded Legacy Encryption.

Woof!

How SSL 3.0 works

Very simply put, POODLE works because the encrypted data in an SSL 3.0 packet is arranged like this:

The MAC is a Message Authentication Code (MAC), or cryptographic checksum, used to ensure that the encrypted data hasn't been tampered with along the way.

The padding is just that: extra bytes tacked on the end of the data to pad it out so that the encryption algorithm can process it properly.

→ Padding is not needed if the connection is using what's known as a stream cipher, such as RC4, because stream ciphers can encrypt any number of bytes at a time, from one to millions. But if the HTTPS session is configured to use SSL 3.0 with a cipher such as AES-CBC or 3DES-CBC, it has to consume its data in fixed-size chunks, because AES and 3DES are block ciphers that can only encrypt one full chunk at a time: 8 bytes for 3DES, or 16 bytes for AES.

SSL 3.0 padding is done by adding zero or more bytes until the data size is one byte shorter than a multiple of the cipher block size.

Then, a final byte is added denoting how many padding bytes were added before.

Using the last byte to signal the size of the padding is convenient, because it makes it easy for the other end of the connection to get rid of the padding later, by doing this:

  • Decrypt all the data (user data, MAC and padding).
  • Chop off the last byte to get a count of how many padding bytes there are.
  • Chop off the padding bytes.
  • Chop off the MAC to leave just the confidential data.
  • Verify that the MAC matches the checksum of the confidential data.

Note that if the data and MAC are already a multiple of the cipher block size, you can't just leave it at that, because you always need to add at least one count byte, even if only to say that you've added zero padding bytes.

So, if we have 16 bytes of data plus a 16 byte MAC, and we are encrypting with AES (i.e. in 16-byte blocks), we'll need 15 bytes of padding, plus a final byte (set to the value 15) to round out the overall content to 48 bytes, an exact multiple of the AES block size:

Cryptographic flaws in SSL 3.0

You probably have an inkling of the flaws in SSL 3.0 from the diagram above.

Firstly, the padding bytes and the padding count aren't included in the MAC, and secondly, the 15 padding bytes can be anything at all and therefore cannot be validated or verified.

So, if you tamper with the last 16 bytes of the encrypted data, replacing them with absolutely anything you like as they pass through your rogue Wi-Fi router, there's still a 1-in-256 chance that the entire 48 byte data packet will be accepted by the server.

If the last byte in the modified last block just happens to decrypt to the value 15, then the server will chop off that final byte, and then blindly but correctly chop off the other 15 bytes of padding, blissfully ignorant that the padding bytes are completely different from when they left the user's browser.

That will leave the MAC, which will match the checksum of the confidential data, and the packet will be accepted even though it was altered.

This may not sound like much of a cryptographic hole, since only data that is going to be discarded anyway has been tampered with.

But it should be ringing a warning bell: modifications should always be spotted and if there are any inconsistencies in the received data, it should be rejected.

Deliberately devious tweaks

Now imagine that instead of randomly altering those last 16 bytes, you try some deliberately devious tweaks instead.

What if you copy the first 16 encrypted bytes and write them over the encrypted padding bytes, and then pass the data along?

If the server accepts your modified data stream, you now know that that the last byte of the block you copied decrypted to the value 15, otherwise the server would have extracted the wrong MAC and the data verification would have failed.

You just tricked the server into telling you something about the encrypted data you copied across!

Likewise, if the server reports an error, you know that the the last byte of the first 16-byte block is not 15.

That doesn't sound like much of an information leak, but in this case, size doesn't matter: strong encryption isn't supposed to leak anything at all.

You shouldn't be able to extract anything about the plaintext in an SSL 3.0 data packet merely by fiddling with the encrypted data stream.

Clearly, we have a problem.

Cipher Block Chaining

Actually, the description above isn't quite correct, because we omitted one aspect of the way that SSL 3.0 does its block ciphering, namely that is uses Cipher Block Chaining, or CBC.

That's actually a security enhancement that XORs the previous block of ciphertext with the current block of plaintext before encrypting each block.

The first plaintext block, of course, doesn't have any previous ciphertext to draw on, so it is XORed with a random starting block known as the Initialisation Vector, or IV.

CBC ensures that even a run of identical blocks, such as a sector's worth of zeros, won't encrypt into a recognisably repeating pattern of ciphertext blocks.

That's because of the the random IV mixed in at the start, and the randomness that then percolates through the encryption of each subsequent block.

So, when the server unscrambles your sneaky copy of those first 16 encrypted bytes that you wrote over the padding block at the end, it decrypts it and then XORs it with the previous 16 bytes of ciphertext (which just happen to be the encrypted MAC - the middle 16 bytes in our diagram above).

Ironically, this actually improves your chances of learning something about that last byte in the copied block.

As described above, with straight decryption only, you could only tell if the last byte was 15 or not.

But with CBC, that last byte is decrypted and then XORed with what is an essentially a random number.

In other words, it's not always going to be a plaintext byte of 15 that decrypts to 15 to trigger the POODLE trick and give the byte away.

In fact, if you can somehow persuade the user's browser to generate the same HTTPS request many times, for example by tricking it into thinking it needs to re-send the data due to an error, you'll have a fresh 1-in-256 chance every time of working out what that last byte is.

That's because the random IV means that you'll get a different stream of encrypted data every time.

Sooner or later, you'll recover the 16th byte of the original plaintext.

Recovering plaintext one byte at a time

If you can trick the user's browser into visiting a sequence of URLs (for example, by using your rogue access point to inject some JavaScript into a web page), you may be able to create a sequence of SSL 3.0 requests with the confidential data shifted along one character.

Then you can recover the new 16th byte in the block, which was the previous 15th byte, and so on.

One obvious way to control the positioning of both known and unknown content in SSL 3.0 packets is by generating a series of download requests in which you ask for a file that is one character longer each time.

You can then predict where the filename will appear in each HTTP request, and thus almost certainly work out where the HTTP headers, including the data you want to decrypt and steal, such as a session cookie, will be located:

The green data is controlled by you, because it is determined by the URL in the web request; the red data is the confidential content inserted by the user's broswer that you want to attack using POODLE.

What to do?

The problem is SSL 3.0.

It's an old version of the secure socket layer protocol: about as old as XP, in fact.

It was long ago superseded by safter alternatives such as TLS 1.0, TLS 1.1 and TLS 1.2.

So stop using it!

Tell your browser not to support SSL 3.0 connections, so that no rogue cybercrook in a coffee shop can downgrade your HTTPS sessions to his own advantage.

Tell your server not to offer or to accept SSL 3.0 connections at all, so that you can never be tricked into accepting a malicious sequence of POODLE requests that could put one of your website users at risk.

Please be aware: if you run a web server that refuses SSL 3.0 even when users specifically ask for it, those users, who might be your customers, will no longer be able to access your HTTPS pages.

But when WordPress.com VIP, the service on which Naked Security is hosted, wrote to tell us that it turned off SSL 3.0 on all its sites, including ours, it pointed out that only about 1 in 1000 users make SSL 3.0 connections at all.

Those 1 in 1000 users have much bigger problems than POODLE: most of them are using SSL 3.0 because they're still running IE 6 on Windows XP.

And that's a story for another day...

SEE BELOW ANOTHER GREAT ARTICLE FROM WATCHGUARD SECURITY

How to Neuter POODLE (New SSL Vulnerability)

by Corey Nachreiner

Surprise, surprise... Researcher's have found yet another OpenSSL vulnerability. They've named this one POODLE. Silly name, I know, but at least it stands for something—Padding Oracle On Downgraded Legacy Encryption.

In short, POODLE is a protocol level cryptography flaw in Secure Sockets Layer version 3 (SSLv3), which is one of the many encryption protocols available to SSL/TLS implementations like OpenSSL, used to encrypt network traffic. While SSL can encrypt any traffic, it's most commonly associated with secure web communications (HTTPS). SSLv3 is one of the older encryption protocols in OpenSSL's library, having been around for 18 years or so. Newer protocols like TLS 1.0-1.2 are much more secure, but we've kept SSLv3 around for legacy interoperability reasons. Since this new vulnerability allows attackers to decrypt SSLv3 traffic, it's time we get rid of SSLv3 for good.

The POODLE flaw is fairly complex, and hard to understand without a deeper comprehension of cryptography. If you'd really like to dive into the details, I recommend you read the paper [PDF] by the Google researchers who found the flaw, or check out this detailed explanation. However, here are the basics:

  1. First, this vulnerability requires a Man-in-the-Middle (MitM) attack to succeed. An attacker can only perform it if he can intercept traffic between you and the SSL server. Performing MitM attacks can range from extremely difficult to trivial, depending on the circumstances. For instance, if you join an unsecured WiFi network, attackers on the same network can quite easily intercept your traffic, whereas intercepting Internet traffic is exceptionally more difficult, and typically requires ISP level interception (or at least DNS poisoning) to pull off.
  2. Next, this attack only works against SSLv3 encrypted traffic, so the attacker needs to somehow force you to use it. This is a much easier hurdle for attackers to overcome. The SSL/TLS protocol includes a "downgrade" feature that allows SSL clients and servers to negotiate which encryption protocol they agree on, depending on what they both support. With a MitM attack, the attacker can intercept and manipulated the negotiations to ensure your browser and the server settle on SSLv3 encryption.
  3. At this point, attacker can take advantage of the SSLv3 flaw (which is essentially a vulnerability in how SSLv3's CBC cipher suites use padding) to decrypt certain bytes of your secured traffic. Again, see the paper if you are interested in the technical and mathematical detail. However, there are some caveats here. Basically, the educated guesses used in this attack will only work 1 in 256 times.  So this attack requires the same data be sent over newly created SSLv3 connection hundreds of time. Forcing hundreds of requests is easy when targeting web browsers, since the MitM attack allows the attacker to inject malicious javascript into your web session. This javascript allows the attacker to silently force your browser to do what he needs. However, there are many other clients that use SSL/TLS to encrypt communications, including VPN clients, and apps on your mobile device. Since this attack relies on malicious javascript, attackers can't easily exploit it against non-browser SSL clients. In any case, once this attack succeeds in decrypting one byte, it's trivial for the attacker to decrypt the rest of your secure message.
  4.  So what can attackers do by decrypting SSL encrypted web sessions? Most likely, they'd leverage this flaw to try to intercept your encrypted HTTP session cookie. This essentially allows them to hijack your secure web sessions, and do anything you could do on the particular secure site you're visiting. They wouldn't obtain your passwords, but they'd have access to your secure web account.

While this sounds pretty bad, and it can be when the attack succeeds, the mitigating factors mentioned above really lessen the severity of this flaw. MitM attacks are not trivial to pull off in most cases, and this exploit's javascript requirement means it can only easily target web browsers, not other SSL-based clients. Furthermore, if either end (client or server) disables SSLv3, the attack is dead in the water. In fact, NIST only assigns this vulnerability (CVE-2014-3566) a CVSS severity rating of 4.3, which is on the lower medium range of their severity scale. Though many of the media outlet reporting on this flaw have made it sound extremely dangerous, I would only give it a medium severity. It's definitely something you want to mitigate, but it is not nearly as dangerous as the Heartbleed and Shellshock flaws the media has compared it to.

How to Protect Yourself from PODDLE:

Simply put, disable SSLv3!

SSLv3 is an antiquated and broken encryption protocol. Every modern browser and SSL client supports much more recent encryption options. Disabling SSLv3 is the only way to completely protect yourself.

That said, some organizations may still use some legacy web applications, especially ones that require Internet Explorer (IE) 6 running on XP, which depend on SSLv3. Frankly, it's time you get rid of those applications. In order to quantify today's minimal SSLv3 usage, CloudFlare monitored all their customers' traffic and found only 0.09% of it was SSLv3. When monitoring only secure web (HTTPS) traffic, SSLv3 usage jumped to 0.65%, but that's still a tiny fraction of web traffic. We recommend you help bring this number to zero by getting rid of SSLv3 in your organization

So how do you disable SSLv3? There are two sides to the equation—the server and the client. You only have to disable one side for the attack to fail.

Since this attack targets clients, and seems to primarily affect web browsers, I recommend you disable SSLv3 in your browsers first. All popular web browsers have configuration settings that allow you to do so. The folks at Zmap.io have kindly provided an instruction page detailing how to disable SSLv3 in the popular browsers; check it out. Furthermore, most browser vendors have promised to disable SSLv3 by default in their next software release. Once you have disabled SSLv3 in your browser, attackers cannot leverage this flaw to decrypt your traffic, even if you connect to a web server that still has SSLv3 enabled.

That said, you also should disable SSLv3 on any servers you run, just to help protect the rest of the world against this flaw. The creators of OpenSSL have release an update that fixes this vulnerability (and three others). Besides allowing you to disable SSLv3 on your server, the latest version of OpenSSL supports a feature called TLS_FALLBACK_SCSC, which essentially prevents MitM attackers from forcing clients to downgrade to a certain encryption protocol. Many other Linux distributions and SSL implementation have also released updates. Go get them.

As an aside, once you've disabled SSLv3 in your browsers and servers, you can check the results using the following sites:

Are WatchGuard Products Affected by POODLE?

In short, yes.

WatchGuard appliances use OpenSSL and are affected by this vulnerability to varying degrees. The impacted products include:

  • XTM appliances - WatchGuard's web-based user interfaces (UI), whether the administrative interface or the VPN client portal, do support SSLv3, and are vulnerable to this. However, you can mitigate this flaw by limiting exposure to the Web UI. There is no reason to allow Internet users to access that administrative interface. Also, our SSL VPN clients do NOT support SSLv3. So mobile VPN connections are not affected. We are making updates to our XTM firmware to disable SSLv3 by default.
  • XCS appliances - The XCS's Web UI does support SSLv3 by default. However, you can disable it for the Web UI, and should do so. Our mail engine does also support SSLv3, and you can't currently disabled it in the mail engine. That said, this exploit primarily targets web browsers, so the exposure in the mail engine should be low. In any case, we are making changes to the XCS firmware to disable SSLv3.
  • SSL VPN appliances - The SSL VPN appliances administrative Web UI uses SSLv3, and your currently can't disable it. However, you can limit exposure simply by not allowing external access to the Web UI. As far as client VPN connections, you can disable SSLv3 in the Manage System => Device Setting page. Doing so ensures attackers can't exploit this flaw to intercept and decrypt mobile SSL VPN traffic. We will release and update to disable SSLv3 in the Web UI.

This vulnerability's impact to our appliances is relatively low, nonetheless WatchGuard will release updated versions for all affected software and devices that are under support. We are currently planning all these releases, and we will update this post as the dates and releases become available. In any case, if you limit access to the web-based administration interfaces on your WatchGuard appliances, the vulnerability poses you little risk. Furthermore, if you disable SSLv3 in your browser, attackers can't even leverage it against you, whether or not the appliance uses SSLv3.

To summarize, POODLE is a big enough issue that you should definitely disable SSLv3 in all your browsers and servers as soon as you can. However, despite the wide and alarming coverage of this issue, it does not pose a huge, real-world risk to most users. If you update your browsers, and avoid unsecured WiFi connections, POODLE will likely not bite, and is easy to neuter. — Corey Nachreiner, CISSP (@SecAdept)