Graeme Dawes - Fotolia
Why the Bleichenbacher attack is still around
The Bleichenbacher attack got a new name after 20 years. Expert Michael Cobb reviews the ROBOT attack and discusses why it's still active this long after it emerged.
The technologies that make the internet work all have an inherent weakness: They need to maintain a high degree of backward compatibility in order to work with legacy systems. This causes a drag on efforts to improve the overall security of the internet and often results in a second best or less than ideal solution.
The SSL/TLS protocol is a clear example of how security has been compromised for the sake of interoperability. Take the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability, for instance. Even though the SSL protocol is known to be insecure, the need for backward compatibility means there is a protocol downgrade option during the TLS protocol handshake when the server and client negotiate which protocol version to use. POODLE takes advantage of this to force a TLS connection to use the insecure SSL protocol, even if both the client and server support the TLS protocol.
The Bleichenbacher attack
In 1998, Daniel Bleichenbacher published details of what he called the Bleichenbacher oracle attack while working for Bell Laboratories. He found that the messages returned by SSL servers for errors in Public-Key Cryptography Standards (PKCS) #1 version 1.5 padding enabled an adaptive-chosen ciphertext attack, in which the attacker sends a number of ciphertexts to be decrypted, then uses the results of these decryptions to select subsequent ciphertexts. This enabled an attacker to perform RSA decryption and signing operations with the private key of a TLS server, completely breaking the confidentiality of TLS when used with RSA encryption.
To mitigate this serious flaw, the designers of TLS added various countermeasures because removing the vulnerable encryption modes would have led to problems with backward compatibility. Even after research showed that these countermeasures were incomplete, more countermeasures were added. Unsurprisingly, it appears that these complex workarounds have often been incorrectly implemented, even though this attack has been referenced in all Internet Engineering Task Force specifications for TLS since version 1.0 in 1999, with specific warnings to take steps to avoid the Bleichenbacher attack. The issues that enable the Bleichenbacher attack have been fixed in later versions of PKCS, but many servers still implement TLS using the PKCS #1 v1.5 specification.
The return of the Bleichenbacher attack
A team of information and computer security researchers discovered that by using some minor variations of the original Bleichenbacher attack, it can still be used effectively against many HTTPS hosts, including eight major vendors and open source projects and affecting some of the most popular websites on the internet, including Facebook and PayPal. The researchers have called the vulnerability "Return of Bleichenbacher's Oracle Threat," or ROBOT.
Bleichenbacher used an oracle based on different TLS alerts. In cryptography, an oracle is a mathematical description of a data leak which can provide information about a system that otherwise would not be available. He found that the error messages given by servers for errors in PKCS #1 v1.5 padding opened up the possibility to launch an adaptive-chosen ciphertext attack. By changing the attack to enable various signals to distinguish between error types like timeouts, connection resets and duplicate TLS alerts, the researchers found that the vulnerability could still be exploited, because TLS, as currently deployed, still ignores improperly formatted data.
This flaw could lead to very serious attacks, enabling an attacker to passively record traffic and later decrypt it. They even demonstrated a practical exploitation by signing a message with the private key of facebook.com's HTTPS certificate. The signature can be found in Appendix A of their paper.
ROBOT only affects TLS cipher modes that use RSA encryption, so RSA encryption modes should be disabled, even though most modern TLS connections use an elliptic-curve Diffie-Hellman key exchange as RSA encryption modes lack forward secrecy. This means disabling all ciphers that start with TLS_RSA. Checks should be carried out to ensure legacy systems won't be affected by these changes, but in most cases, there should be no adverse effects; data obtained by the researchers from cloud company Cloudflare Inc. showed that only around 1% of their connections use the RSA encryption modes.
Mitigation strategies
Vendors of TLS stacks need to test and audit their code for known vulnerabilities more thoroughly, using third-party firms specializing in cryptanalysis if they don't have the necessary in-house expertise. Network administrators should begin preparing systems for the arrival of TLS 1.3, which is expected to be finalized soon, particularly as it deprecates the use of PKCS #1 v1.5 and specifies use of PKCS #1 v2.2, a move the researchers feel the TLS protocol designers should have made sooner.
The researchers noted however that PKCS #1 v1.5 is still used in other systems like XML encryption and the ability to disable it will be highly application-specific. Although the attack creates identifiable traffic patterns, high volume sites would struggle to distinguish between genuine failed connections and those used in an attack. The ROBOT attack researchers provided an online tool for testing public HTTPS servers and a python tool to scan for vulnerable hosts.
