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. 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).

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

Recent TLS-Attacker implementation also contains checks for different variations as described in the ROBOT attack: https://robotattack.org/

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

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 invalid elliptic curve, 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

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]

An output for a secure implementation can look as follows:

14:24:55 [main] CONSOLE attacks.impl.Attacker - A server is considered vulnerable to this attack if it responds differently to the test vectors.
14:24:55 [main] CONSOLE attacks.impl.Attacker - A server is considered secure if it always responds the same way.
14:24:56 [main] CONSOLE attacks.impl.Attacker - The server shows no behaviour difference on the protocol / socket layer. The Server seems to be fine.
14:24:56 [main] INFO  attacks.Main - Vulnerable:false

The padding_oracle attack offers the following parameters:

-cipher
-config
-server_name
-type
-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]

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