Google has recently disclosed a (new?) SSLv3 vulnerability that allows an attacker controlling the SSL-encrypted network stream between client and server to extract the plaintext of specific parts of the communication, most “preferable” cookies.
Does it have to do with BEAST again?
Due to the well-known insecurities of SSL researchers have speculated the existence of the attack vector about for some time. Additionally, the attack was developed by researcher Thai Duong who was also part of the BEAST and CRIME attack.
The POODLE attack is similar to BEAST, but unlike the latter, POODLE doesn’t require such extensive control of the format of the plaintext.
According to Matthew Green, research professor at Johns Hopkins University and cryptographer: “What makes it worse than BEAST is two things: One, It’s not as easy to fix as BEAST was on TLS. Two, it doesn’t require you to be running a Java applet the way you needed to with BEAST. You can probably execute the attack with a piece of Javascript,”
How it works?
As the name “POODLE” suggest – Padding Oracle On Downgraded Legacy Encryption – is a very effective attack against CBC encryption. Since SSLv3 does not specify the padding bytes of a cipher block, an attacker can send duplicates of blocks and use a XOR operation to extract one byte of plaintext – based on a pattern in padding data – if the server accepts and does not close the SSL connection.
Thus, with an average of 256×N requests an attacker can decrypt N bytes of plaintext from SSLv3. The critical part of this attack is that SSLv3 doesn’t specify the contents of padding bytes. TLS does and so this attack doesn’t work because the attacker only has a 2^-64 or 2^-128 chance of a duplicated block being accepted.
But what about servers and clients supporting up to TLS 1.2?
SSL/TLS has negotiation mechanisms in place that should prevent a browser and server both supporting modern encryptions (eg. TLS 1.1) to fallback to anything else.
However, due to loose implementations, negotiation is also loose. Thus, an attacker, by injecting SSL negotiation errors in the network, thus triggering a “downgrade dance”, forces the use of SSLv3 in order to launch the attack.
What is to be done?
Disable SSLv3 completely would solve the problem but communication between legacy systems may be required and even support for latest version of TLS is not straight-forward (for example, OpenSSL prior 1.0.1 does not support TLS >1.0 = Redhat/Centos decisions..)
TLS_FALLBACK_SCSV is proposed and implemented in many occasions, which forces the use of the correct TLS version. By this feature, all unnecessary downgrades (eg TLS 1.2 to TLS 1.1 if both clients support 1.2) are safely avoid.
How Obrela Security Industries protects their Clients from the threat?
“Aggressive” measures have taken place in the past to disable SSLv3 completely on all services delivered to our clients including the Web Application Firewall and management consoles for MSS services.
Additionally, we are currently taking steps towards an implementation of TLS_FALLBACK_SCSV to test the non-yet-standardized feature that should apply also on non-SSLv3 setups.
