Everything old is new again. Security researcher Hanno Böck and friends built a neat little Python adaptive chosen-ciphertext attack proof-of-concept (POC) tool and ran it against many popular websites. They call their attack the “ROBOT”, which stands for Return of Bleichenbacher Oracle Threat, and they’ve published their results at robotattack.org. For this article I’ll be using the word Bleichenbacher to mean the general attack, and ROBOT to mean this latest, optimized version that includes a key signature attack. F5’s SSL/TLS stack was one of the stacks that was found vulnerable. We issued knowledge base article K21905460 in November of 2017 with details for immediate consumption. K21905460 is the official F5 response, and this article is for those looking for a more detailed explanation of the attack, as well as the detection and mitigation strategies related to the vulnerability. CVE-2017-6168 describes a Bleichenbacher attack against the F5 TLS stack. The theory of the attack isn’t new; primers on SSL/TLS mentioned it as early as 1998. The original RSA key exchange padding oracle attack for TLS, Bleichenbacher sends thousands of variations of ciphertext at a TLS server. The TLS server attempts to decrypt each one, and sends back one of two error codes—either the decrypt failed or the padding was messed up. By trying many variations of a message, and differentiating between the two error codes, the attacker could eventually decipher an RSA-encrypted plaintext, one bit at time. Key Points Previously recorded RSA sessions will be vulnerable to decryption until mitigation is applied. At best, the attack decrypts one past TLS session taking several hours and tens of thousands of failed handshakes. Only RSA-based TLS handshakes are vulnerable; elliptic curve (ECC) and Diffie-Hellman are not affected by Bleichenbacher. Recovery of the RSA private key is never a concern for this exploit. There is no need to rotate keys or get new certificates. There is a theoretical man-in-the-middle decryption attack, but it is highly unlikely to successfully exploited. The Bleichenbacher attack raises its head in Europe every now and then. Filippo Valsorda found one in the Python-RSA library in 2016. A German team found one in XML encryption in 2012. Another German team wrote about optimizations for Bleichenbacher in this 2014 paper. Hanno Böck lives in Berlin and writes mostly in German. Daniel Bleichenbacher himself, though, is Swiss. There are two obvious uses for the ROBOT attack. Threat vector #1: Use ROBOT to recover a TLS session Attacker Eve records a TLS browser session between user Alice and website Bob. Eve extracts the encrypted session key material from Alice’s session. Eve then sends thousands of variations of that session key at server Bob, changing a bit here and there. Of course the vast majority of the variations fail, in one of two ways. Sometimes Bob replies “I couldn’t decrypt that.” And sometimes he replies “I decrypted it, but the message padding is messed up.” Eve uses the difference between these error codes to test the validity of each bit she changed. Eventually, she reconstructs Alice’s original session key. She decrypts Alice’s session, and in that session Eve finds Alice’s user credentials, and then the breach is on. Threat vector #2: Use ROBOT during a man-in-the-middle attack In addition to decrypting a message, the Hanno Böck team claims that their variation of the Bleichenbacher attack can coerce a TLS server into signing a piece of data. Because signatures are used to verify the integrity of the TLS handshake, in theory, the ROBOT attack could be used to man-in-the-middle a new TLS session. However, such an attack would be difficult to exploit due to the tens of thousands of messages that Eve would need to send to Bob to construct a signature. Even if Eve was wicked fast, there’s only so many messages t