Attacks

The Attacks module allows one to test specific attacks against TLS implementations, or even to execute the whole attacks and extract confidential data.

Bleichenbacher Attack

Bleichenbacher attack allows one to decrypt the premaster secret (and thus the TLS connection secrets). It is applicable to implementations responding with different error messages, depending on the decrypted PKCS#1 message validity.

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

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

In case the server responds with different error messages, it is most likely vulnerable.

Further information can be found here: http://web-in-security.blogspot.de/2014/08/old-attacks-on-new-tls-implementations.html

Heartbleed

The Heartbleed attack exploits a buffer overread in the Heartbeat message processing (see http://heartbleed.com/).

You can check the attack with:

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

If the server responds with a Heartbeat response, it is vulnerable.

You can use the payload length parameter to force the server to send arbitrary number of message bytes:

$ java -jar Attacks.jar heartbleed -connect [host]:[port] -payload_length 20

//TODO

Invalid Curve Attack

If an implementation accepts elliptic curve points from an elliptic curve with a small order, it can be attacked with an invalid curve attack and the server private key can be extracted.

You can check your implementation with the following command:

$ java -jar Attacks.jar invalid_curve

TLS-Attacker attempts to send invalid points to the server and perform a valid handshake. If this is possible and the implementation accepts the invalid point, your implementation is vulnerable. Otherwise, the implementation rejects the incoming point and it is not vulnerable. You should see:

13:50:12.434 [main] CONSOLE_OUTPUT de.rub.nds.tlsattacker.attacks.impl.InvalidCurveAttack - NOT vulnerable to the invalid curve attack.

Further information about the attack can be found here: http://web-in-security.blogspot.de/2015/09/practical-invalid-curve-attacks.html

Padding Oracle Attack

TLS standardized the MAC-then-Pad-then-Encrypt concept to secure symmetric CBC ciphertexts. It is of a huge importance to correctly check the CBC padding and always validate the MAC. Otherwise, the attacker could apply padding oracle attacks. See the original paper from Vaudenay (https://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf) or the Lucky13 paper for more details (http://www.isg.rhul.ac.uk/tls/Lucky13.html). If your implementation responds with different error messages depending on the padding validity, it can be vulnerable to the attack.

You can check whether your implementation is vulnerable to this attack with:

$ java -jar Attacks.jar padding_oracle

You should see the following output:

14:03:24.266 [main] CONSOLE_OUTPUT de.rub.nds.tlsattacker.attacks.impl.PaddingOracleAttack - localhost:4433, NOT vulnerable, one message found: [
ALERT message:
  Level: FATAL
  Description: BAD_RECORD_MAC]

Be aware that this test can easily produce false positives, because some implementations directly reject the message before decryption, as soon as they found there are not enough bytes to validate the MAC. This is, for example, the case of Botan 1.11.30.

In Botan 1.11.30 version you would see:

14:06:07.675 [main] CONSOLE_OUTPUT de.rub.nds.tlsattacker.attacks.impl.PaddingOracleAttack - localhost:4433, Vulnerable (?), more messages found, recheck in debug mode: [
ALERT message:
  Level: FATAL
  Description: DECODE_ERROR, 
ALERT message:
  Level: FATAL
  Description: BAD_RECORD_MAC]

However, this does not mean the library is vulnerable. The library responds with DECODE_ERROR if there are not enough bytes to decrypt and process.

Lucky 13

The Lucky 13 attack exploits timing differences arising from processing TLS records encrypted with AES-CBC (http://www.isg.rhul.ac.uk/tls/Lucky13.html).

Java is not the perfect language for executing timing measurements...but it is still ok to execute these tests.

You can use TLS-Attacker to test whether your implementation is vulnerable to this attack:

$ java -jar Attacks.jar -loglevel ERROR lucky13

TLS-Attacker per default sends 2 different Application messages and measure server response times. Both messages have the same length: 18 blocks. The first message contains one 0x00 padding byte. The second message contains 256 0xFF padding bytes (this scenario corresponds to the Distinguishing Attack from Section 3 in the Lucky 13 paper). The measurement is executed 100 times and at the end, you can see the median values (provided in nanoseconds):

Lucky13Attack - Padding: 0
Lucky13Attack - Median: 416520
Lucky13Attack - Padding: 255
Lucky13Attack - Median: 412731

Processing of the message with a 0x00 byte takes longer because the server needs to validate HMAC over more plaintext bytes.

More comprehensive tests can be executed with statistic tools and a few TLS-Attacker parameters:

• measurements: Number of timing measurements
• blocks: Number of blocks to encrypt. Default is set to 18, the value from the Lucky 13 paper, Section 3
• paddings: Paddings to check for differences, column separated. Default is set to 0,255
• mona_file: File output for Mona timing lib to execute further analyses (https://github.com/seecurity/mona-timing-report).

For example, you can use the following command:

java -jar Attacks.jar -loglevel ERROR lucky13 -mona_file /tmp/lucky13.txt -measurements 2000

TLS-Attacker then executes 2000 measurements with the tested server and writes the output to /tmp/lucky13.txt-0-255. You can then start Mona timing reporting library with the following command to generate a report:

java -jar Attacks.jar lucky13 --inputFile=/tmp/lucky13.txt-0-255 --name=lucky13-0-255 --lowerBound=0.3 --upperBound=0.5

A figure from a timing report analyzing Botan 1.11.33 clearly shows the differences in processing times (in nanoseconds):

Please always check the code and debug messages before submitting bugs.