TLS-Attacker v2.2 and the ROBOT attack

We found out that many TLS implementations are still vulnerable to different variations of a 19-year old Bleichenbacher's attack. Since Hanno argued to have an attack name, we called it ROBOT: https://robotattack.org

Given the new attack variants, we released a new version of TLS-Attacker 2.2, which covers our vulnerabilities.

Bleichenbacher's attack from 1998

In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 1.5 padding allow an adversary to execute an adaptive-chosen ciphertext attack. This attack also belongs to the category of padding oracle attacks. By performing the attack, the adversary exploits different responses returned by the server that decrypts the requests and validates the PKCS#1 1.5 padding. Given such a server, the attacker can use it as an oracle and decrypt ciphertexts.

We refer to one of our previous blog posts for more details.

OK, so what is new in our research?

In our research we performed scans of several well-known hosts and found out many of them are vulnerable to different forms of the attack. In the original paper, an oracle was constructed from a server that responded with different TLS alert messages. In 2014, further side-channels like timings were exploited. However, all the previous studies have considered mostly open source implementations. Only a few vulnerabilities have been found.

In our scans we could identify more than seven vulnerable products and open source software implementations, including F5, Radware, Cisco, Erlang, Bouncy Castle, or WolfSSL. We identified new side-channels triggered by incomplete protocol flows or TCP socket states.

For example, some F5 products would respond to a malformed ciphertext located in the ClientKeyExchange message with a TLS alert 40 (handshake failure) but allow connections to timeout if the decryption was successful. We could observe this behaviour only when sending incomplete TLS handshakes missing ChangeCipherSpec and Finished messages.

See our paper for more interesting results.

Release of TLS-Attacker 2.2

These new findings motivated us to implement the complete detection of Bleichenbacher attacks in our TLS-Attacker. Before our research, TLS-Attacker had implemented a basic Bleichenbacher attack evaluation with full TLS protocol flows. We extended this evaluation with shortened protocol flows with missing ChangeCipherSpec and Finished messages, and implemented an oracle detection based on TCP timeouts and duplicated TLS alerts. In addition, Robert (@ic0ns) added many fixes and merged features like replay attacks on 0-RTT in TLS 1.3.

You can find the newest version release here: https://github.com/RUB-NDS/TLS-Attacker/releases/tag/v2.2

TLS-Attacker allows you to automatically send differently formatted PKCS#1 encrypted messages and observe the server behavior:

$ java -jar Attacks.jar bleichenbacher -connect [host]:[port]

In case the server responds with different error messages, it is most likely vulnerable. The following example provides an example of a vulnerable server detection output:

14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered vulnerable to this attack if it responds differently to the test vectors.
14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered secure if it always responds the same way.
14:12:49 [main] CONSOLE attacks.impl.Attacker - Found a difference in responses in the Complete TLS protocol flow with CCS and Finished messages.
14:12:49 [main] CONSOLE attacks.impl.Attacker - The server seems to respond with different record contents.
14:12:49 [main] INFO  attacks.Main - Vulnerable:true

In this case TLS-Attacker identified that sending different PKCS#1 messages results in different server responses (the record contents are different).