Daniel Bleichenbacher was the security researcher who first discovered, in 1998, that PKCS #1 v1.5 padding error messages sent by a Transport Layer Security (TLS) stack running on a server could enable an adaptive-chosen ciphertext attack. When used in conjunction with RSA encryption, this attack completely shattered TLS confidentiality.
What Is the ROBOT Attack?
ROBOT stands for Return Of Bleichenbacher's Oracle Threat – the return of the original vulnerability that enabled hackers to perform RSA decryption and signing operations with a TLS server's private key (without needing the key itself).
Even though it has been known since the late 1990s, lots of web hosts remain vulnerable to attacks against RSA in TLS.
How Does the ROBOT Attack Work?
An attacker can simply send Client Key Exchange (CKE) messages – with wrong paddings – while a TLS-RSA handshake is being negotiated. Then, depending on the server's response to these modified CKE messages, the attacker can determine whether the server provides an oracle that renders the server vulnerable. If they discover a vulnerable server, the attacker will be able to decrypt any ciphertext, or sign any data, with the server's private key. To do so, the attacker first needs to passively record a certain amount of encrypted traffic. The amount of the traffic that needs to be recorded is determined by the
strength of the provided oracle.
Attack Performance and Oracle Types
Bleichenbacher's article explains that the strength of the provided oracle determines the impact of the attack:
- What happens is that with every new and valid oracle response, the attack algorithm finds a new interval (if the decrypted ciphertext begins with '0x0002')
- It is thought to be weaker if it sends a negative response (for some decrypt ciphertexts that begin with '0x0002'), resulting in no new intervals
In the second situation, the attack would need to create additional queries.
When using
the strongest oracle, 10,000 queries on average will be enough; however, when using
the weakest oracle, about 18,000,000 queries will be needed to decrypt a ciphertext. All the other oracles lie between these two in exploitability terms.
For simplicity, the ROBOT attack paper assumes there are two types of oracle:
- The strong oracle, which needs less than a million queries
- The weak oracle, which needs at least several million queries
Anatomy of a ROBOT Attack Query
As stated earlier, an attacker needs to send modified CKE messages – with incorrect paddings – while a TLS-RSA handshake is being negotiated, in order to get an oracle from a vulnerable server.
Based on the previous research on the Bleichenbacher attack, attackers need to create five different types of padding in order to trigger different vulnerabilities in the server. The padding types are outlined below.
Correctly Formatted TLS Message
This message contains a correctly formatted PKCS #1 v1.5 padding, with '0x00' in the correct position and the correct TLS version located in the pre-master secret.
| 0x0002 [2] |
PAD |
0x00 [1] |
TLS Version [2] |
Random [46] |
|
|
|
Pre-master Secret |
This message should simulate an attacker who correctly guessed the padding as well as the TLS version. It's difficult to trigger (because of a low probability of constructing such a message), but it is needed to evaluate the server correctness.
Incorrect Padding
This message starts with incorrect padding bytes.
The invalid first bytes in the padding should trigger unexpected server behavior.
0x00 Byte in the Wrong Position
This message is in the correct format, but has '0x00' in the wrong position, so that the unpadded pre-master secret would have an invalid length.
Many implementations assume that the unpadded value has a correct length. If the unpadded value is shorter or longer, it could trigger a
buffer overflow or specific internal exceptions, and lead to unexpected server behavior.
Missing 0x00 Byte
This message starts with '0x0002' but excludes the '0x00' byte.
If the '0x00' byte is missing, the PKCS #1 v1.5 implementation cannot unpad the encrypted value, which can again result in unexpected server behavior.
Wrong TLS version
This message contains an invalid TLS version in the pre-master secret.
| 0x0002 [2] |
PAD |
0x00 [1] |
0x0202 [2] |
Random [46] |
|
|
|
Pre-master Secret [48] |
This message also should trigger unexpected behavior.
How Hackers Reveal the ROBOT Vulnerability
To construct all these padding variations, and get an oracle from the server, an attacker proceeds as follows:
- First, they start a TLS-RSA handshake and acquire the server certificate from the 'Server Hello' message.
- Next, they create CKE messages, as described above. Padding length should match the server certificate's public key length (key size of the public key, in bytes). Then, they encrypt the pre-master secrets using the server's public key.
- Next, they send constructed CKE variations, followed by valid Change Cipher Spec (CCS) and Finished messages. This is referred to as the 'Message Flow'.
- If the response is not the same for each test case, the target can be presumed to be vulnerable.
- If not, the attacker sends the same CKE messages but without following up with CCS and Finished messages (a shortened message flow), and waits for the Timeout.
- Again, if the response is not the same for each test case, the target can be presumed to be vulnerable.
When testing with the shortened Message Flow, it is necessary to set an appropriate Socket Timeout for the network path between the client and the server.
ROBOT Impact and Remediation
When the ROBOT vulnerability was first discovered, it was estimated that "almost a third of the top 100 domains in the Alexa Top 1 Million list, among them Facebook and Paypal" were vulnerable to this type of attack. In addition, many other vendors and open source projects were also found to be vulnerable.
For a complete list of who is affected, refer to the
ROBOT Attack website. If you use one of the products that provides a fix, you should, of course, install the update.
Do Not Use RSA Encryption Modes!
However, to prevent such vulnerabilities on your host, it would be better to disable RSA encryption modes. This is not the first time a variation of Bleichenbacher's padding oracle attack has surfaced to exploit RSA encryption modes. Previously there was another attack, DROWN (Decrypting RSA with Obsolete and Weakened eNcryption), which also allowed an attacker to break the encryption. Moreover, RSA encryption modes also lack forward secrecy.
In a nutshell, the fact that RSA encryption modes are so exploitable means that disabling them is the best policy. This refers to all ciphers that begin with 'TLS_RSA'. This does not include ciphers that use RSA signatures and include 'DHE' or 'ECDHE' in their name; they are unaffected by the ROBOT attack.
Scanning for the ROBOT Vulnerability with Netsparker
We released a
Netsparker web application security scanner hotfix version that included ROBOT checks on December 22. To make sure Netsparker includes the ROBOT checks in your next scan, simply open the relevant Scan Policy and enable the SSL Security Check Group.
In addition, if you want only to check your host for the ROBOT vulnerability you can
create a new Scan Policy with only the SSL Security Check group enabled.
To limit the scan to SSL checks only you can also disable JavaScript Analyzer in the Scan Policy, and run the scan with the Scan Imported Links Only option by adding your host's root path to Imported Links. Remember that a host can run different TLS stacks on different domains. Often the host starting with 'www' is served by a different TLS stack than the host without the 'www' prefix. Therefore, add both forms to Imported Links, or scan both.
The ROBOT Attack Whitepaper
For all the technical details on the ROBOT attack read the
Return Of Bleichenbacher’s Oracle Threat (ROBOT) whitepaper by by Hanno B¨ock, Juraj Somorovsky1 and Craig Young.
