DDoS Detection, Mitigation, Orchestration, and Threat Intelligence
Consolidated Security & CGNAT
TLS/SSL Inspection
Web Application Firewall
Application Security & Load Balancing
Analytics & Management
CGNAT & IPv6 Migration
In May 2011, Thai Duong and Juliano Rizzo released a paper titled, “Here Come The ⊕ Ninjas“, describing the BEAST attack.
In October of 2014, three-and-a-half years later, Bodo Möller, Thai Duong and Krzysztof Kotowicz released a new paper called “Padding Oracle On Downgraded Legacy Encryption”, which documented a new SSL vulnerability, POODLE.
BEAST stands for “Browser Exploit Against SSL/TLS” and is an attack allowing an attacker to effectively read protected content, exploiting IV (Initialization Vector) chaining in CBC (Cipher Block Chaining) weakness using a known plaintext attack. CBC IV chaining is a technique where the new “random component” (the IV) is a function of the crypto text from the previous block and is a commonly used technique circumventing the need for high rate random number generators, since it derives the IV from data that cannot (hopefully) be guessed and here lies the problem. If the data is guessable, the whole schema is weakened.
At that time, the attack was successfully mitigated by enabling RC4 as a stream cipher. Then in 2013, Scott Fluhrer, Itsik Mantin, and Adi Shamir published the paper, “Weaknesses in the Key Scheduling Algorithm of RC4,” in which they described a vulnerability in the Key Scheduling Algorithm (KSA) – or simply said, the way the initial state is derived. As already mentioned regarding the initial state in the case of CBC IV chaining, similarly here – if the initial state can be deduced, information is leaked. The difference, though, is that in CBC IV chaining an entire block is vulnerable. In this case, fragments of the plain text can be recovered – so with multiple attempts, the full text can be constructed. As a result, there is information leakage in the initial bytes of the encrypted stream.
Note that those are two separate issues that stem from a weak initial state of the system (yes, I am being liberal). In the case of BEAST, it is the CBC IV chaining that is attacked and can compromise a cipher block. In the RC4 attack, fragments of the plain text can be recovered and so, with repetition (and time), the entire text can be compromised.
At the time, BEAST affected SSL and TLS 1.0, currently POODLE (Padding Oracle On Downgraded Legacy Encryption) is only affecting TLS. Note that the issue is not really with the protocol itself but the cipher suites it uses. TLS 1.0 favors CBC ciphers and so does SSL v3, where the Padding Oracle attack happens. POODLE also requires the who “dance” to start with TLS so it can be downgraded (the -DLE part of the attack).
POODLE has two phases. In the first phase the protocol is degraded to SSL v3 and then a padding attack similar to BEAST is executed, where CBC IV chaining is exploited to recover the text block – but it is also combined with a cipher degradation attack (that the authors call the “downgrade dance”), so technically, the attack should be called “Dancing with BEAST.” Jokes aside, POODLE is more dangerous than BEAST because it requires less upfront information.
The POODLE attack exploits a protocol flaw in SSL v3 where the padding of the last block is not defined (with the exception of the last byte). This class of attacks is known as Padding Oracles attacks and this is an excellent article describing in detail how they work.
Specific to this attack is the way the padding works and that the last byte of the padding is significant and equal to the length of the padding itself. Having that in mind, if the final block is full of padding bytes only and the attacker is able to replace it with a block of interest that appeared earlier in the stream and the last byte matches, this block will be accepted and not result in termination of the connection. This means that that attacker can use that as a signal if they have “guessed” the encrypted value of the padding length and as a result they can recover the last byte of the block they replayed and gain one byte of the message. By manipulating the offset of the message they can circle through all its bytes. If this was to be a secure cookie, they would know its value.
It is important to note that for BEAST to work, the attacker has to have the ability to timely manipulate traffic. This could be done in a number of ways. On the local network, they can simply do MAC spoofing and run the traffic through their station, or do policy routing if they have an access to a switch, or they can potentially hijack traffic via BGP route injection (which has happened on a number of times in the past). The last note I make intentionally, so it is clear that it is not required to have access to the local network in order to exploit this. And for the ones that do not believe in BGP hijacks, I would strongly recommend Andree Toonk’s blog.
This was how the cipher leaks information based on the initial internal state and particular keys.
As mentioned before, this is a bug is in the design of the protocol and it is not implementation dependent. In comparison, Heartbleed was a bug in the implementation of the protocol and was particular to OpenSSL, so other SSL implementations did not suffer the same issue. In POODLE’s case the flaw is affecting all SSL implementations supporting SSL v3 and all corresponding ciphers.
If you have OpenSSL installed you can connect to a server and force SSLv3 using the following command: openssl s_client -ssl3 -connect <TESTED SERVER>:<PORT>.
If you do not have OpenSSL and the server is accessible from the Internet, you can use some of the online resources.
A10 users can use disable certificates in the data plane by issuing the “disable-sslv3”, under the “slb template client-ssl cs”. Detailed article to follow.
As it pertains to the administrative web interface A10 devices are using the FIPS version of the OpenSSL library which does not allow for the use of SSL v3 so this code is not compiled in.
It would appear that at this point the best way to remediate is to disable the protocol that was superseded by TLS 1.0 some 15 years ago and this is true for the majority of cases. There is a large exception though. Tech In Asia claims some 200 million users of Windows XP and IE6 in China.
The problem with this is that Windows XP has not been officially supported as a platform as of April 8, 2014 and even worse, since the introduction of Windows Genuine Advantage in Windows XP SP3 a lot of those illegally installed system did not have it applied so they run without the latest set of patches for an already EOL platform, including they lack the ability to use TLS out of the box. However Microsoft provides some resources on how to do this here.
There is a new SSL option called TLS_FALLBACK_SCSV, which will allow for backward compatibility and was released in OpenSSL today. It comes with several considerations however. It only protects new implementations from downgrading to SSL v3, in case of network issues, but it does not protect systems using the old protocol and properly negotiating it, which in turn leaves them only with the option to switch off CBC modes and operate using RC4 which as explained above is also vulnerable. In addition, the TLS_FALLBACK_SCSV patch requires that both sides implement it.
Google Chrome and Mozilla Firefox made announcements (see Google, see Mozilla) they will disable SSL v3 in the near future.
In the mean time you can do that by following the excellent post by Ubuntu.
In summary: Chrome users should use command line flag –ssl-version-min=tls1 (which btw was added to the source code back in 2012) and Firefox users can change the configuration settings by accessing “about:config” and set security.tls.version.min to 1 (details).
In summary, the vulnerability is real, but not as dramatic as HeartBleed or even as the press tried to present it. However, it shows a protocol design failure that has managed to survive 15 years after this protocol successor was released.
Furthermore, CBC IV chaining exploitation has been discussed for a while and still this flow managed to escape scrutiny for many years. Looking back in literature, the first discussion about this in the context of SSH is in 1995 by Phillip Rogaway, then later in 2004 by Bodo Moeller and Gregory V. Bard.
Seeing is believing. Schedule a live demo today.
