title: Attacks on SSL/TLS categories: [cheatsheets]
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...
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$)
later alligator
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)
Secure renegotiation via RFC 5746 (Renegotiation Indication Extension)
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:
<img src=evil.com/<custom>
)~7 guesses per Byte
GET evil.com/Cookie: PHPSESSID=<guess>
Cookie: PHPSESSID=UNASMNSDJGBKASDB
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!
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)
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.
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.
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.