Attacks

TLS-Attacker ships with an Attack application, which allows one to test for 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 behavior:

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

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

With the -type FULL parameter you can specify a higher number of test queries.

The bleichenbacher command supports the following parameters: -config -cipher -connect -server_name -signature -signature_length -version

Further information on the Attack 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

Addtionally, the following parameters are supported: -cipher -config -server_name -version

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 servers private key can be extracted.

You can check your implementation with the following command:

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

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.

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

Additionally the invalid_curve command support the following parameters: -additional_equations -cipher -config -curve_field_size -executeAttack -namedCurve -protocol_flows -server_name -server_type -version

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 -connect [host]:[port]

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.

//TODO Update Output 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.

The bleichenbacher Attack offers the following parameters: -cipher -config -server_name -type -version

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 lucky13 -connect localhost:4433

TLS-Attacker per default sends 2 different Application messages and measures the servers 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 lucky13 -connect [host]:[port] -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 -connect [host]:[port] --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):

Additionally the lucky13 command supports the following commands: -block_size -block -cipher -config -connect -measurements -mona_file -paddings -server_name -version

Poodle

TLS-Attacker is able to test a Server for the Poodle Vulnerability as well as the TLS variant of Poodle. (https://censys.io/blog/poodle) (https://www.imperialviolet.org/2014/12/08/poodleagain.html) In order to test a server for poodle one has to execute the poodle command.

For example, you can use the following command:

java -jar Attacks.jar poodle -connect [host]:[port]

If you want to test for the TLS variant of Poodle use:

java -jar Attacks.jar tls_poodle -connect [host]:[port]

CVE-20162107

This CVE describes a Padding Oracle vulnerability that was discovered using TLS-Attacker (http://web-in-security.blogspot.de/2016/05/curious-padding-oracle-in-openssl-cve.html). A Server can be checked with the following command:

java -jar Attacks.jar cve20162107 -connect [host]:[port]

Additionally the cve20162107 command supports the following commands: -cipher -config -connect -server_name -versions

Early CCS

With TLS-Attacker it is easy to check if a Server is vulnerable to the Early CCS vulernability(https://www.imperialviolet.org/2014/06/05/earlyccs.html). An example test for the vulnerability can be executed with:

java -jar Attacks.jar early_ccs -connect [host]:[port]

Winshock

TLS-Attacker is able to execute the Winshock Exploit if you provide it with a defined Signature. Example:

java -jar Attacks.jar winshock -connect [host]:[port] -signature 0x1234

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