Hanno Böck, Juraj Somorovsky (Hackmanit GmbH, Ruhr-Universität Bochum), Craig Young (Tripwire VERT)
Full paper published at the Usenix Security conference.
An earlier version was published at the Cryptology ePrint Archive
We won a Pwnie award!
We gave presentations about ROBOT at various Infosec conferences:
ROBOT presentation at RuhrSec 2018
ROBOT presentation at BornHack 2018
ROBOT presentation at USENIX Security 2018
Further presentations were given at other conferences, for example, at Black Hat USA. We'll add links once recordings become available.
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.
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.
We have identifed 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.
We published a python tool to scan for vulnerable hosts. Alternatively you can check a host with the SSL Labs test.
We will update the following table if we become aware of more affected vendors:
MatrixSSL and JSSE are old vulnerabilities, but we added them as we still see vulnerable hosts.
Indirectly vulnerable products due to the use of vulnerable components:
| Aruba Instant | Aruba Product Security Advisory ARUBA-PSA-2018-002 (uses WolfSSL) | CVE-2017-13099 |
| Micro Focus | Bouncy Castle Weak Oracle (CVE-2017-13098) (uses Bouncy Castle) | CVE-2017-13098 |
If you use one of the products that provides a fix you should of course install the update. However, we recommend something else:
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.
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.
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.
No. This is an implementation bug in servers, there is nothing clients can do to prevent it.
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).
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.
Not necessarily.
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.
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.
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.
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.
They're also problematic, but for different reasons that were not part of our research.
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.
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.
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.
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.
We have reached out to the developers of various TLS testing tools before the publication of our research. The following tools have checks that will cover ROBOT:
We encourage developers of other security and TLS testing tools to add checks for ROBOT. You can use our code, it's under a CC0 (public domain) license.
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.
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.
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.
We had considerable disagreement in our team about this. Juraj agreed only under protest. All complaints about this issue need to go to Hanno.
The Register: F5 DROWNing, not waving, in crypto fail
Golem.de: ROBOT-Angriff - 19 Jahre alter Angriff auf TLS funktioniert immer noch
Forbes: 'ROBOT Attack' Exposed Facebook With 19-Year-Old Bug -- Massive Websites Still Vulnerable
Ars Technica: 1998 attack that messes with sites’ secret crypto keys is back in a big way
The Hacker News: ROBOT Attack: 19-Year-Old Bleichenbacher Attack On Encrypted Web Reintroduced
The Register: I, Robot? Aiiiee, ROBOT! RSA TLS crypto attack pwns Facebook, PayPal, 27 of 100 top domains
Security Affairs: ROBOT Attack: RSA TLS crypto attack worked against Facebook, PayPal, and tens of 100 top domains
Bleeping Computer: Variation of 19-Year-Old Cryptographic Attack Affects Facebook, PayPal, Others
ThreatPost: 19-Year-Old TLS Vulnerability Weakens Modern Website Crypto
SC Magazine: TLS exploit 'ROBOT' capitalizes on 19-year-old vulnerability; vendors issue patch
heise: ROBOT-Attacke: TLS-Angriff von 1998 funktioniert immer noch
digi.no: Gammel kryptosårbarhet er tilbake. Facebook blant de berørte
TripWire / The State of Security: VERT Threat Alert: Return of Bleichenbacher’s Oracle Threat (ROBOT)
Cryptosense: Bleichenbacher is Back – Again
Trustzone: The ROBOT attack: RSA Encryptoin is vulnerable
Kudelski Security / JP Aumasson: Algorithms can't be patched
Juraj Somorovsky: TLS-Attacker v2.2 and the ROBOT attack
Hubert Kario / Red Hat: Detecting ROBOT and other vulnerabilities using Red Hat testing tools
CERT/CC: Vulnerability Note VU#144389
TLS mailing list, Colm MacCárthaigh (Amazon s2n): A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS
Here we collect links to further significant research on Bleichenbacher attacks that happened after our work.
The 9 Lives of Bleichenbacher's CAT (Cache sidechannel attacks, 2019) (Blogpost by David Wong)
Marvin Attack (Timing sidechannels, 2023)