tls_attacks.md 6.7 KB


title: Attacks on SSL/TLS categories: [cheatsheets]

tags: [crypto]

Implementation Attacks

Heartbleed

  • Bug in OpenSSL 1.0.1 (CVE-2014-0160)

Bug in the Heartbeat Function (TLS Extension) of OpenSSL Size Field of the Heartbeat Message is not checked, an attacker can therefor read 64kb of process memory from the server (with one heartbeat message) -> can leak the private key, session tokens, passwords...

FREAK - Factoring RSA Export Keys

  • Bug in OpenSSL (CVE-2015-0204)

This Bug needs the Server to use export ciphers and to reuse the downgraded RSA 512 Bit Keys. And the Client needs the vulnerable OpenSSL Version. in the 90s Export Keys where max 40 bit for sym. ciphers and 512 bit for asym. ciphers. And because RSA was also used for authentication AND for the encryption, you needed to split that up (strong auth. was allowed). Therefor before the key exchange, the server was generating new and weak RSA keys, they were signed by the strong certificate and send to the CLIENT (via ServerKeyExchange Message). The CLIENT used this to encrypt the PREMASTER SECRET. This function should not be used at a normal RSA Key Exchange, but if an Server sends a ServerKeyExchange Paket anyway, a vulnerable Client happily accepts it. Thus making the Key Exchange with a 512Bit Key :(

Was is the attacker changing:

a) Change the ClientHello to only offer Export Cipher Suites to the server

b) Change the ServerHello to a fitting RSA Cipher Suite that the Client can Accept (no ServerKeyExchange on a RSA Suite)

c) The finished Message containing a valid MAC over all Handshake messages

This ServerKeyExchange two major problems:

1) The injected Signature must be signed by the strong Key

2) Finished Paket contains a MAC of all Handshake messages

To overcome 1:

Make a own request to the server with only export ciphers, replaying this exact paket.

-> Another problem: random 64bit in the Client/ServerHello? Wait for a Client to connect, and use this 64bit random value in the own Request

To overcome 2:

Bruteforce the 512 Bit RSA Key in realtime to pass a valid MAC to the Server/Client

-> Needs a shitton of resources Or: Hope the server is reusing the key for some period (saving cpu resources). Must be long enough to break key. (Online Cloud Computation to break key: 7h and 100$)

Downgrade Attacks

later alligator

Protocol Attacks

Insecure renegotiation (found in 2009)

This happens when a client does not support secure renegotiation. An attacker can intercept a victims TLS Handshake, keep it and send its own Handshake to the server. (Attacker acting as a proxy) Then the attacker can send arbitrary requests to the server

GET /evil.php
Dummy:

then, the victims handshake is send to the server, using the same TCP connection. The server interprets this as a client-initiated renegotiation. An encrypted channel is opened between vicitm and server, via the attacker. The victims sends a new request:

GET /good.php
Cookie: very-secure-cookie

Because the application knows nothing about the underlying TLS stuff, the two data parts are treated as one:

GET /evil.php
Dummy: GET /good.php
Cookie: very-secure-cookie

This attack can be used for all-kinds of stuff, e.g. bypassing authentication (using the victims session cookies)

Mitigation

Secure renegotiation via RFC 5746 (Renegotiation Indication Extension)

BEAST (found in 2011)

  • TODO

CRIME (+TIME & BREACH) (found 2011)

  • All three are Attacks against the compression in TLS (or even HTTP).

The way compression works: if something occurs multiple times -> gets replaced by a reference to an earlier occurance. This can be abused by guessting (eg. HTTP Cookie). Use the guessed cookie in the request. If the cookie is in the request a second time, the compressed size is smaller (-> guess is correct). if the size is larger, a wrong guess was made.

Example Attack:

  1. Used must browse on good.com and http://evil.com
  2. JS/Html is used to request evil.com from good.com (<img src=evil.com/<custom>)
  3. Guess single Bytes of the Cookie
  4. Attacker is in the network (mitm) and observes the response size of evil.com
  5. ~7 guesses per Byte

    GET evil.com/Cookie: PHPSESSID=<guess>
    Cookie: PHPSESSID=UNASMNSDJGBKASDB
    

Lucky13 (found in 2013)

Padding oracle attack against CBC Ciphersuites. Early TLS: decryption_failed error when having a wrong padding & bad_record_mac for wrong authentication. Now: Timing differences between wrong padding & wrong mac. this leads to a padding oracle. Can recover plaintext pairs of a request (approx. 8m requests for 16 Byte) Problem: After Every (wrong) Guess, a new TLS Handshake must be established! (time consuming...) Multiple variants with increasing successrates. Eg. one byte at a known position (last- or second-last bye) reduces the number of request to about 2**16!

=> Every TLS implementation (1.0, 1.1, 1.2) is vulnerable to this attack!

Mitigation

Dont use CBC Cipher Suits! (Padding Oracles are a general problem) Remove possible timing-oracles by calculating a dummy MAC, even when the padding is wrong (-> no oracle)

RC4 Stuff (found in XXXX)

Key Scheduling Weakness

A small part of the input key influences a greater part of the keystream. So if a part of the key is reused, an attacker can uncover parts of the keystream (parts of known plaintext), these parts can then be uncovered at the same place in all keystreams.

  • this is how WEP was broken!
  • NOT a Problem of TLS (its using a new key for each connection)

Single-Byte Biases

The Second Byte in the RC4 keystream is biased towards zero (1/128 instead of 1/256). this means, that the second byte is much more often zero as it should be. therefor the ciphertext @byte 2 is often "unencrypted" (C xor P) if C = 0; -> 0 xor P = P

Needs a lot of data, and always the same data at the same position. NOT usable against TLS

Later research showed, that with enough samples (~2^32) the first 256 bytes have biases that can be revealed. with that 2^32 samples the success rate is almost 100%. More theoretical and not really practical attack. too many connections needed + often cookies/passwords are stored after the 220 byte mark.

double-byte biases

Also double-byte biases are found in RC4, this means that some 2 byte combinations occur more often that others. this attack needs less messages as the single-byte bias attack, but is still unpracticle. one advantage is that it doest needs a new connection for every now biases message. ~3.25TB of connection data is needed to have a practicle attack.

TIME (found in XXXX)

BREACH (found in XXXX)

Triple HS (found in XXXX)

POODLE (found in XXXX)

ROBOT (Return Of Bleichenbacher Oracle Threat)