The Vulnerability
ROBOT is the return of a 19-year-old vulnerability that allows performing RSA decryption and signing operations with the private key of a TLS server.
In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 v1.5 padding allowed an adaptive-chosen ciphertext attack; this attack fully breaks the confidentiality of TLS when used with RSA encryption.
We discovered that by using some slight variations this vulnerability can still be used against many HTTPS hosts in today's Internet.
How bad is it?
For hosts that are vulnerable and only support RSA encryption key exchanges it's pretty bad. It means an attacker can passively record traffic and later decrypt it.
For hosts that usually use forward secrecy, but still support a vulnerable RSA encryption key exchange the risk depends on how fast an attacker is able to perform the attack. We believe that a server impersonation or man in the middle attack is possible, but it is more challenging.
Who is affected?
We have identified vulnerable implementations from at least seven vendors including F5, Citrix, and Cisco. (Current patch status is listed below.)
Some of the most popular webpages on the Internet were affected, including Facebook and Paypal. In total, we found vulnerable subdomains on 27 of the top 100 domains as ranked by Alexa.
I am affected, what shall I do?
If you use one of the products that provides a fix you should of course install the update. However, we recommend something else:
Disable RSA encryption!
ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.
By disabling RSA encryption we mean all ciphers that start with TLS_RSA. It does not include the ciphers that use RSA signatures and include DHE or ECDHE in their name. These ciphers are not affected by our attack.
Based on some preliminary data we also believe the compatibility costs of disabling RSA encryption modes are relatively low. Cloudflare shared with us that around one percent of their connections use the RSA encryption modes. Disabling these modes on the HTTPS server operated by one of the authors caused no notable problems.
I have a Cisco ACE device.
Cisco informed us that the ACE product line was discontinued several years ago and that they won't provide an update. Still, we found plenty of vulnerable hosts that use these devices.
These devices don't support any other cipher suites, therefore disabling RSA is not an option. To our knowledge it is not possible to use these devices for TLS connections in a secure way.
However, if you use these products you're in good company: As far as we can tell Cisco is using them to serve the cisco.com domain.
My server is vulnerable. Do I need to revoke my certificate?
No. This attack does not recover the server's private key. It does only allow an attacker to decrypt ciphertexts or sign messages with the server's private key.
Do I need to update my browser?
No. This is an implementation bug in servers, there is nothing clients can do to prevent it.
Can you actually prove that Facebook was vulnerable?
We were able to sign a test message with Facebook's private key.
You don't have to take our word for it; we have cryptographic proof. Just use these commands:
echo 799e4353 5a4da709 80fada33 d0fbf51a e60d32c1 115c87ab 29b716b4 9ab06377 33f92fc9 85f280fa 569e41e2 847b09e8 d028c0c2 a42ce5be eb640c10 1d5cf486 cdffc5be 116a2d5b a36e52f4 195498a7 8427982d 50bb7d9d 938ab905 40756535 8b1637d4 6fbb60a9 f4f093fe 58dbd251 2cca70ce 842e74da 078550d8 4e6abc83 ef2d7e72 ec79d7cb 2014e7bd 8debbd1e 313188b6 3a2a6aec 55de6f56 ad49d32a 1201f180 82afe3b4 edf02ad2 a1bce2f5 7104f387 f3b8401c 5a7a8336 c80525b0 b83ec965 89c36768 5205623d 2dcdbe14 66701dff c6e768fb 8af1afdb e0a1a626 54f3fd08 175069b7 b198c471 95b63083 9c663321 dc5ca39a bfb45216 db7ef837 | xxd -r -p > sig
curl https://crt.sh/?d=F709E83727385F514321D9B2A64E26B1A195751BBCAB16BE2F2F34EBB084F6A9|openssl x509 -noout -pubkey > pubkey.key
openssl rsautl -verify -pubin -inkey pubkey.key -in sig
The first line will write the signature to a file using xxd (a tool that's part of vim). The second line will download Facebook's certificate as used at the time of the attack (we could also download it from Facebook, but then it won't work after they change it). The third line will verify it and tell you that it's a signature over the text:
We hacked Facebook with a Bleichenbacher Oracle (JS/HB).
How is it possible that a 19-year-old vulnerability is still present?
After Bleichenbacher's original attack the designers of TLS decided that the best course of action was to keep the vulnerable encryption modes and add countermeasures. Later research showed that these countermeasures were incomplete leading the TLS designers to add more complicated countermeasures.
The section on Bleichenbacher countermeasures in the latest TLS 1.2 standard (7.4.7.1) is incredibly complex. It is not surprising that these workarounds aren't implemented correctly.
If the test says I'm not vulnerable then everything is fine, right?
Not necessarily.
Further protocol flows and cipher suites
We discovered that with slight modifications, e.g. by changing the message flow or by using different cipher modes, we could find more vulnerable hosts. It is likely that further variations may reveal new oracles.
Cross-protocol and cross-server attacks
Even if your server is not directly vulnerable, the attack can be applied in two cases. First, your secure server can share the same public with a vulnerable server. As shown in DROWN, this is quite common that web servers share the same key. The attacker can then use the vulnerable server as an oracle to decrypt the confidential communication with your secure server.
Second, another vulnerable server can use a certificate with a domain name that matches your secure server. This would allow an attacker to perform impersonation attacks. We have actually observed such an example in the wild. The main WhatsApp web page www.whatsapp.com was not vulnerable, but we detected several vulnerable servers with a wildcart certificate issued to *.whatsapp.com.
Timing attacks
It is also important to note that our test does not consider timing variants of Bleichenbacher's vulnerability. However these tend to be very hard to exploit in practice.
You can find some info about potential timing issues in OpenSSL here and in NSS here.
What's this PKCS #1 v1.5 you're talking about?
The RSA algorithm cannot be used in its "pure" form. In order to be secure, messages need some kind of padding. PKCS #1 v1.5 is a widely used padding mode for RSA for both encryption and signatures.
There are more secure padding modes for RSA (PSS/OAEP), but they never gained widespread adoption. They're standardized in PKCS #1 v2.2.
What about PKCS #1 v1.5 signatures?
They're also problematic, but for different reasons that were not part of our research.
Is this only a problem for TLS?
No. Bleichenbacher-style vulnerabilities have been found in XML Encryption, PKCS#11 interfaces, Javascript Object Signing and Encryption (JOSE), or Cryptographic Message Syntax / S/MIME.
Every protocol that uses RSA PKCS #1 v1.5 encryption is at risk of exposing similar vulnerabilities.
How is ROBOT different from Bleichenbacher's original attack?
Bleichenbacher's original work from 1998 used an oracle based on different TLS alerts. We changed it to allow various different signals to distinguish between error types like timeouts, connection resets, duplicate TLS alerts.
We also discovered that by using a shortened message flow where we send the ClientKeyExchange message without a ChangeCipherSpec and Finished message allows us to find more vulnerable hosts.
So... ROBOT doesn't add a whole lot, right?
That's correct. The surprising fact is that our research was very straightforward. We used minor variations of the original attack and were successful. This issue was hiding in plain sight.
This means neither the vendors of the affected products nor security researchers have investigated this before, although it's a very classic and well-known attack.
How is this related to previous research?
Originally this type of attack was discovered by Daniel Bleichenbacher in 1998.
Klima, Pokorny and Rosa improved the attack and discovered the bad-version oracle in 2003.
In 2012 Romain Bardou and others developed a much more efficient Bleichenbacher attack algorithm that reduces the number of needed connections.
In 2014 Christopher Meyer and others discovered Bleichenbacher vulnerabilities in JSSE and other products and describe the first practical timing attacks.
Tibor Jager and colleagues discovered that it is possible to use a cross-protocol Bleichenbacher attack against TLS 1.3 and QUIC.
The DROWN attack is a protocol level Bleichenbacher vulnerability in SSL version 2. The DROWN research also contains further insights on cross-protocol scenarios.
Are there any tools that I can use to scan for this vulnerability?
We have reached out to the developers of various TLS testing tools before the publication of our research.
https://gss-portal.com/sslchecker/
Can this attack be used against Bitcoin?
Bitcoin does not use RSA, instead it uses elliptic curve cryptography based on the curve secp256k1. Our attack cannot be directly applied to that. However if you transform a quantum key exchange to a supersingular Isogeny you can attack post-quantum RSA and thus apply our attack indirectly to secp256k1.
We believe the only way Bitcoin can defend against this is to immediately switch to Quantum Blockchains.
Will you publish the proof of concept?
We have published a proof of concept as part of our robot-detect script.
We delayed publishing the poc after our initial announcement to give people time to patch and fix their servers and to play the CTF.
Play our Capture The Flag contests!
Update: The CTF is over!
We have a ROBOT CTF contest where you can test your crypotgraphic attack skills.
This will require the implementation of a practical Bleichenbacher attack. While we can't make any rules about what you publish we ask you to delay the publication of any tools you create during the contest until it is over.
We will probably run the contest for two months, but we may revisit the timeline.
Is this vuln really serious enough to deserve a name, a logo and a web page?
We had considerable disagreement in our team about this. Juraj agreed only under protest. All complaints about this issue need to go to Hanno.
