Attacks

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

In the following, we will assume the commands are executed from the Runnable folder. The connection is per default established with localhost:4433.

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 target/TLS-Attacker-1.0.jar bleichenbacher

In case the server responds with different error messages, it is most likely vulnerable. Otherwise, you would see:

14:09:43.098 [main] CONSOLE_OUTPUT de.rub.nds.tlsattacker.attacks.impl.BleichenbacherAttack - localhost:4433, NOT vulnerable, one message found: [ALERT (FATAL, BAD_RECORD_MAC) ]

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

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 target/TLS-Attacker-1.0.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-1.0-SNAPSHOT-jar-with-dependencies.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 e.g. the case of Botan.

In the recent Botan 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]

This however does not mean the library is vulnerable.

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